is anybody aware of a way to apply (as in write or transfer) the settings of a Visual studio property sheet to the actual properties of the project (so they appear explicitly in .vcxproj file)?
I would like to load in a property sheet, transfer the settings to the "real" project's properties (not inherit the settings from the sheet!) so I can remove the property sheet afterward again.
Does the VS IDE allow this?
I am looking for a clickable solution, not a manual transfer.
Thanks in advance
There is no built-in way to do this though you could program an extension or external executable (which is easy to invoke as External Tool in VS) to do this, using e.g the Project class. But it is not that trivial: what do to when conflicting properties are found? Replace them? Combine them? Moreover it sort of defeats the entire purpose of propertysheets which is having a reusable set of options for building.
Related
Context: setting up the Assembly Name/Default namespace in the Project Properties (right click on project, Properties, Application tab; or edit the .csproj).
I would like to add a parameter there to explicitly have them following the Project Name, plus some custom suffix. So if I rename my project, the Assembly name/namespace follow that rename.
Example: project named foo → foo_suffix.dll. If I rename the project to foo1 → foo1_suffix.dll.
Same behaviour for the namespace.
Reading Common macros for MSBuild commands and properties,
I tried inputting $(ProjectName) both in VS and in the .csproj file, but I get a .dll named exactly like that.
How can I get this done?
How can I get this done?
1. Try using $(MSBuildProjectName) property from this document.
You're developing a C# project(csproj) while your document above is about macros in C++ projects(vcxproj). So I think $(MSBuildProjectName) property can be more suitable for you after my several tests.
(I tried $(ProjectName), but it only worked well when I set something like <AssemblyName>$(ProjectName)</AssemblyName>, if I add a suffix like $(ProjectName)_suffix, the output sometimes is _suffix.dll. But it always work well if I use $(MSBuildProjectName)!)
I get the desired behaviour, but that is inconsistent with what I can
see in project, Properties, Application tab.
2. Try reloading the project file(Right-click project, unload.., reload...) to Update the UI.
From your comment, it seems like the $(ProjectName)_suffix works well in your machine? If so, you can still use $(ProjectName) property.
What you experienced is expected behavior for Msbuild and VS. VS will read value from csproj during project loading process. Then it display the related value by UI.
So after we rename the project name and then build the project, we can get a ProjectName_suffix.dll in output folder. But the UI is still not changed(inconsistent), cause now we need to Update the UI.
You can right-click project node, unload the project=>reload the project to get UI updated. And now the output xx.dll can be consistent with what you see in project, Properties, Application tab. It needs us to reload the project each time after you rename the project, then the UI would be consistent with your xx.dll. And actually it won't affect your build though the UI is not updated, the output can be your desired behaviour.
3. All above is more related to the relationship between Assembly Name and Project Name. One point you should know is msbuild(csproj) won't modify the source files(xx.cs) after the project is created.
So assuming you have a Class1.cs file whose namespace is Library. If you rename the project to NewLibrary, reload the project and you can see the Namespace is NewLibrary now in project, Properties, Application tab. But the namespace for Class1.cs file is still old Library. This is expected behavior in VS, and the new NameSpace NewLibrary would work if you create a new xx.cs file.
Hope all above helps :)
I've recently encountered Property Sheets in Visual Studio, which provide a way to define user defined $(MACRO)s for a project. They're not what I really want but are the closest I can find in VS so far.
However, under the property manager (View -> Other Windows -> Property Manager) it doesn't seem to be possible to get the User Macros section of the configuration editor to show up unless you edit a specific configuration/platform combo, like Debug | Win32.
If you have quite a few configurations and want to (say) set a macro to the same value for all configurations on the same platform, this gets cumbersome fast.
When editing project properties normally you can select "All Configurations" and/or "All Platforms" to have changes copied to sub-sections. This isn't available when editing a property sheet.
Is there any way to set values in a property sheet for multiple configurations/platforms at once? Consider, for example, that you want to set a macro POSTGRES_INSTALL to %PROGRAMFILES%\PostgreSQL\9.3 for x64 targets and %PROGRAMFILES(x86)%\PostgreSQL\9.3 for x86 targets, is there any way to do that for multiple targets (Debug, Release, SomeCustomTarget) at the same time?
How property sheets work
Property sheets are simple lists of properties. Entries aren't per-configuration or per-platform.
If you add a property sheet to the top level of a project, it's added to all configuration/platform combinations underneath, as if you individually added that property sheet file to each configuration yourself.
All properties are therefore visible across all configuration/platform variants.
This means you can also do things like have one sheet for all your x86 configurations and a different sheet for all your x64 configurations, e.g. for build paths. That way all the rest of your properties in your code can just use $(MYLIB_INCLUDE) without worrying about whether it's a 32- or 64-bit build.
You can usefully combine per-configuration/platform and global property sheets, too, a property sheet can reference one further down the list. (Order is significant, and they seem to be read from bottom to top according to the UI).
You can check what the final values of properties are by going to edit a property in the main project properties page, and tabbing open the "Macros>" tab. This is useful when debugging ordering issues with one user macro referencing another from a different sheet.
Example of usage, with code
As an example, which you can download from pg_sysdatetime on github here, I created three property sheets:
pg_sysdatetime.props is the master sheet that users can edit to change paths. It defines PGBASEDIR_x86 and PGBASEDIR_x64 macros with the paths to the 32-bit and 64-bit PostgreSQL installs on the system.
pg_sysdatetime_x86.props is a simple wrapper that defines PGBASEDIR as $(PGBASEDIR_x86).
pg_sysdatetime_x64.props does the same for $(PGBASEDIR_x64)
I added pg_sysdatetime.props to the top level of the project, so it got applied to all configuration/platform combinations.
I then added sysdatetime_x86.props to all x86 platform configurations, and sysdatetime_x64.props to all x64 platform configurations.
The properties editor looks like:
and I can see the macros properly defined when editing a property:
Now I can reference the PostgreSQL libdir, include directory, etc from anywhere in my project with simple macros like:
$(PGBASEDIR)\lib
without caring whether I'm doing a 32-bit or 64-bit build, etc etc. So I can just edit settings for "all configurations", "all platforms" and know that they'll work for everything, I don't have to individually edit each one.
It's almost like using a Makefile from 1980 ;-)
I have a C++ project in VS2010. I would like another C++ project to inherit its properties (e.g. include directories, external libraries, etc.). It seems the best way to do this is to use Property Sheets, but I can't figure out how to do it.
When I try adding an existing property sheet to my new project, I expect to be able to find a property sheet containing the old project's properties in the old project's directory. No such file exists.
What should I be doing?
In order to create inheritable properties you must create a new property sheet, save it in a local location and have any projects you want to have those properties use (inherit) it by "Add Existing" sheet.
The order of the listing of property sheets matters. If the property is listed as "Use default or inherit from parent" it will get the value from the property sheet directly below it or if there is none below it, it will use the default.
The sheets listed in the property sheet manager are just links. If the file is linked to multiple Configurations and you change it in one, ALL linked configurations will accept the changes. Therefore if you want to make different changes for each Config. for the same property you must make separate sheets.
I need to be able to change the PublishUrl property in my Excel VSTO project's csproj file in order to manage which publish url is used based on the configuration that is set in the configuration manager. This needs to happen regardless of what the developer enters in the Publish Wizard or the project properties window. I really need to control it at the point of publishing, based on the configuration set. I have found no solutions that work and it seems that this would be more common than I am finding.
I think this article will help you. You can create a small script to re-sign the files, and when you do that, you can set the URL. The article shows an example (but w/o the URL -- it's just another option available when using mage).
Sometimes when working on projects that people have posted online, I have to frantically modify my own property sheets to match theirs in order for my project to work (things like: MTd, linker stuff, Unicode/Multibyte settings).
I was wondering if I could just export a property sheet in Visual Studio for later use instead of creating one from scratch.
Not if you use their project file, its settings are "last" and override anything you'd set in a project property sheet.
Nothing that you couldn't fix with a text editor btw, open the .vcproj or .vcxproj file with, say, Notepad to see how you could delete settings so a property sheet can work. Or copy/paste settings from your own project file.