I can't seem to be able to suppress warnings in my solution in Visual Studio 2017 by going into Project Settings > Build > Suppress warnings:
Even when I clean - build, rebuild, etc... the solution, Visual Studio keeps bringing up these warnings for me.
I brought this up with a visualstudio.com report yesterday and it's "triaged" at the moment. Is there an alternative way to suppress warnings in the solution, without marking every single reference?
Version: 15.6.2
Update:
This is wierd.
Visual Studio 2017 uses a semicolon by default, but comma worked.
The way I do it solution-wide is to create a specific suppression file, for instance GlobalSuppressionsForTestProjects.cs, in a convenient solution-level location.
Then for each project of the solution where I want the suppression definitions applied, I add a link to the suppression file:
right-click on project -> Add -> Existing Item
in selection dialog, navigate to the suppression file
click on Add as Link
I learned this trick from this post where the same way was applied for AssemblyInfo.cs files.
I usually use pragma directives:
#pragma warning disable 1591
// whatever member is lacking xml comments, or even the whole file
#pragma warning restore 1591
Verbatim from the link above:
disable: Do not issue the specified warning message(s).
If you really want to disable warnings solution-wide, there's no way to do it.
All compilation options are specified on the project level. MSBuild exists below the level of solutions.
But it can be done project-wise, just like you were doing above; the only thing I would change is separating those codes using a comma and not a semicolon like in your picture (and without a comma in the end), e.g.:
1591,1701,1702,1705
That's because compiler options use a comma.
You may just need to restart Visual Studio. This worked for me, and FYI we do not need to include the CS part of the error in your textbox (it would still work as written though, but you only need the number for this.) You have certainly restarted VS in the years since first asking the question, but for anyone having this problem today, I hope this helps.
I had the same issue with the same warning (CS1591). So for "Suppress warnings" in the properties to actually work (rather than the #pragma solution which is a legitimate work-around but might be unnecessary keyboard time after a restart) you might just need to restart Visual Studio.
In VS, it is possible to set a custom build rule at the individual file level. However, unless you change the description of the build step (which is what msbuild outputs when running the external tool), all you get is the default, which says "Performing Custom Build Step," followed by the error output of the tool.
I recently got burned by this in an inherited solution, where the build rule for a .asm file buried deep in a project was failing, and NASM didn't provide any useful debug information. Since I didn't know what file was failing, it took me forever to find the problem. One thing I tried was changing the description for all the projects in the solution (by selecting them all at once and opening the properties panel) and adding macros to show the project and file affected. Since the build rule was attached to a file, however, this naturally didn't work.
I also tried searching for the default description string in all the project files, but the project files don't store this information unless you set the value. So clearly, there's got to be a default somewhere. Anyone know how you can set this?
I doubt you can change the default for everything, but what you can do is create a property sheet in which you set a custom description, and than add that property sheet to all projects needing it.
I have a Visual Studio project with about 60 C++ source files. I can do a build, and it completes without errors. But if I immediately hit F7 again, it always re-compiles about 50 of the source files. It doesn't re-compile all of the files, which is strange.
I have 'Enable minimal rebuild' (/Gm) set. Any ideas why it might be doing this?
None of the files have a Modified Date in the future.
Are any of your file dates in the future? This can occur if you changed time zones or changed the system clock time. Dates in the future will confuse the IDE and force a rebuild every time F7 or F5 is hit.
I've solved the same problem.
In my case compiler displayed warning, that /Zi option is required if /Gm is specified.
/Gm enables "minimum rebuild", which requires debug information in .pdb file. So, if you don't want to use .pdb, also disable minumum rebuild - it solved a problem in my case.
Most probably is a matter of dependencies.
Consider the following possibilities:
If you have custom build tools defined for some of the files in your solution, make sure that the output property contains the right file name(s). If the output of the build tool doesn't correspond to the one(s) specified in the output file names, the builder will rebuild that file.
If you have custom build events, check whether the output from those build events don't affect the dependencies of the files to be built.
I had problems when trying, at post-build, to copy or move some of the output files to a build folder. The post build operations that affect the timestamp of the ouput files of the build process will determine rebuild each time.
In my case of such effect (C++ via VS2005) it was on Release configuration only, and the Studio tells in the build output, that compiler option /Gm is ignored if /Zi - option is not set. After setting /Zi via
Configuration Properties -> C/C++ -> General -> Debug Information Format : Program Database (/Zi) ,
it was ok. But isn`t there something wrong, when the Release Configuration needs something about Debugging? Not yet clear to me!
Project Properties -> "C/C++" -> "Output Files" -> "Program Database File Name" option should not be empty. Set this option by selecting from drop-down box . The option will be set like this: $(IntDir)\vc90.pdb. And line ProgramDataBaseFileName="" will be removed from vcproj file.
Then only changed *.cpp files will be recompiled when you build the project or solution.
It seems that this problem can be caused by many things, but what fixed it for me was:
Closing Visual Studio
Manually deleting all bin and obj folders (Clean doesn't seem to do the trick)
Opening the solution and running Clean (I'm not sure if this is necessary, but I did it just in case...)
Building like normal
Note: This was for a C# program in Visual Studio 2010.
After a couple days of googling, I ended up with a solution to my problem.
I encountered this problem when I moved my projects to a new PC. I had checked several times the creation date of the files. These dates were up-to-date, however the modification dates were in the bast (kinda bizarre) even when I changed the files.
A simple update of the files resolved the problem.
I'm having the same problem, and it seems to be because I've turned browse information off. Properties->C/C++->Browse Info->Enable Browse Info->None. The only fix I've found is turning it back on. This is for an xbox 360 project, fwiw, my other projects don't have the problem.
A reason is if the 'date last modified' for one of the source file is set for some date in the future: it rebuilds, and then the source file is still later than the executable.
This problem with the dates can happen if the source file is located in a directory a remote machine (a network share), and/or may even happen if your machine's time isn't synchronised with the date of the machine which is running the server of your source version control system.
Check your project includes any .h header file that doesn't exist on disk. Always happens to me when I delete a header file I'm not actually including anywhere, but forget to delete it from my solution navigator in VS. Note: missing headers produce no errors during the build (when not #included anywhere).
Check your project's Program Database Filename setting. For some reason, if this is set to the name of a directory (such as "$(IntDir)\"), it can sometimes cause VS to rebuild your project every time, even if you're not generating PDB files (i.e. Debug Information Format is set to "Disabled").
This is a bug in VS2008; I have not yet reproduced it yet in VS2010, but my tests haven't been thorough, so I'm not confident saying that the behavior isn't present in VS2010.
What caused similar symptoms at me was:
I have several projects in a solution. There were .cpp files which were referenced (and therefore compiled) by >1 projects. Unfortunately Visual Studio creates .obj files with a very simple naming - it just replaces ".cpp" by ".obj". Creating wrapper .cpp-s with different named solved the problem.
I had something similar. Even though I did have pre and post build events, they weren't causing the issue. It turned out that I had a number of projects down the reference chain that had content files that were marked as "copy always" instead of "copy if newer" meaning that these projects were always considered "out of date". By changing all of these to "copy if newer", changes to my unit test project no longer forced a recompile of all of the other projects.
Disabling "minimal rebuild" (Configuration Properties > C/C++ > Code Generation) fixed it for me. The compiler even left a clue:
1>cl : Command line warning D9007 : '/Gm' requires '/Zi or /ZI'; option ignored
Although I must point out, the compiler did not ignore the option as it said.
In my case I changed system data time to previous date so it is rebuilding every time because of different time stamp of the files once changed to the current time its not rebuilding every time.
We have that here regularly:
delete all intermediate and output files by hand. The clean option in vstudio is sometimes not enough. From a fresh start do the complete build. If after a complete build vstudio still wants to recompile certain files it might be related to next bullet.
if in your vcxproj a header file is referenced which is not on disk, the project is also recompiled. You might check this by some hidden feature described on MSDN blogs or just touch (i.e. click on it to open) all header files in the project exploder and see if one does not exist on disk
Had the same problem. Solved by:
-delete output folder (obj,exe,all files)
-run cygwin
-cd project folder
-run "touch *", which reset file modify date/time
-build and enjoy problem fixed
There is similar issue with project rebuild.
Visual Studio does not recompile but re-links a project every time on F7 hit.
Fix is simple. Try to open in Editor all files included into project (from Solution Explorer double click on each file) and remove from solution those files which do not exist.
I would like to change the output file name based on certain criteria that I'm checking with #defines. A little background, I'm doing this because I've decided to use VS2010 in one of my projects to regain intellisense. However, this is causing some other problems with Google Test, and the rest of my team is on VS2008. So, I would like to build a GTEST_VS2010.lib if I'm on VS2010, and GTEST.lib otherwise. I was hoping I could trick the compiler with #pragma comment(linker...
but that doesn't seem to be allowed by MS. Thanks for any help.
VS2010 converts project and solution files, doesn't it? Then you don't have a problem since you can't use the project file with VS2008 anyway. Just change the linker's Output File setting.
Otherwise, you probably should just consider adding another configuration to your solution.
This may sound like a newbie question - and it is. I'm relatively new to vs, we started using it a few months ago, and I still haven't "mentally" made the change from the command line. So, if you could help me with 2 things:
I create a new project (not a solution). He puts the files in some directory. After putting my code inside it, I click on the little green triangle (Debug, it says), and he compiles it, builds it and runs it. It works ok. Now, sometimes, I have to change only a tiny bit of code and I don't feel like getting the whole VS up just for that. How can I do that Debug thing from the command line, with the assumption I didn't change anything else.
Where do I tell him not to create a "Debug" subdirectory, not to create a HTML Build log, an object file ... and so on, generally, where can I find the settings which will help me to get as little files ... apart from my original source, and the .exe resultant one ?
I have to change only a tiny bit of code and I don't feel like getting the whole VS up just for that. How can I do that Debug thing from the command line, with the assumption I didn't change anything else.
I think what you want here is not debugging but a rebuild of your project.
Where do I tell him not to create a "Debug" subdirectory, not to create a HTML Build log, an object file ... and so on, generally, where can I find the settings which will help me to get as little files ... apart from my original source, and the .exe resultant one ?
The answer to both these questions is to use the command line! You can make VS emit a make file from the loaded project. Use NMAKE to build this make file after you have made your desired modifications. The ".obj" files are created as an intermediate step between compilation and linking phase this is how the C++ compilation model works. Why do insist on not generating them?
You can't really start debugging without starting up Visual Studio, since Visual Studio is the debugger. You can tell VS to rebuild a solution from the command line without firing up the UI if you want to just build it: See MSDN for details.
You can control the creation of the DEBUG and RELEASE directories via the 'intermediate files' option in the project settings. Though you need to create the obj file somewhere in order for the compile to work.