Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Include full dependency chain in error message #127

Open
trampster opened this issue Jun 17, 2021 · 6 comments
Open

Include full dependency chain in error message #127

trampster opened this issue Jun 17, 2021 · 6 comments

Comments

@trampster
Copy link

I have have an error as follows:

Error while resolving dependencies for 'Pttox.Core.ViewModels.GroupPttViewModel': We have no source for instance of type 'Xamarin.Forms.Page?'

GroupPttViewModel doesn't have a direct dependency on Page, and GroupPttViewModel's depedency tree is quite large so finding the things that needs Page is hard.

Searching the code for Page is hopeless because it's a Xamarin.Forms app so page is everywhere.

Would it be possible to make the error message include the full dependency chain, or at least include the type that has a direct dependency on Page.

@trampster
Copy link
Author

trampster commented Jun 18, 2021

I just had another one.

Error while resolving dependencies for 'Pttox.Forms.Views.AppShell': We have no source for instance of type 'UIKit.UIViewController'

This is particularly confusing, as I only have a handful of iOS specific services and none of them have a dependency on UIKit.UIViewController, in fact the text UIViewController doesn't exist anywhere in my solution.

Pttox.Forms.Views.AppShell is defined in the shared project

Here are a list of the types registered in my iOS module

  • PlatformIos - only has a default constructor (so no dependencies)
  • ImageService - only has a default constructor (so no dependencies)
  • SqliteConnectionFactory - only has a default constructor (so no dependencies)
  • ConnectivityServiceIos - only has a default constructor (so no dependencies)
  • PttoxClientConfigSetupIos - only has a default constructor (so no dependencies)
  • UserPresenceServiceIos - only has a default constructor (so no dependencies)

I have the following factory

  • ILogger (only depends on a service from the shared project)

@YairHalberstadt
Copy link
Owner

So I do actually include the whole message in the diagnostic - as a description, which unfortunately visual studio doesn't display:

dotnet/roslyn#46911

I could move it out of the description, but that would make the messages way too long I think. Perhaps I could add an MS build property to show full path.

@trampster
Copy link
Author

trampster commented Jun 18, 2021

Is there anyway for me to get at this diagnostic info? It doesn't seem to be in the output info under Build.

I also tried changing the 'MSBuild project build output verbosity' to 'Diagnostic' but that didn't work either.

@YairHalberstadt
Copy link
Owner

YairHalberstadt commented Jun 18, 2021

At the moment I don't think so (other than compiling the project using Roslyn directly and accessing the diagnostic). If the diagnostic appears in intellisense (which another Roslyn bug prevents) you can expand it in visual studio, but not if it comes from build.

@trampster
Copy link
Author

trampster commented Jun 18, 2021

I think that UIKit.UIViewController is used internally by Xamarin.Forms to render a page on iOS. In our app AppShell is responsible for getting and displaying the Xamarin.Forms pages.

So it is probably trying to create a Xamarin.Forms view and somehow StrongInject has been fooled into trying to resolve UIViewController I'll try and create a minimal Xamarin.Forms. iOS project to demonstrate the problem.

@trampster
Copy link
Author

I finally managed to track down the UIViewController dependency issue (by removing dependencies until it started working)

We use a barcode scanner library called ZXing.Mobile. It has an interface IMobileBarcodeScanner which needs to be resolved to MobileBarcodeScanner. In the shared .Net standard project this only has a default constructor but in an iOS project it has a constructor taking a UIViewController. (I assume this is using the old bait a switch cross platform method)

So when I build the iOS project it tries to resolve using the constructor that takes a UIViewController. Even through that constructor does not exist in the shared project in which it is registered.

I have worked around this issue by defining a Factory which calls the default constructor.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants