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.
Related
In a VS 2015 solution, with 100 C++ projects, some projects have different values for the same property. These projects go back a long time (product is 20+ yrs old). One such property is the Linker/Debugging/Generate Debug Info. Most projects have the /DEBUG settings. A few have /DEBUG:FASTLINK.
I am looking at the same configuration on both projects. Drilling into the property sheets does not show where this property is introduced. If I create a new project it shows the /DEBUG:FASTLINK setting for debug builds. This leads me the think that there is something in the project file that makes it different; the ones with /DEBUG:FASTLINK are newer then the ones with /DEBUG. This jives with a MSDN page I found indicating that FASTLINK is now the preferred option.
As an experiment I created a new project that parallels and "old" project. Both .vcxproj files are in the same directory, just named differently. The "new" project shows the /DEBUG:FASTLINK property. In both cases the project file does not set this value it relies on "". In other words it is not in bold in the property pages dialog. I was not able to see a useful difference between the two projects. Both use V140 for the toolset.
My goal is to make the setting the same across all of the projects, without setting it in each project. One way to do this is to create my own property sheet with these values the way I want. I would rather bring my projects up to current standards w/o manually recreating 100 projects.
With Makefiles I'm used to being able to write things like:
includedir=$(shell pg_config --includedir)/server
to run an external program, pg_config, with argument(s) --includedir, and include the result in a variable or as part of a variable. So if pg_config --includedir output /usr/include to stdout, the value of includedir would become:
includedir=/usr/include/server
Is there any way to do the equivalent with a Visual Studio project? Run a command, get the result, and substitute it into a property?
I find myself having to edit properties pages all over the place - changing the include directories and library directories for both the x86 and x64 configurations of a project whenever I want to build an extension against a different PostgreSQL version. It is intensely frustrating.
I want to be able to put something like this into Configuration Properties -> C/C++ -> General -> Additional Include Directories:
%(shell pg_config --includedir)
or even better:
%(shell %(PG_CONFIG) --includedir)
where %(PG_CONFIG)'s location is defined in a single place for each platform in the project.
So I'm looking for at least user-defined macros, and preferably the ability to invoke a command line tool and replace the macro with the resulting standard output.
(Preferably in a way that doesn't involve delving into semi-documented UI elements that move and get renamed in every VS version, and that appear and disappear from the various Express editions).
This has been possible in Makefiles for 20 years, there must be a way to do it in VS, right? Or do "Real Windows Developers" generate their VS projects with scripts and build them using MSBuild?
I've looked at some similar questions without finding much of use, e.g.:
Visual Studio - Where to define custom path macros?
In particular, I'm aware of property sheets (View -> Other Windows -> Property Manager), but they don't seem to provide a way to set a value in just one place, they're still per-configuration and per-architecture, so if you have four configurations and two architectures it gets awkward. Unlike with the normal project property editor you can't even apply a change across a group of architectures/configurations, either.
I could use a VS extension, but they require installation into the user's VS, can be version-specific, and seem like a very big hammer for a small problem.
I find myself having to edit properties pages all over the place
That bugged me to no end as well. Property sheets to the rescue! When setting up a major solution in VS10, for example, I had every project pull in a settings.props that contained the common settings, made in only one place. Then go through all the generated or imported projects and kill any explicit value (even if blank) for everything possible. That way things will inherit from property sheets. Select "all configurations" and on each properly use the drop-down to "inherit from...".
I have property sheets for each special library too, just defining the proper #define, include paths, lib paths, etc. Projects that use that particular external lib simply use that property sheet. Users are told, in the worst case, to “edit the XML to change the path to where you have Boost”.
As for setting such a properly to a dynamic determined value, you can do that too. There are property functions you can use.
It sounds like you're going down the same path as I did.
More notes: “prop sheets are per configuration/platform”: If you include a prop sheet at the top-level node for the project itself (not the Debug|Win32, etc. child nodes) it will include it into all current configurations at once. If you edit the properly page, you can choose Multiple or All configurations on the Property dialog box, just as with the usual project use of the Property dialog.
“Custom user macros are well hidden” A property page shows up for that when in a property sheet you created, but not when opening property dialog on a proj file as in the normal File View. The macro will be set in one place (the prop page) and usable as a $(name) in all projects that include it, and even in other property pages that come later in the evaluation sequence.
Let me know how it goes. You should be able to do everything you asked.
—John
In addition to #jdlugosz's answer:
It looks like the traditional way to do this with Visual Studio, before the advent of property functions, was to write a new MSBuild Task. The task can potentially do things like modify a property sheet.
MSBuild supports "inline tasks" where the task code is in the MSBuild project file, rather than a separate assembly, so it might not be neccessary to create a new subproject just for the task.
There are a bunch of built-in tasks, like Exec and CreateProperty that may be useful.
The docs say that:
[The Exec task] is useful when a specific MSBuild task for the job that you want to perform is not available. However, the Exec task, unlike a more specific task, cannot gather output from the tool or command that it runs.
... but that seems to be outdated/wrong so you don't need horrible workarounds.
So, prior to .NET 4.5 I'd probably have to write a custom task for this simple job, because there's no way to feed the command stdout/stderr into the CreateProperty task or have Exec create a property directly. But in 4.5 it looks like I can do it directly. At least in VS Express support for tasks etc is very limited so you'll probably land up editing the XML.
I am a Visual Studio noob. My background is more Unix-related and mostly used to building things via scons or make. I don't even have much Eclipse experience.
Anyway, I am frustrated how it seems very difficult to move files between projects in VS. (I am running Visual Studio 2013). For example, suppose I have a ProjectXRel (release) and I want a ProjectXDev (development). I want them both to be runnable, and the dev version might have just a few editing changes that differ it from the rel version.
The intuitive thought is to just copy the files from ProjectXRel to create ProjectXDev, but VS seems to fight me on that (it wants to rename all the namespaces to the title of the project).
Also, some of the files, like .cs files derived from .dbml via OR designer, seem uncopyable, and rely on one replicating the process of using the utility to having valid files. I'm used to a project being defined by its files, but that's not really the case in VS. Instead it seems defined by process steps used to create and organize the files.
Also, do serious developers just use command line calls and powershell? That's seems harder, but at least you know what the %#$$# is going on.....
So, the basic question is, how does one replicate an existing project to produce a similar one for development purposes? (I know source control such as git could help with that, but that's not an option for this situation.)
Thanks!
You should be using the same project for both Development and Release.
The things that are different between Development and Release should be stored in a config file (web.config or app.config, depending on what type of project).
You should then be using Configuration Transformations to transform that .config file into Development or Release.
In Visual Studio, right click on the project and click Add New Item, select "Application Configuration File".
In this file you can put connection strings or key/value pair settings in the AppSettings element (MSDN Link).
Once you have your basic settings defined, you can then right click on the config file and click Add Transformation. This will add transformations for each of the Project Configurations you have. (by default Debug and Release).
It will look like this:
Now you can build deployment packages.
Or install Slowchetah and then when you press F5 to debug it will run the selected project configuration with the configuration transformation applied.
Basically, what I want to achieve, is to be able to have 2 separate solutions containing the same set of projects, but 1st solution needs to be bound to source control, 2nd - not.
So whenever you want source control integration in Visual Studio, you can open 1st solution, but if you don’t want it, you can open the 2nd one.
The problem is, that VS stores some binding info in the project files, and while it is there, no matter what solution the project is part of, it will have source control integration when opened in VS.
Is it possible to have all the binding info in the .sln file only?
Or maybe there is another solution form my problem?
Edit: the reason I want to do that is because some of the team members prefer to have source control integration in Visual Studio, the others don't. Having 2 solutions would give them a choice.
No.
It couldn't be the same set of projects - the files in a project are either source controlled or not, but you could have a non-source-controlled copy of a version retrieved from source control.
You could probably automate the process of removing source control bindings. So you would get a solution from source control, make a copy, and remove the source control bindings from the copy.
I've needed this in the past in the following situation: a source-controlled solution with a shared class library and a sample application that uses the shared library. I wanted to be able to ship a ZIP file containing the sample application without source control bindings.
This is technically possible. Open the File -> Source Control -> Change Source Control dialog and you can adjust the bindings for each individual project, including the root solution. However, it probably won't do what you want. If you remove the bindings from the projects but keep the solution binding, you'll end up in a state where changes to the solution itself (e.g. stuff you do in Configuration Manager) are automatically checked in & out, but changes to files that are "owned" by the individual project systems won't be.
The best answer IMO is to have the developers who don't like SCC integration adjust the settings in Tools -> Options -> Source Control -> Environment to their liking. Here you can turn off most (all?) of the SCC features that act "behind your back." And they are all strictly per-user, stored in the HKCU registry rather than your makefiles.
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.