I need to create two different configurations for my VS2010 C-library project: one configuration is "regular" C/C++, the other one uses a custom compiler.
Unfortunately, when I create the two configurations for the project I'm either able to specify "C/C++" configuration properties for both configurations or "Custom Build Tool" for both configurations, but not "C/C++" for one and "Custom" for the other.
Same happens on the "item" (C-file) level.
To work around that problem I've created two mutually exclusive projects, but that is ugly - e.g. when adding files or modifying common properties one has to do it in two places instead of one, etc.
Any ideas? Thanks in advance.
Related
By default when creating a new solution, VS 2015 gives you two solution configurations: Debug and Release. I want to know if it is okay to remove these two configurations. I want to create three: Development, Testing and Production to match the nomenclature of my organization and do not want to have confusion with Debug and Release.
So any reason I should NOT remove these two?
You shouldn't delete the Debug and Release configurations.
Configurations are not just a name. The Debug configuration for example defines a preprocessor variable called DEBUG that you can use to add or skip blocks of code with the preprocessor statement #if.
The Release configuration instead contains settings used by the compiler to produce optimized code.
However you can rename DEBUG to Development and Release to Production while you could create Testing copying one of the twos and adding your own settings (like a preprocessor variable called TEST for example)
To rename a configuration use the menu Configuration Manager inside the Build menu.
Then in the Active Solutions Configuration combobox choose <Edit>
The following form contains the button that allows you to rename the configurations but preserve the orignal settings
To create a new configuration use the same menu but choose <New> instead of <Edit>
This article on MSDN seems pretty interesting
Understanding Build Configurations
I have a solution file that has the following example projects:
SharedLibrary
NonSharedLibrary
WebProject
WebProject.Install
Then another solution file that has the following example projects:
SharedLibrary
WindowsServiceProject
WindowsServiceProject.Install
Currently I open both in two separate instances of VS2010. The share library is the same in both but shared through my source control.
Is there an easy way to create another Solution file that when opened, opens all necessary projects for both. Then when testing, etc. you just change your startup project.
All the while maintaining the ability to open the old solutions if you want to just work on one of them.
Has any one does this before and/or know of a good methodology?
Visual Studio solutions are basically containers that group projects together. You can reuse the same projects in multiple solutions. A common way of handling this is to have one solution that contains all of your projects. Then create additional solutions that only load some of the projects. For example, you might make one solution for UI developers that only loads the projects they need while other developers might not care about the UI but need the windows service.
Each developer can set their own startup project which is stored in their local .suo file.
If you have multiple solutions open simultaneously and you change one project then you'll get the reload message in the other instance since they are shared.
Sure. Just create a new (or several) empty solutions right next to your existing one and then just add to it the projects you want to see there (Add Existing project)
I have a Visual Studio web application solution. I have three projects as UserInterface, BusinessLogic and DataAccess.
I had to store some user defined settings and I created configSections in the config file.
I access these configSections through classes which inherit from .NET's ConfigurationSection base class.
So in short for every project I had a separate configSection and for that corresponding configSection I had a class in that project inheriting from ConfigurationSection to access the config section settings.
This works all sweet. But the problem arises if there is any setting which I need to use across multiple projects. So If I need to use a setting defined in UserInterface project configSection in, let say, BusinessLogic project I have to actually make a copy of that setting in the BusinessLogic's configSection. This ends up having the same setting copied across multiple configSections.
Isn't this a bit too redundant?
Never actually done this, but in theory it might work...
When you define your custom configuration section, set its configSource to an external file (whatever.config). This external file should be added to the SOLUTION and not the project. It will appear under "Solution Items". In each project, Add an Existing File, browse to whatever.config, click the dropdown on the Add button and select "Add as Link."
Whatever.config will be a single file you can edit under Solution Items, and it gets copied into each application at compile time.
Using your example:
Just create the setting in the Business Logic project and then expose a Getter to the User Interface project.
Then the UI can query the BL for the value. Your configuration setting is only in one place - the lowest level it can be.
However, if you replace a lower level project with a new one you'll have to make sure that the setting is replicated too. This is only likely to be an issue if the setting is in the Data Access level as that's the one most likely to get changed (different database provider for example).
There is a much better way of doing this using "Shared Projects" see my Answer on a very similar question here.
We have a VS solution with 99 projects. I'd like to extract XML documentation for them.
So far, the only procedure I've found involves several hundred mouse clicks; e.g. open each project properties page, one by one, find the "Generate documentation" check box, and click it. The default filename is fine.
Worse: I have to do that twice per project, once for "Release" and once for "Debug".
Is there a magic button that says "enable documentation for all projects in this solution"?
This is a general problem with project-level configuration. For example, I'd like to also set the output build directory for all projects to the same place: $SolutionRoot/bin rather than each going into 99 different $ProjectRoot/bin directories.
What is the recommended strategy for dealing with this? In makefile-land, I'd have a master makefile that defined a bunch variables that each sub-makefile would use. What's the equivalent for Visual Studio? (I'm using VS 2008)
Project files are XML, I wrote a program to open each project file as an XDocument, add the required Elements and save it again. Next time I opened visual studio, the properties were set.
For something like this, you'll want to use Visual Studio's property sheets.
Though it will be a PITA to assign the same property sheet to all 99 projects, making changes that apply to all projects in the future will be much easier - 1 change versus the original 99.
You may also want to consider creating a hierarchy of property sheets that apply to different types of projects (executables, libraries) or configurations (debug, release) to allow even more fine-grained control without requiring massive duplication.
EDIT: I guess property sheets are not available for languages other than C++. For other languages (like C#) you could refer to this answer.
If you use Visual Studio 2008 and have many project files within solutions how do you keep them in sync? In other words, if you change a property in one project, how do you ensure that this property is automatically changed in other projects?
Given that enough contributors are mystified about the notion of nested solutions, I'll just work from the assumption you meant "solution with multiple projects". You give them common settings by using a project property sheet. Start with View + Other Windows + Property Manager. Open one of the nodes, right-click a configuration and choose Add New. Choose a location that makes sense for the solution, the solution directory for example. Configure the settings the way you want them.
Repeat this procedure for all other projects in your solution, now using Add Existing. Every project will inherit the settings you configured in the sheet, unless it overrides them explicitly. You may have to go back to the project properties and change an override back to "inherit".
IDE support for project property sheets is a bit flaky, be sure to save them explicitly when you make a change.
I have to say, I've not heard of "nested solutions", and I'd need a pretty compelling reason to do anything of this sort. Especially considering your question really centers on "how do I maintain duplication?" since you say the solutions will share properties. It's a cardinal rule in programming "do not duplicate thyself".
You could put the required options into a compiler response file, and use the same response file in each of your .vcproj files.
See here: http://msdn.microsoft.com/en-us/library/3te4xt0y(VS.71).aspx
Basically, you create a text file like SharedOptions.rsp, and on each line of the file specify a different command-line compiler option. Like /I.\include or /DDEFINE or whatever.
Then in the c++ command-line property page of each project, you add this in the additional options box: #"SharedOptions.rsp".
Then when you edit the options in the text file, they will be picked up by all projects. It is possible that the property manager solution provided by nobugz is just a gui for this - I don't know, I am more of a command-line kinda guy.
I guess you've already done something about this in the last 2 months, but this answer is more for the googlers...
I ended up using global variables available within Visual Studio. These were variables like $ProjectName and the like. There are many available already within VS, they can be user-defined as well.