How to make use of Property Sheets for better solution management for C++ projects in Visual Studio

Setting up a C++ project can take a lot of time and often we are setting the same properties for a lot of projects, so isn’t there a solution to this problem?

Maybe create a custom Project-Template and always create the projects from this template?

Would be feasible but we would need a lot of templates. But what happens if we have to change a property after the project was already created?
We would have to change it for all project by hand …

But there is a a better solution in visual studio for these kind of problems, Property Sheets.

This can help with managing large solutions, but a lot developers don’t know about this feature, because it’s hidden away under the “Other Windows” menu in the shell.

With this post I want to let more people know about this great “hidden” feature of Visual Studio for C++ projects.

What is a Property Sheet?

A Property sheet simply is a .xml file with the file extension .props in Visual Studio 2010 and .vsprops in older versions (2005 and 2008). These file contain property definitions which can than be added to a project so the Properties are automatically set on all projects using the Property Sheet.

But Property Sheets do not contain different configurations, because this would destroy the ease of use.
If you need different settings for different configuration just create multiple Property Sheets.

A Project can use any number of Property Sheets.

What can they be used for?

Property sheets can be used to solve a lot different problems.

I’m using them to place the settings for the different configurations (Debug, Release, Production) outside of the actual projects so I have only one file containing the debug properties, one for release and one for production.

Now every project just has to add these Property Sheets and they are ready to be compiled. With the same settings as every other project in the solution. Using the same Compiler Warning Level, optimization settings, Linker settings and so on.

An other possible use case would be one property sheet for every  external dependency your code is relying on.
For example when we are using boost, we could create a property sheet which contains just the path to header and library directory. So every project which would like to use boost just has to add this property sheet and not have to define the path itself.

Defining a path can take some time, keep in mind if you are compiling for x86 and x64 you have to use different libraries.
So your path has to be defined in a way, it will link to the correct location for the chosen platform which can easily contain an error. If this is the case and you are using a Property Sheet, there is just one place you need to change whether it’s being used in 1 or 20 projects.

These are just some examples, surely there are more problems they can help, just be creative.

How to use?

We talked about the what and why, but now it’s actually time talk about how we actually can use Property Sheets. I will show how to use them in the Visual Studio 2010 Beta 1, but nothing really changed since Visual Studio 2005( in this area) so they versions are mostly equal.

Everything starts with finding the correct window. It’s hidden away under
“View” –> “Other Windows”. There you will find the “Property Manager”.

You will now see this unimpressive window. This is the Property Manager.

It contains every project in the Solution with a “Folder” for every Platform/Configuration Combination. Like Debug/x68 and Debug/x64.

There are some buttons, the first one (from left to right) opens the properties for the currently selected item in the list. If the project is selected, the configuration window for the project will be opened.
If a property Sheets is selected, the properties for the selected Sheet will be opened.

When opening the Properties of a Property Sheet you  have to pay attention that just the values which are bold are actually defined in the sheet. The inherited values are also visible but they are not bold.

The second button adds a new, empty Property Sheet. The button right from it, adds a already existing Sheet to the project.

With the arrays you can move the priority. The Property sheets inherit values from each other. The Property Sheet which is placed at the top has the highest priority and will override the settings from Property Sheets placed below.

My advise would be to open the Property Sheet in an editor after you have made changes and see if just the value you wanted to set are actually set.

If you have changed any values in a Property Sheet, my advice would be to open the file in an xml editor and have a look at the properties you have changed. So you can be sure that have set the correct values.

Make sure to always save the changes, as they will not be saved automatically.

Some Pitfalls

There are some pitfalls you have to keep an eye on.

The first pitfall is that changes to the Property Sheets are not saved automatically. You manually have to save every Property Sheet you have changed. If you are changing a lot Property Sheets it can happens quickly that you have forgotten to save the changes and you are left wondering, why nothing changed.

My Solution for this problem is: I always close the solution and reopen it after I made any changes. This way Visual Studio will ask, If you want to save you changes and will save all Property Sheets automatically. This takes some seconds but it’s a lot faster than recompiling you project just to find out that you have forgotten to save the changes.

The other one is actually a problem with the UI.
It’s really hard to see how the values for the final project are brought together.
There is no other way to see if a Property Sheet overrides settings from any other Sheet without opening both. It’s also not possible to have two Property Windows open at the same time. Which doesn’t make it any easier, as well.

Conclusion

So i hope I could show the potential of Property Sheets for better Project Management in C++ projects and I also could warn you about the potential problems you may encounter when you are using Property Sheets for the first time.

I think this is a great feature and deservers a better handling in the UI than it currently has. Nothing has changed in the Property windows since Visual Studio 2005 and I think it’s time for a rework of those windows.

Thanks for reading and I hope you learned something new.