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.
Related
I get two warnings at the cpp compile phase with all the stan programs that I submit.
C:/Larry/R/win-library/3.4/BH/include/boost/config/compiler/gcc.hpp:186:0: warning: "BOOST_NO_CXX11_RVALUE_REFERENCES" redefined # define BOOST_NO_CXX11_RVALUE_REFERENCES
and
cc1plus.`exe: warning: unrecognized command line option "-Wno-ignored-attributes"
Since I don't get these warnings in submitting other Rcpp programs, I suspect that they are generated in the course of gc++ compiling of the Stan program. They seem to be harmless, but they are disconcerting. I see many other messages on Stack Overfkiw that include these warnings, but I have not found any explanations of them, nor ways to correct what is producing these warnings.
I am running R 3.4.3 and RStudio 1.1.383 in Windows 10 with Rtools 3.4.0.1964. I'd be grateful to anyone that will explain these warnings to me and what I have to do to correct them.
Don't worry about either of those.
The first is telling you that it redefines that Boost thing, but it is redefining it to what it was already set to.
The second is avoidable if you take -Wno-ignored-attributes out of the CXXFLAGS line of your ~/.R/Makevars file. It applies to a different compiler or version or something and is being ignored.
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
We are trying to use grunt-lesslint in our project, as our UI developer is comfortable fix errors in less file. grunt-recess seems more powerful but not sure if it can point errors in less file itself. I am unable to comprehend enough from lesslint page, and there do not seem to be many examples. Does anyone know the following:
How to prevent lesslint from displaying on the console. I use formatters and the report file is generated, but it also prints on console, which I do not want to.
How to make lesslint fail only in the case of errors (not warnings). Also csslint seems to report errors also, while lesslint mostly gives warnings only, why is that so? Does lesslint throw errors as well? How to make it fail only in case of errors?
I tried using 'checkstyle-xml' formatter, but it does not seem to use it (I have used in jshint and it gives a properly formatted xml, which it does not give for lesslint).
Is it possible to compile less (many files or directories) in conjunction with lesslint? Any example?
Thanks,
Paddy
I'd say it's more of a common practice to display stdout for this kind of thing; the JSHint plugin does it, as does any other linting plugin that I've used. If you get in another developer that uses Grunt they'll probably expect stdout too. If you really want to override this, use grunt-verbosity: https://npmjs.org/package/grunt-verbosity
Again, this is a convention in Grunt; if a task has any warnings then it fails. The reason being if you lint a file and the linter flags something up it should be dealt with straight away, rather than delay it; six months time you have 500 errors that you haven't fixed and you're less likely to fix them then. Most linting plugins allow you to specify custom options (I've used CSS Lint and that is very customisable), so if you don't like a rule you can always disable it.
This should work. If there's a bug with this feature you should report it on the issue tracker, where it will be noticed by the developers of the plugin. https://github.com/kevinsawicki/grunt-lesslint/issues
Yes. You can set up a custom task that runs both your linter and compile in one step: something like grunt.registerTask('buildless', 'Lint and compile LESS files.', ['lesslint', 'less']); note that you'll have to install https://github.com/gruntjs/grunt-contrib-less to get that to work. Also note that, failing linting will not compile your LESS files; mandate that your code always passes the lint check; you'll help everyone involved in the project.
I'm pretty new to MSBuild, so I might be doing something obviously-wrong, but a colleague of mine who's worked with MSBuild a lot can't see any error, so I figured I'd post here and see if anyone else can see it.
I'm converting an old batch file that we used to call ant to MSBuild tasks (because we want to call it from MSBuild) and the environment variables always expand to )for reasons we don't understand.
I have a property group that includes
<PropertyGroup>
<EnvJavaHome>
$([System.Environment]::GetEnvironmentVariable("JAVA_HOME"))
</EnvJavaHome>
<!-- ... -->
</PropertyGroup>
(line breaks added for legibility). Now the MSBuild Property Functions reference suggests I'm calling System.Environment.GetEnvironmentVariable correctly, but I always get a value of ). The code works perfectly well when I hardcode the value, however.
What obvious thing am I missing? :o)
If it's an env variable, you should be able to just use it like $(JAVA_HOME)
as in <EnvJavaHome>$(JAVA_HOME)</EnvJavaHome> , see e.g. use http://msdn.microsoft.com/en-us/library/ms171459(v=VS.100).aspx
(Check that the environment variable actually exists though, echo %JAVA_HOME% in a command window)
I'm working in an embedded system (RTXC) where I need to disable the debugger functionality which is enabled through a #define command. However, when I change the #define to undefine, compilation goes off fine, but when the linker runs, it encounters an error about a symbol not existing that belongs to the debug code (which should have been taken care of by the debugger variable not being defined). Is there any way for Make to ensure that a preprocessor variable does not get defined or stays undefined ?
The answer to your question is no, Make can't absolutely prevent a variable from being defined by, say, a #define expression in the code.
You seem to have an elusive problem. It could be a bug in your Makefiles, a misspelled directive, a bad macro (if you'll pardon the tautology) or something trivial. I'd suggest burning the forest: cut out everything until the problem stops, then see where it was hiding. If you get down to HelloWorld and the problem persists, let us know.
No. You will need to fix the bug in your code.
More specifically, there is something that is referencing the debug side of things outside of an #ifdef. Make won't be able to help you there.
Another possibility is that you have a .o or something left over from a previous build; you might want to try cleaning the build tree.