I'm trying to alter the default property sheet on a new install of Visual Studio 2010 for C++ projects. Just trying to add a few directories (for Boost etc.) and optimisation settings for release builds, basic stuff like that. Obviously there are some settings that I want to be different for different configurations. Problem is that whatever I try from the property manager window of my project, everything I do seems to affect both configurations.
I tried multi-selecting both -> right click -> properties initially, to set up common settings, and that did exactly the same thing as selecting Microsoft.Cpp.Win32.User under either debug or release. So everything affects both configs.
Now, as I understand it, Microsoft.Cpp.Win32... is a single file (at least, a single file for x86 configs, single file for x64 etc.) so the fact that I can't change the configs individually actually makes some degree of sense. But if I can't do it that way, how can I do it?
Appreciate any advice!
Short answer: you can't. See comment discussion under question.
Related
Can anyone tell me how to control default configuration parameters in VS 2017 C++? The scenario is that we generate one sample PC with the software we want (Win10, VS2017, et cetera), and this image is cloned onto about 100 PCs in student CS labs.
The two specific things I would like to control are (1) use of precompiled headers and (2) message C4706 (= versus == in an if condition). There are some others, but these are at top of the list.
I know students could fix this themselves, but so many are confused in the first few weeks of an introductory programming class that I don't want to try that.
A search of MSDN has not been productive, but I probably am using the wrong search terms.
Thank you in advance!
You could also edit the default platform property pages found at \\AppData\Local\Microsoft\MSBuild\v4.0, Microsoft.Cpp.Win32.user.props and Microsoft.Cpp.x64.user.props
I'm not sure how you would automatically distribute those files but so long as you are using MSBuild as the build system anything in those files is picked up prior to project-specific settings.
There are two ways I can think of:
Change the default settings in property pages for each configuration
Create a custom project template with all the project settings necessary. This will only affect new projects created with this template. Also it will keep the default template intact and will probably allow students to experiment a bit more.
For enabling Precompiled header.
Right click your project->Properties->( a property pages window appears)Configuration Properties-> C/C++ -> Precompiled Headers -> (on the right side) Select Use(/Yu) by clicking Precompiled Header.
And for suppressing C4706, set compiler warning to level less than 4
Right click your project->Properties->( a property pages window appears)Configuration Properties-> C/C++ -> General ->Warning Level to less than 4
To retain the settings and share with others....
I do not have proper VS2017.... Can you try as said below.....
First export the existing project settings using
project(visual studio menu)->Export template.... continue and and save the template and make a note of the path....
usually by default the templates is saved in below path as a zip file.
C:\Users\<>\Documents\Visual Studio 2017\My Exported Templates
Now copy the zip file and and put it in
C:\Users\<>\Documents\Visual Studio 2017\Templates\ProjectTemplates\Visual C++ Project
Check if your template is automatically picked up.
If not open visual studio command prompt tool and run
devenv /installvstemplates.
My current preferred C++ environment is the free and largely excellent Microsoft Visual Studio 2005 Express edition. From time to time I have sent release .exe files to other people with pleasing results. However recently I made the disturbing discovery that the pleasing results were based on more luck that I would like. Attempting to run one of these programs on an old (2001 vintage, not scrupulously updated) XP box gave me nothing but a nasty "System cannot run x.exe" (or similar) message.
Some googling revealed that with this toolset, even specifying static linking results in a simple hello-world.exe actually relying on extra .dll files (msvcm80.dll etc.). An incredibly elaborate version scheming system (manifest files anyone?) then will not let the .exe run without exactly the right .dll versions. I don't want or need this stuff, I just want an old fashioned self contained .exe that does nothing but lowest common denominator Win32 operations and runs on any old win32 OS.
Does anyone know if its possible to do what I want to do with my existing toolset ?
Thank you.
For the C-runtime go to the project settings, choose C/C++ then 'Code Generation'. Change the 'runtime library' setting to 'multithreaded' instead of 'multithreaded dll'.
If you are using any other libraries you may need to tell the linker to ignore the dynamically linked CRT explicitly.
My experience in Visual Studio 2010 is that there are two changes needed so as to not need DLL's. From the project property page (right click on the project name in the Solution Explorer window):
Under Configuration Properties --> General, change the "Use of MFC" field to "Use MFC in a Static Library".
Under Configuration Properties --> C/C++ --> Code Generation, change the "Runtime Library" field to "Multi-Threaded (/MT)"
Not sure why both were needed. I used this to remove a dependency on glut32.dll.
Added later: When making these changes to the configurations, you should make them to "All Configurations" --- you can select this at the top of the Properties window. If you make the change to just the Debug configuration, it won't apply to the Release configuration, and vice-versa.
I've had this same dependency problem and I also know that you can include the VS 8.0 DLLs (release only! not debug!---and your program has to be release, too) in a folder of the appropriate name, in the parent folder with your .exe:
How to: Deploy using XCopy (MSDN)
Also note that things are guaranteed to go awry if you need to have C++ and C code in the same statically linked .exe because you will get linker conflicts that can only be resolved by ignoring the correct libXXX.lib and then linking dynamically (DLLs).
Lastly, with a different toolset (VC++ 6.0) things "just work", since Windows 2000 and above have the correct DLLs installed.
In regards Jared's response, having Windows 2000 or better will not necessarily fix the issue at hand. Rob's response does work, however it is possible that this fix introduces security issues, as Windows updates will not be able to patch applications built as such.
In another post, Nick Guerrera suggests packaging the Visual C++ Runtime Redistributable with your applications, which installs quickly, and is independent of Visual Studio.
I have a vsprops file that defines the optimizations all of our projects should be built with for Visual Studio 2008. If I set the properties for the project to "inherit from parent of project defaults" it works, and fills them in the vcproj file. However, this doesn't protect me from a developer checking in a project file that changes the optimizations. In this case, the project settings are used over the vsprops settings. I need to make it so that vsprops always takes precedence over what is in the vcproj file. Is this possible? Other workarounds are also welcome.
Hmya, that's just not how Visual Studio was designed. It is quite free from "boss override" switches, it gives its user unfettered access to configuration settings. Which ought to make sense to you, a developer can do far more damage with his code than with tinkering settings. If a dev intentionally changes an optimization setting then, surely, it is because he profiled the code and determined a better setting.
Anyhoo, Visual Studio isn't just useful to the dev, it is also useful to you. Write a little utility that parses the .vcproj file and checks if the optimization settings were overridden. It is a simple .xml file, you'll need about 5 lines of code. Run it in a pre-build event on your build grunt and fail the build if you deem it inappropriate. Dealing with the pissed-off developer cannot be automated however.
The only advice I can give is, if you open up the Property Manager for the project, and Right Click on one of the Configuration folders, it should popup a menu with an item called "Overidden Properties..." which in turn opens a dialog box that lists each property set in the project configuration that overrides a property sheet property sheet - along with the facility to select some or all, and delete the overrides.
We just got a new developer and I'm trying to set him up with Dev Studio 2005 (The version we all use at this office), and we're running into a weird problem that I've never seen before.
I have some code that works perfectly on my system, and he can't seem to get it compiled. We've tracked the issue down to his copy of dev studio ignoring the preprocessor directives.
For example, in the project properties under C/C++|Preprocessor|Preprocessor Directives, I add DEFINE_ME. Which should translate to a /D"DEFINE_ME" for the compiler. And it does in my development environment, but it doesn't on his.
I verified that when he checks out the code from the source repository, that he has the same version of the code I do. And if I look in his Project Properties, all of the directives are there. For some reason they're just not getting passed down to the compiler.
Any Ideas?
I recently ran into the same symptom with VS2005. Ultimately I was able to resolve it by explicitly adding my preprocessor defines via the Command Line - Additional options dialog:
Configuration Properties -> C/C++ -> Command Line
When I added '/DPROPERTY' there it was recognized at compile time, whereas adding it under 'Preprocessor -> Preprocessor Definitions' did nothing. Oddly the Command Line dialog did show that Visual Studio was adding the property to the command line, albeit in the form '/D "PROPERTY"'.
Unfortunately schedule pressure being what it is I have not been able to dig into the issue deep enough to figure out what the underlying issue was/is, nor why it seems to work out of the box for some of our projects but not others. Nonetheless the workaround above is worth a shot if you're having this symptom.
Also, credit where credit is due: the idea came from this thread.
Make sure that the project configuration which is being built in the selected solution configuration is the same as the one you're configuring the properties for, and/or that you're configuring the properties for all project configurations. A common problem with new VS installations is that the current active solution configuration is system-specific, and may default to something not matching yours (eg: Release vs Debug).
You can see the project config in the build output, and/or check it in the Configuration Manager.
My current preferred C++ environment is the free and largely excellent Microsoft Visual Studio 2005 Express edition. From time to time I have sent release .exe files to other people with pleasing results. However recently I made the disturbing discovery that the pleasing results were based on more luck that I would like. Attempting to run one of these programs on an old (2001 vintage, not scrupulously updated) XP box gave me nothing but a nasty "System cannot run x.exe" (or similar) message.
Some googling revealed that with this toolset, even specifying static linking results in a simple hello-world.exe actually relying on extra .dll files (msvcm80.dll etc.). An incredibly elaborate version scheming system (manifest files anyone?) then will not let the .exe run without exactly the right .dll versions. I don't want or need this stuff, I just want an old fashioned self contained .exe that does nothing but lowest common denominator Win32 operations and runs on any old win32 OS.
Does anyone know if its possible to do what I want to do with my existing toolset ?
Thank you.
For the C-runtime go to the project settings, choose C/C++ then 'Code Generation'. Change the 'runtime library' setting to 'multithreaded' instead of 'multithreaded dll'.
If you are using any other libraries you may need to tell the linker to ignore the dynamically linked CRT explicitly.
My experience in Visual Studio 2010 is that there are two changes needed so as to not need DLL's. From the project property page (right click on the project name in the Solution Explorer window):
Under Configuration Properties --> General, change the "Use of MFC" field to "Use MFC in a Static Library".
Under Configuration Properties --> C/C++ --> Code Generation, change the "Runtime Library" field to "Multi-Threaded (/MT)"
Not sure why both were needed. I used this to remove a dependency on glut32.dll.
Added later: When making these changes to the configurations, you should make them to "All Configurations" --- you can select this at the top of the Properties window. If you make the change to just the Debug configuration, it won't apply to the Release configuration, and vice-versa.
I've had this same dependency problem and I also know that you can include the VS 8.0 DLLs (release only! not debug!---and your program has to be release, too) in a folder of the appropriate name, in the parent folder with your .exe:
How to: Deploy using XCopy (MSDN)
Also note that things are guaranteed to go awry if you need to have C++ and C code in the same statically linked .exe because you will get linker conflicts that can only be resolved by ignoring the correct libXXX.lib and then linking dynamically (DLLs).
Lastly, with a different toolset (VC++ 6.0) things "just work", since Windows 2000 and above have the correct DLLs installed.
In regards Jared's response, having Windows 2000 or better will not necessarily fix the issue at hand. Rob's response does work, however it is possible that this fix introduces security issues, as Windows updates will not be able to patch applications built as such.
In another post, Nick Guerrera suggests packaging the Visual C++ Runtime Redistributable with your applications, which installs quickly, and is independent of Visual Studio.