Visual Studio and .NET Framework Home
MSB3247 warning message should include referencing assemblies
4/3/2008 2:10:31 PM
User(s) can reproduce this bug
I recently spent several days, and ultimately involved MS tech support, to figure out why I was getting warning MSB3247 ("Found conflicts between different versions of the same dependent assembly"). This warning happens when two or more assemblies in the same project reference different versions of a third assembly.
The warning tells me the name of the referenced assembly, but it doesn't give a clue as to the underlying cause of the problem (that is, it doesn't tell me which assemblies are referencing the different versions of the same assembly).
Ultimately, the tech support engineer and I had to resort to using ildasm to examine assembly manifests to figure out which assemblies in my project were causing the problem. This whole issue could have been avoided if the warning message had told me which assemblies were causing the problem in the first place.
Visual Studio 2005 (All Products and Editions) Service Pack 1
Windows XP Professional
Operating System Language
Steps to Reproduce
Create a solution with three library (DLL) projects, A, B, and C.
A exposes method ATest()
B exposes method BTest(), which calls ATest
C exposes method CTest(), which calls both ATest
C also exposes method CTest1(), which calls BTest
Strong name sign the whole mess, build it, and copy the 3 DLLs to C:\Temp
Change the assembly version in project A, and rebuild it again. This time, copy A.DLL and C.DLL (but NOT B.DLL) to C:\Temp
Just to add to the confusion (and to reproduce the problem I actually encountered), install A.DLL in the GAC.
Create a new Windows Forms project name D.EXE in a new solution. Give that project "copy local" references to C:\Temp\A.DLL and C:\Temp\C.DLL
In the new Windows Forms project, call A.ATest and C.CTest.
Build the Windows Forms project.
The Windows Forms project gets local copies of A.DLL and C.DLL, and it runs correctly. But it gets a cryptic MSB3247 warning referring to A.DLL in the GAC, which really has nothing to do with the problem.
The MSB3247 warning should clearly tell me that X.EXE and B.DLL reference different versions of A.DLL.
Note: X.EXE doesn't directly reference B.DLL. B.DLL is referenced by an unused function in C.DLL. In my tech support case, I didn't even realize that I was (indirectly) referencing B.DLL until we went digging with ildasm.
TAP Code (if applicable)
You can indicate your satisfaction with how Microsoft handled this issue by completing this quick
3 question survey
to post a comment.
Please enter a comment.
on 8/5/2013 at 6:37 AM
This is not fixed at all in vs 2010, 2012...
on 9/11/2008 at 9:47 AM
The next version of MS Build, which will ship together with the next version of the CLR and Visual Studio, will have the fix for this scenario.
Thanks for your feedback!
on 4/8/2008 at 11:22 AM
Thanks Izzy. The diagnostic messages were the reaason I posted this issue in the first place. They clearly tell me which assembly is multiply referenced, but they don't tell me who the culprits are that are referencing different versions of that assembly. Ultimately, that is the information that a developer needs to fix the problem identified by the warning.
on 4/7/2008 at 7:12 PM
Thank you for your feedback. While we certainly don't do much verbosity in the tasklist, you can get the level of verbosity you need to diagnose the issue by looking at the output window. To do this, follow these steps:
 Bring up the Tools/Options dialog (Tools->Options...).
 In the left-hand tree, select the Projects/Solutiosn node, and then select Build and Run. Note: if this node doesn't show up, make sure that the checkbox at the bottom of the dialog ("Show all settings") is checked.
 In the tools/options page that appears, select the MSBuild project build output verbosity level to "Diagnostic."
 Build the project and look in the output window.
MSBuild will have spewed out a lot of diagnostic messages. The ResolveAssemblyReferences task, which is the task from which MSB3247 originates, is probably our best task for logging diagnostic information -- those logging messages should help you debug this particular issue. Please reactivate the bug and let us know if they do not help.
Lead Software Design Engineer
Microsoft Visual Studio Platform Development
on 4/4/2008 at 3:35 AM
Thanks for your feedback. We are escalating this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Visual Studio Product Team
to post a workaround.
Please enter a workaround.
© 2014 Microsoft