List conflicts in MSB3277 reference-version-conflict message #608
Comments
|
We discussed this in triage this week. We're in favor of clear, actionable error messages, but since the information is just a rebuild with |
|
It seems like the information might be available, but just not logged: https://github.com/Microsoft/msbuild/blob/72c12de51702f7e214f1eba481f2f3f93b885616/src/XMakeTasks/AssemblyDependency/ResolveAssemblyReference.cs#L1039-L1042 |
cdmihai
added
the
help wanted
|
This error message has been the bane of .NET developers for years. Having worked on assembly resolution for ~6 years in the BCL team, I've diagnosed so many of these warnings for customers, and there's three issues that I see with it:
Here's a typical log: Note the warning states: But really the relevant portion is 1#: and 2# We should promote 1# or something like it as the root message, and 2# as a nested message under the warning. VS will now hide by default messages that too long or contain multiple lines, and let the user expand to see more detail. |
|
Could we perhaps have an option to right click on the warning and select something like "Generate Binding Re-directions in Config" then if msbuild was to honor those redirections as "the will of the developer" then conflicts can be deemed to have been at least thought about and a solution provided. |
|
@TehWardy Good suggestion. I think that is a really good first step. |
|
At the risk of sounding like a noob, how the heck do we fix this and since my projects seem to be compiling and working is this a serious issue? When I look at the internal diagnostic log it doesn't look like anything I have added. Seems like its multiple NuGet packages fighting with one another. |
|
@ewahner It's basically a resolution in the build process / compiler where it finds multiple versions of a given assembly / doesn't find the thing it expects in some default location. The issue here of course is that resolving this problem properly is quite complex and actually requires a developer to make a decision but putting assembly redirection directives in the config file for the assembly you are building should resolve it. In short: |
|
Just hit one of these for the first time. This issue helped me find it at least. +1 I guess |
|
Thank you @davkean for your initial words on this frustrating issue. I have devs in VS Code who can't focus on actual warnings that matter due to this. It used to be just the devops issue but clean coders obsess over the build log. How can we lessen the noise in VS2017 or VS Code on this error? TIA. |
|
From reading the source for Instead of generating a single warning that contains no specifics (the current behavior), generate a separate warning message for each distinct reference conflict. For example: I've generally found that knowing the name of the conflicting assembly has been enough to track down the problem and address the issue. All of the existing diagnostics would still be available in the detailed log if required, and I believe all of the information required for this change is already available within the If this is an acceptable modification, I'm willing to have a go at making the change and creating a PR - but didn't want to dive in if there's another/better fix already underway. |
|
@theunrepentantgeek that could be the key if the message included the project names that had the conflict too. The key to solving this is knowing project + reference I believe. |
|
Conflicts don't always stem from a direct project reference - sometimes there are intermediate dependencies on the path - this is why it's not always straightforward to solve.. That said, I'll have a look at what other information is on hand in |
|
Yeh the trick is figuring out the root project in a tree I guess ... The ones that's the "app" is likely to be the one that needs something like binding redirection that would solve it for all of the projects compiled in to its build output directory. Hence my suggestion above about making this process as painless to resolve as possible (with a simple right click). As you say ... All the information is there right! |
|
Please fix this. Opened over two years ago. |
|
Well- opened 1.5 years ago unless I'm missing something. |
|
@jnm2 you're correct. 1.5 years ago. Still not good this has not been addressed. |
|
@theunrepentantgeek did #2379 which prints the name of the conflicting assembly. Let us know the extent to which this helps you diagnose and fix conflicts. The change should be in the 15.5 previews. |
|
@cdmihai looking forward to VS 15.5 RTM. |
|
Well, as a noob, that fix is great for me!! |
|
On this topic... once you have a project with MSB3277 warnings... what are the next steps? Is there any formal guidance on this topic? In my case, I have a UWP app with a number of NuGet package dependencies, and building it raises a number of these warnings. However, I'm not entirely sure what to do to address the problem, since my NuGet packages are generally up to date. Is there even a problem? Thanks. |
|
Using VS 15.7 and still seeing these warnings in one of our UWP solution. No idea, where or how to fix this: Edit, the problem was caused by referencing MvvmLightLibs NuGet v5.3.0 in our UWP app targeting MinVersion 10.0.14393 and TargetVersion 10.0.17134. The MvvmLight dll was built as PCL library, referencing different 'System' types. |
|
@martinsuchan as stated above ... the fix is to add binding re-directions to your config files "manually" ... |
|
@StingyJack that' the good version of this problem ... if I recall you should be able to just double click on that and it'll dump that XML blob in to your config file. |
|
@TehWardy except that maybe a years of users testing code built from projects that exhibit the wall of warning leads me to believe that they are false positives. |
|
The issue is what the build process sees vs what actually gets deployed ... I would think that the reason your testers aren't finding anything is that you either don't use those edge cases in the dependent libs or they have an incomplete test case suite. |
|
This happens when reffing a netstandard2.0 assembly from a 4.6.2 project. |
|
@StingyJack Windows 7 is gone in January. Assuming everyone is on Windows 10 at that point, which forces you to stay up to date within at most a year, everyone has 4.7.2 already and soon 4.8 will be the new baseline. |
rainersigwald
modified the milestones:
MSBuild 16.5 Preview 3 (Sprint 165),
MSBuild 16.6 Preview1
rainersigwald
modified the milestones:
MSBuild 16.6 Preview1,
MSBuild 16.6 Preview 2,
MSBuild 16.6
@rainersigwald - you mean its just an opening of Tools -> Options, then Projects and Solutions -> Build and Run, then select the Diagnostic option for the two verbosity options, click OK, then rebuild , and then sift through 10's of thousands of lines of log output (if not more) to find the problem source? Thats a total PITA compared to the message just telling us what the problem is. Why make your customers work so much when its possible for you to improve their experience with this cryptic and questionable warning? At least this used to explains how to find the source. I see this has been changed at some point and now we dont get that instruction, and instead get a message like... ... for projects that have that flag set to True in the project file. |
This warning previously indicated to people that there were conflicts, but they were confused because it did not specify how th conflicts came into their project. Although they could build again with diagnostic logging, many customers still had trouble finding the relevant information in the log. This change makes it so the relevant information is printed along with the warning message when relevant without adding (almost any) extra overhead in the normal case. Fixes dotnet#608
This warning previously indicated to people that there were conflicts, but they were confused because it did not specify how th conflicts came into their project. Although they could build again with diagnostic logging, many customers still had trouble finding the relevant information in the log. This change makes it so the relevant information is printed along with the warning message when relevant without adding (almost any) extra overhead in the normal case. Fixes dotnet#608
This warning previously indicated to people that there were conflicts, but they were confused because it did not specify how th conflicts came into their project. Although they could build again with diagnostic logging, many customers still had trouble finding the relevant information in the log. This change makes it so the relevant information is printed along with the warning message when relevant without adding (almost any) extra overhead in the normal case. Fixes dotnet#608
This warning previously indicated to people that there were conflicts, but they were confused because it did not specify how th conflicts came into their project. Although they could build again with diagnostic logging, many customers still had trouble finding the relevant information in the log. This change makes it so the relevant information is printed along with the warning message when relevant without adding (almost any) extra overhead in the normal case. Fixes dotnet#608
This warning previously indicated to people that there were conflicts, but they were confused because it did not specify how th conflicts came into their project. Although they could build again with diagnostic logging, many customers still had trouble finding the relevant information in the log. This change makes it so the relevant information is printed along with the warning message when relevant without adding (almost any) extra overhead in the normal case. Fixes dotnet#608
Always log conflict information in MSB3277 Fixes #608
This is to keep track of this feature request from Connect: http://connect.microsoft.com/VisualStudio/feedback/details/2619450/unclear-warning-msb3277-found-conflicts-between-different-versions-of-the-same-dependent-assembly-that-could-not-be-resolved
This message is emitted in ResolveAssemblyReferences.
The text was updated successfully, but these errors were encountered: