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.
Related
I wish I could provide a better description, but this is hard to describe succinctly.
Let me start with some background. This is a C++ solution using Visual Studio 2019 Community Edition. It has 12 projects of different types (DLLs, static libraries, and executable tests) and 4 build configurations ((Release, Debug)x(Win32, x64)). Keeping all the properties the same across projects and configurations has been a massive pain, so I decided to try using property sheets so that I could have the properties shared across projects. Given the structure of my solution, the property sheets are themselves somewhat complicated, but it's an improvement over what I had.
However about halfway through this migration I noticed some odd behavior. When I inspect the properties for one of my projects (a static library), the properties page is almost totally empty. Not only the properties I have changed with my sheets are missing, but even the default properties that you would expect.
However when I build this project, I can tell that most of the custom properties are in fact set correctly despite being missing, so it would seem like a UI bug, except some properties are not set correctly, for example the build log is not written to the correct location despite being set in the property sheet. This makes me worried that other more important properties may not be set correctly as well, but it's hard to know which properties are getting set and which are not.
I have another static library project that is set up in the same way with the same property sheets, and it behaves normally. It shows the expected properties in the project properties, and the build log is even in the correct location.
It gets even stranger. When I run the build from the command line using msbuild or devenv, the build log is written to the correct location. This suggests that building from the command line is working correctly, and that building from Visual Studio is not the same as building from the command line.
I ran msbuild -pp to see the expanded project file, and it looks correct. I diffed this project file with another static library from my solution that is working normally, and the diff is as expected, only the project names, paths, and source files are different. I did this diff on the expanded projects files too and they were the same except the expected differences.
I have closed and reopened Visual Studio countless times. I have also unloaded and reloaded the project. I have even tried deleting the .vs folder. None of these had any affect.
Here is a link to my code.
Screenshots demonstrating what I mean.
Is there any way to fix this? Have I done something wrong? I would like all of the properties from my property sheets to show up in the project properties, and I especially need all of them to apply when building the project.
Moving the <ItemGroup>s containing the source files below the <ImportGroup>s in my project file (.vcxproj) fixed the problem. I cannot explain why this works, or why this was ever a problem in the first place, but it fixed it.
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.
I am moving now from VS 2005 to VS 2010 with products consisting of few solutions with numerous projects each. I wanted to make use of the property sheets system so our numerous configurations would be easier to maintain.
One of the issues is that we want to use Windows SDK 7.1 (as we need BaseClasses sample - and if we have to use that sample that why not the entire SDK)? But this requires me to change PlatformToolset on each and every single project in all the solutions. Also we will have to remember to change that value for newly added projects. Rather bad idea.
So I wanted to set this (among other things) from a custom property sheet. There is no such option directly from dialog shown when setting properties on property sheet. Adding entries manually to the XML file didn't help as well (but I haven't also seen any error or warning message).
Then how am I supposed to set default PlatformToolset value? At best in a configuration file which can be committed to repository. But if it could be done in some computer local settings then it would be acceptable too.
(Note that I know that I can use BaseClasses differently and avoid that problem at all but I think it is interesting issue in itself.)
I also asked this question at MSDN Formus.
PlatformToolset must be set in project properties at the begin of the file before inclusion of other files so that it can be later used to set up some defaults. If non is set then those inclusions will set it up to some default value.
Resetting it later even if works is pointless as everything was already included/set up. So to change the default value to a different SDK it seems VS configuration files (those which are included) should be changed appropriately.
But this does not have to be a good thing because it is local for the machine.
There is also an option of manual inclusion of property file which sets the PlatformToolset before default inclusions. However MS warns that if project file does not keep proper order (and this would spoil the order) VS GUI tools for project set up might not work properly.
In the end I just manually changed all projects. New projects also have to be changed to the new PlatformToolset.
Being new to VS, how may I think of these two concepts, what is the difference?
I find some missing information in the other answers (at least for people who come from other IDEs like, say, Eclipse) . To say that a solution is a container for projects is only part of the thing. The conceptual feature of a VS project (what determines its 'granularity') is that one project produces one output: typically an executable or a library (dll). So, if you are going to code three executables that uses related code, you'll create one solution and at least three projects - probably more.
A solution is a container for projects, and tracks dependencies between projects.
Just to come up with a metaphor..
A solution is like a house, a project like a room. Each room provides a piece of functionality whereas the house, a container of rooms, provides the means to link the rooms together and organize them appropriately.
Kind of corny but I made it up on the fly, so bear with me :)
It doesn't help that Visual Studio seems to make things more confusing. "New Project" actually creates a new SOLUTION containing a project. "Open Project" actually opens a solution containing one (or many) project. (The file menu says "Open Project/Solution" but it really is opening solutions. There is no "Close Project" only "Close Solution" which is accurate.
So, in VS you are always working within a solution. Many solutions contain only one project and newer developers are likely to think of them as the same thing. However you can add other projects into a solution.
In case anyone decides to scroll down this far... I thought the MS docs did a pretty good job at describing the differences. I've copy pasted (and rephrased) the relevant bits here:
When you create an app, application, website, Web App, script, plug-in, etc in Visual Studio, you start with a project. In a logical sense, a project contains of all the source code files, icons, images, data files and anything else that will be compiled into an executable program or web site, or else is needed in order to perform the compilation. A project also contains all the compiler settings and other configuration files that might be needed by various services or components that your program will communicate with.
You don't have to use solutions or projects if you don't want to. You can simply open the files in Visual Studio and start editing your code.
In a literal sense, a project is an XML file (.vbproj, .csproj, .vcxproj) that defines a virtual folder hierarchy along with paths to all the items it "contains" and all the build settings.
In Visual Studio, the project file is used by Solution Explorer to display the project contents and settings. When you compile your project, the MSBuild engine consumes the project file to create the executable. You can also customize projects to product other kinds of output.
A project is contained, in a logical sense and in the file system, within a solution, which may contain one or more projects, along with build information, Visual Studio window settings, and any miscellaneous files that aren't associated with any project. In a literal sense, the solution is a text file with its own unique format; it is generally not intended to be edited by hand.
A solution has an associated .suo file that stores settings, preferences and configuration information for each user that has worked on the project.
A Solution can have many Projects.
The Solution can also handle managing the dependencies between its different Projects...making sure that each Project gets Built in the appropriate order for the final Solution to work.
A project contains executable and library files that make up an application or component of an application.
A solution is a placeholder for logically related projects that make up an application. For example, you could have separate projects for your application's GUI, database access layer, and so on. The projects would be specific divisions for your program's functionality, and the solution would be the umbrella unifying all of them under one application.
A solution is a readable text file whose extension is .sln and having a structured content that describes the projects that it contains. A project is a readable XML formatted text file whose extension is .vcxproj and having a structured content according to its XML schema, and whose primary purpose is to contain the listing of source codes filenames and their dependencies or references to other project's source codes as well.
Solutions are containers for projects - you can also use them to organize items that are used across different related project (shared dll's and such).
Solutions are containers used by Visual Studio to organize one or more related projects. When you open a solution in Visual Studio, it will automatically load all the projects it contains.
When you create a new project in Visual Studio, it automatically creates a solution to house the project if there's not a solution already open.
You can set dependencies of projects on other projects in the solution. The dependent project is build after the project it is depending on is built.
For more details refer - https://learn.microsoft.com/en-us/visualstudio/ide/quickstart-projects-solutions
If you are from an Eclipse background you would probably go to build path of a project and add a dependency on other project or add an external jar. In VS you can do that in a single container called solution where all related projects are grouped together.
Eg. Let's say you are build and android and iOS app in xamrin, there would be some common code and resources that could go in a separate project and then your android and iOS projects can depend on this common code project. Also you could have projects to test these projects etc.
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.