After I have fixed this warning, how can I make it an error, so it doesn't slip in again?
msbuild /p:TreatWarningsAsErrors doesn't work
No happy answer to give you here. The TreatWarningsAsErrors property only affects the C# and VB.NET compiler (not C++), it determines the value of their /warnaserror command line option.
But MSB3277 is generated by an MSBuild task, ResolveAssemblyReference, its internal LogResult() method generates the diagnostic. The only property the class has that helps treat warnings as errors conditionally is WarnOrErrorOnTargetArchitectureMismatch, not what you are trying to achieve. You can have a look-see for yourself with a decompiler, look at C:\Program Files (x86)\MSBuild\12.0\Bin\Microsoft.Build.Tasks.v12.0.dll. The resource name for the localized MSB3277 message is "ResolveAssemblyReference.FoundConflicts".
So only way to get ahead here is to write a little utility that parses the log file and looks for the warning.
You can use the generic mechanism MSBuildTreatWarningsAsErrors or <MSBuildWarningsAsErrors>MSB3277</MSBuildWarningsAsErrors> (introduced in #1928) to accomplish this.
credit: rainersigwald
Run Update-Package via Package Manager Console, this will fix MSB3277, what it does it reinstall all the packages and all related assemblies they come with to the highest version possible.
More info on official docs https://learn.microsoft.com/en-us/nuget/consume-packages/reinstalling-and-updating-packages
It looks like the /warnaserror will promote all msbuild warnings to errors:
TreatWarningsAsErrors vs /warnaserror
Related
I am trying out NDepend (2018.2.0) but I am stuck early with this one and I am receiving an error for reasons that don't appear to be true.
After install NDepend and starting VS 2015:
Add Assemblies From VS Solution
I select the sln file
Projects from the sln are all loaded.
I "Run Analysis" and while running, I see this:
Then I receive error:
The Code to Analyze and Paths Referenced check out. And there are no errors in the Analysis Error List panel:
Any ideas?
The solution is to install version, 2018.2.1 or later which address the bug referenced in #Patrick from NDepend team's comment.
The expected behaviour is something like this while the analysis is running:
And when it finishes, the bad news looks like:
At which point the, the fire-hose of data and metrics becomes available.
I'm getting a "Compilation exited with code 134" when attempting to use the "LLVM Optimizing Compiler" switch for release iPhone builds, using MonoTouch 4.0.1.
I don't get much information from build output window at all - just:
"Compilation exited with code 134, command:"
MONO_PATH=(snip)/bin/iPhone/Release/LSiOS.app /Developer/MonoTouch/usr/bin/arm-darwin-mono --llvm --aot=mtriple=armv7-darwin,nimt-trampolines=2048,full,static,asmonly,nodebug,llvm-path=/Developer/MonoTouch/LLVM/bin/,outfile=/var/folders/03/033pAAGuHgGkIy4CorbVV++++TI/-Tmp-/tmp38107451.tmp/Newtonsoft.Json.MonoTouch.dll.7.s "(snip)/bin/iPhone/Release/LSiOS.app/Newtonsoft.Json.MonoTouch.dll"
Mono Ahead of Time compiler - compiling assembly (snip)/mscorlib.dll
What is odd is that in earlier command lines, there is a correlation between the DLL mentioned in the arm-darwin-mono command line and what is the compiling, but in this case it says "mscorlib.dll".
Any thoughts?
I have found a few cases (googling and from bugzilla.xamarin.com) where the error code 134 is related to Mono.Linker being too aggressive (removing something that's needed).
This is easy to confirm by turning off the linker, i.e. "Don't link" in Linker Options. If the build works then you can try isolating the assembly where the linker makes a mistake.
E.g. add a "--linkskip=mscorlib" to the mtouch extra parameters and re-enable linking. This will link everything (Link All) or all SDK (Link SDK assemblies) except the assembly you selected (mscorlib in the example). That's only a workaround and a bug report should be filled so the issue can be fixed properly (and get you all the linker advantages).
However be warned that there are other issues sharing the same error code, like:
http://ios.xamarin.com/Documentation/Troubleshoot#Error_134.3a_mtouch_failed_with_the_following_message.3a
YMMV
mtouch does its native builds in parallel so the logs can be confusing, e.g. you can see a bit of assembly X output followed by some assembly Y output.
Reading the full log might help you (or us) to pinpoint the issue.
I was having the exact same problem Scolestock. My app would build fine until I enabled llvm, then it was "Compilation exited with code 134, command" when trying to build the 7s for the app itself.
I'm elated to say that after 2 days of painstakingly whittling my app down to the core problem, I was able to isolate the issue to the usage of embedded dictionaries such as:
Dictionary<enum, Dictionary<enum, value>>
I was able to fix this by defining a class for the embedded dictionary and using that instead:
public class MyDefinition : Dictionary<enum, value>
{
}
...
public Dictionary<enum, MyDefinition>
Not sure if this will help you, but hopefully it'll help some poor soul who decides to use embedded dictionaries and runs into my same problem.
This has been asked, but wasn't answered. The answer (use /warn:1) doesn't work for msbuild.exe, only csc.exe. Perhaps I'm missing something between csc and msbuild?
I'd like to suppress all compiler warnings and code analysis warnings (e.g. "The variable 'variableNameHere' is assigned but its value ..." or Code Analysis Warning : CA1805 : Microsoft.Performance : ...) when I'm using command line msbuild. I don't want to alter the solution file. There are several hundred warning messages in the very large solution that I'm building -- fixing them is far out of scope for my project.
I tried /v:quiet but that didn't work.
Is there any way to do this via the command line?
Update: this:
C:\WINDOWS\Microsoft.NET\Framework\v3.5\msbuild.exe C:\Dev\ReallyBigSolution.sln /p:NoWarn=true /p:NoWarn=CA1031
Absolutely doesn't work. I still get hundreds of warnings, including the one I specifically blocked (CA1031).
Using /p:RunCodeAnalysis=Never or /p:RunCodeAnalysis=false apparently doesn't suppress code analysis warnings or errors.
Can use nowarn flag on the compiler, which corresponds to <NoWarn> property in the .csproj file. So maybe msbuild /p:NoWarn="37;68" will turn off those warning numbers (haven't tried it).
Or use
http://msdn.microsoft.com/en-us/library/13b90fz7.aspx
to turn off warnings altogether. I don't know the property name offhand, try /p:Warn=0.
Edit: read the comments toward the end; seems like really getting rid of all these warnings isn't possible.
I know this is an old post but it got me on the right track and by adding the following to my msbuild call it suppressed all of the warnings and output as it built the project. I have this in a batch file so the only output I get I believe are the end results and any messages I prompt with echo. The secret was in the /clp switch. So I looked that up and put in all of the ones that supress output. Each one got rid of more but there were still the yellow warnings coming up and when I added the ErrorsOnly switch, there was no more output.
call msbuild /clp:NoSummary;NoItemAndPropertyList;ErrorsOnly /verbosity:quiet /nologo
Try this:
msbuild.exe C:\Dev\BigSolution.sln /p:WarningLevel=0 /p:RunCodeAnalysis=false
I have tried this and cannot suppress the warnings either, unless I list them out on the /NoWarn property for msbuild.exe
http://social.msdn.microsoft.com/Forums/en-US/tfsbuild/thread/96b3ea2e-92ed-4483-bbfe-a4dda3231eb9
According to this, it cannot be suppressed.
Looks like it is not possible...
Warnings with MSB prefix are thrown by
MSBuild. Currently, we can't suppress
MSBuild warnings.
I have a VB.Net solution that another developer created and I'm trying to compile it on our build machine (it compiles on their machine) but with one of the projects I get an error saying something along the lines of:
Imyinterface is ambiguous in the namespace anamespaceassembly.
I have tried with no success:
examined the references to see any obvious errors
removed and re-added the assembly in question
searched the system for the same dll
attempted to compile the original deve's src (.v the source control version)
examined the assembly with ildasm.exe
I usually code in C# and have not seen this error before (in this form at least), not that it is VB.Net specific but the UI for adding/viewing references is slightly different so I thought maybe VB.Net might do something different with references.
I also tried to compile on another machine, and it compiles ok. So I assume it is something with the build machine but I'm not sure what. Other conflicting assemblies somehow not referenced by the project, is that possible??
Any ideas?
Check your references if you have two versions of the same reference (eg. Microsoft.ReportViewer.Webforms version 10.0.0.0 and Microsoft.ReportViewer.Webforms 8.0.0.0) You will get this error. Delete the oldest and you should be good. I do this to myself all of the time.
There can be a few causes for this error. In VB, you should be aware that more names then you're used to from C# are available without class specification. Also, case does not matter in VB, which can further liken the chances on collisions.
Even in the event that you don't find the actual conflicting issue, you can resolve this in the same way you would in C#: rename it in the Imports statement:
Imports IM = yourAssembly.Imyinterface
Then change the code such that uses of Imyinterface are replace with IM.
NOTE: If the error does not point to a particular line, the conflict may be out of your hand. Normally, a full Clean Solution and Rebuild helps a lot, but occasionally a misbehaving file (i.e., another error) causes this error to popup first without clear source. Try to rollback recent changes to the place where it did work.
You also say it worked on another machine. Chances are that your machine is having a different version of MS Visual Studio or .NET. Check and compare the exact versions.
I was facing same issue. I upgraded my application from vb6 to vb.net and when i change the build configuration from DEBUG to RELEASE then i got AMBIGUOUS errors.
I found dulicate references folder in solution Explorer. I removed those duplicate referecnces and Build sucessfully. I Hope it may help others.
Thanks for the responses! I tried each but still was having issues.
One point of info I left out of the original question was that the VB.net projects are upgrades from VB6 projects. At the time I did not think that was relevant.
After investigating further the build machine was used to build the VB6 projects also. So I ran 'reg32 /u' on the vb6 dlls and that seemed to fix the VB.net issue.
Not exactly sure why this fixed it since I was not referencing the VB6 dlls, I'm guessing something to do with ambiguous entries in the registry confusing the vb.net project.
I've got a really strange error and any light that anyone can shed on this would be greatly appreciated.
I made some changes to some VB6 source which builds a COM object. The automated build which builds our app returned an error. No problem I thought--I'll just back out my changes. Well backing out my changes isn't making the problem go away.
Specifically when I attempt to build the app via a .vbg file, with a command line like path\to\vb6\vb6 ProjectFile.vbg /make
I get a message
"Compile Error in File '', Line : Object library
invalid or contains references to object definitions that could not be
found."
As I said, I reverted the source code so I'm really stumped as to why this error is still occurring. Any VB6 gurus around who might be able to point me at an answer?
I can post the exact code in question but the fact that it was building correctly, stopped building correctly and now refuses to build correctly makes me think this is not a problem with my code but rather some problem in the environment. Like something got put in the registry as a result of the previous build error.
Any tips, hints, or suggestions greatly welcome. I realize my question is a bit sketchy but I'm not even sure what's important to include and what isn't.
EDIT 1:
Thanks for the excellent suggestions guys. I think it is something to do with VB6 doing some sort of auto-registration.
Just to add a bit more detail: this problem does not occur when I build the referenced vbp file from the IDE. It only happens on the make on the .vbg which contains the vbp. Also the build tool in question automatically pulls latest source and the error happens on both my local box and the dedicated build box.
EDIT 2:
Hi again all,
The release engineering fellow figured out how to get this to build in his build environment so it's currently ok. Once we're past this crunch, I'll try to interrogate him about what he did and share the details with everyone.
Thanks again for all the great suggestions. This is what's so great about SO; that is, I asked about a 10-year-old technology and I got several great and on-point ideas.
Make sure that the VBG and all the VBP's got rolled back as well. That error is consistent with a project trying to reference a CLSID that is no longer valid for the dependency. Have you tried loading up the project group and building from the IDE, if that works and you save and check in all the changes to the group and project files, you might be fixed up.
I'm guessing the fact that you mention that it was a COM component might be the source of the problem. If any of the public method's or properties have changed then I seem to remember that VB6 will change the interface GUIDs and auto register the new ones.
My suggestion would be to check the registry to look for any mention of the component name, make a note of any associated CLSIDs, back up the registry, and then delete the references.
As cmsjr mentions it could also be a bad CLSID reference in your .vbp files.
The other option is that the failure has caused a problem with some .tlb (type library) or olb (object library) files.
The best thing to do is move all your compatibility DLL to a separate and combined directory. The reason for this is control over what VB6 is using to check for binary compatibility. In addition the Typelibs that are generated IMPORT the references. So if you using Binary DLL Ver 10 for compatibility however the import is pulling in Binary DLL Ver 9 you will have issues. By keeping all the libraries in a single folder and pointing your projects to the DLLs in that folder you ensure that the respective TypeLib Import the correct version.
Finally if you have multiple levels of DLL reference each other. You may run into mysterious error where the VB6 is unable to compile using binary compatibility. In such cases you need to compile the lowest DLL in the hierarchy (Utility DLL perhaps) copy it over into the compatibility folders. Work your way up the chain until everything compiles in one shot again.
This is because if have DLL A reference DLL B which Reference DLL C. VB6 will get sometimes get confused if you make a change to A and C. will compile fine but A will not until the compatibility libraries are updated.
Hunt down and delete any .obj and .exp files that may be lying around from the previous failed build.
You will have to open the project & re-type in the lines that you changed.
Save the project alongwith VBG and re-compile after that.
I think that will fix it.
EDIT: The idea is that the cls/bas file remember the class (CLSID) that you used. So, if you change the references but don't change the lines in the cls/bas - it is a mismatch of type (what was referenced vs what is typed in cls/bas file).