Provide Diagnostic Items as part of Package Dependency Resolution task

[natidea]

Diagnostics. In some cases when your task can detect error or warning for some packages, it should send diagnostics associated with that package. For example:

• Package is unresolved, we used to have an error
• Version was unified , we used to have a warning

Here is a full list of diagnostics we had (not all of them are applicable to lock file): https://github.com/dotnet/cli/blob/rel/1.0.0/src/Microsoft.DotNet.ProjectModel/ErrorCodes.NuGet.cs

• [ ] Diagnostics should be another item type and following your data schema we should have new collections DiagnosticsDefinitions, and DiagnosticsDependencies, which would associate diagnostic messages with packages. ItemSpec could be TFM/package/version/, with metadata “Message” and “Type” (error or warning)
• [ ] Each package might have multiple diagnostics at the same time: errors and warnings.
• [ ] Diagnostics will be displayed under package in the tree
• [ ] Also diagnostics should be displayed in the error list as Intellisense errors. I am not sure if Dependencies Tree should be the one pushing them to error list or not, but I can do that too.
• [ ] It might not be a pri 0 workitem to make diagnostics work right now, but we at least need a schema ready , just return empty for now. I would already made Tree to be aware or them.

[natidea]

It appears unresolved packages are not in the project.assets.json (project.lock.json) and will need to be added in order to create a diagnostic

[brthor]

The cli ProjectModel would determine this by comparing the projectFileDependencyGroups in the lock file section with the actual resolved dependencies.

https://github.com/dotnet/cli/blob/rel/1.0.0/src/Microsoft.DotNet.ProjectModel/Graph/LockFile.cs#L35

[eerhardt]

Won't the "restore" fail when a package is unresolved?

[abpiskunov]

restore would fail , but lock file should still be generated. Yes, we could do same thing what ProjectMOdel did.

[davidfowl]

Here are the list of diagnostics:

• NuGet - https://github.com/dotnet/cli/blob/d7b0190bd4ce49121a7cd5bdc0423ab85229a085/src/Microsoft.DotNet.ProjectModel/ErrorCodes.NuGet.cs
• DotNet - https://github.com/dotnet/cli/blob/d7b0190bd4ce49121a7cd5bdc0423ab85229a085/src/Microsoft.DotNet.ProjectModel/ErrorCodes.DotNet.cs

Here's where we created them (if that's relevant)

• Build without restore - https://github.com/dotnet/cli/blob/d7b0190bd4ce49121a7cd5bdc0423ab85229a085/src/Microsoft.DotNet.ProjectModel/ProjectContextBuilder.cs#L310

• Asset file/lock file invalid (dependencies updated without running restore) - https://github.com/dotnet/cli/blob/d7b0190bd4ce49121a7cd5bdc0423ab85229a085/src/Microsoft.DotNet.ProjectModel/ProjectContextBuilder.cs#L319

• Reference assemblies not found (common when building on mono) - https://github.com/dotnet/cli/blob/d7b0190bd4ce49121a7cd5bdc0423ab85229a085/src/Microsoft.DotNet.ProjectModel/ProjectContextBuilder.cs#L334

• Framework not installed (.NET Framework Reference assemblies) - https://github.com/dotnet/cli/blob/d7b0190bd4ce49121a7cd5bdc0423ab85229a085/src/Microsoft.DotNet.ProjectModel/ProjectContextBuilder.cs#L349 PS: We need to do this same thing for shared runtimes on .NET Core

• Dependency diagnostics:

• Unresolved dependency - https://github.com/dotnet/cli/blob/d7b0190bd4ce49121a7cd5bdc0423ab85229a085/src/Microsoft.DotNet.ProjectModel/Resolution/LibraryManager.cs#L58

• Incompatible dependency - https://github.com/dotnet/cli/blob/d7b0190bd4ce49121a7cd5bdc0423ab85229a085/src/Microsoft.DotNet.ProjectModel/Resolution/LibraryManager.cs#L64

• Dependency mismatch - https://github.com/dotnet/cli/blob/d7b0190bd4ce49121a7cd5bdc0423ab85229a085/src/Microsoft.DotNet.ProjectModel/Resolution/LibraryManager.cs#L121

• **Single "type:platform" dependency*** - https://github.com/dotnet/cli/blob/d7b0190bd4ce49121a7cd5bdc0423ab85229a085/src/Microsoft.DotNet.ProjectModel/Resolution/LibraryManager.cs#L144

• Dependency conflicts - https://github.com/dotnet/cli/blob/d7b0190bd4ce49121a7cd5bdc0423ab85229a085/src/Microsoft.DotNet.ProjectModel/Resolution/LibraryManager.cs#L175

Plumbing

• Diagnostics triggered squiggles in the files where they occur. This means that project.json showed red squiggles for errors and green for warnings etc.
• They show up in the error window in the appropriate section and are updated as appropriate the file is edited. They do NOT require a new build to show up.
• They show up in the solution explorer on a per dependency basis if the diagnostic applies to a specific dependency (https://github.com/dotnet/cli/blob/d7b0190bd4ce49121a7cd5bdc0423ab85229a085/src/Microsoft.DotNet.ProjectModel/DiagnosticMessage.cs#L130)
• They show up on build from the command line or in the IDE. dotnet-compile had logic that printed out these errors on build https://github.com/dotnet/cli/blob/d7b0190bd4ce49121a7cd5bdc0423ab85229a085/src/dotnet/commands/dotnet-compile/Compiler.cs#L135-L182.
• VS code used the same system to show errors in the right places (and I imagine VS for Mac will as well).

Once a system like this is in place and going to all the right places and all the right editors and command line experiences, it becomes trivial to add new ones.

/cc @emgarten @rrelyea

[dsplaisted]

@natidea I think some of these diagnostics will be covered by the work you are doing for #1026

[livarcocc]

I believe these have been addressed. So, I am closing this item. @natidea, if there is anything missing, please, re-activate and let us know what you need from SDK.