$(ProjectDir) etc. are not being replaced in my Visual Studio C# project's app.config file.
I'm sure this is simple and I'm just searching for the wrong things, but does anyone know?
EDIT:
I want to have this work in my app.config:
<add key="path" value="$(ProjectDir)..\blabla">
Things like $(ProjectDir) are build-time (or rather, design-time) environment variables for use within Visual Studio and the MSBuild build system. They have nothing to do with the applications you're building. Your app.config file is your program's runtime configuration file.
If you want to have text inside your app.config file vary when your project is built then you should look at T4 Templates: http://msdn.microsoft.com/en-us/library/bb126445.aspx - that you can use VS's environment variables from within them (see http://msdn.microsoft.com/en-us/library/vstudio/ee848143(v=vs.100).aspx under "Access to environment").
But in your case, it looks like you could just use relative paths in your application, why do you need to hardcode paths in your config file?
You don't need to use $(ProjectDir) in your app.config. The app.config file is already in the project directory so you can just use a relative path from there.
<add key="path" value="blabla">
Related
I am attempting to overhaul my project's build processes. We have ~330 Visual C++ projects that we have upgraded in the last year from Visual Studio 2005 to Visual Studio 2013. I would like to take advantage of MSBuild to improve our build time over our very serial build scripts that we have now. I have completed a rough first pass and dropped the build times for a Release build from ~2 hours to ~20 minutes. In the process of doing this, I am consolidating a lot of common project settings into a .props file . In doing so, I have hit a stumbling block.
I wish to inherit the Platform Toolset from one VSProps file to all of the projects that include it. At the top of the new .props file I created, I put the following:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ImportGroup Label="PropertySheets" />
<PropertyGroup Label="Configuration">
<PlatformToolSet>v120</PlatformToolSet>
</PropertyGroup>
<PropertyGroup Label="UserMacros" />
I then removed the corresponding <PlatformToolSet>v120</PlatformToolset> from the individual project files.
Alas, things have started to go downhill. The projects (in Visual Studio 2013) now say in the Solution Explorer something like CoreGeometry (Visual Studio 2010) and the projects themselves seem to want to reference the v100 platform toolset. When I build, it then complains at me:
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppBuild.targets(362,5): warning MSB8003: Could not find WindowsSDKDir variable from the registry. TargetFrameworkVersion or PlatformToolset may be set to an invalid version number.
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(341,5): error MSB6006: "CL.exe" exited with code -1073741515.
The only way I have been able to work around this is to manually set the PlatformToolset on the .vcxproj themselves, which is not terrible, I just am a bit annoyed that every other property seems to inherit, but the PlatformToolset does not.
My question is thus:
Can I use a .props file to inherit a common PlatformToolSet into a .vcxproj that does not specify a platform toolset?
A second question: Should I even be messing with the Platform ToolSet in this manner or am I setting myself up at risk for a maintenance nightmare later?
It is very good practice to extract common settings to a separate .props file and <Import> that from all projects. I am doing the same with my projects, including configuring PlatformToolset property in .props file, and I have no problems building it this way.
Few points related to this:
There is nothing special about PlatformToolset property, or any other property for that matter. Configuring properties inside .props file is identical to setting it inside .vcxproj file directly (however see my point below about ordering). Of course, there are some built-in properties, which you cannot configure at all, but those are always read-only properties.
The only case where you would not be able to override a property, if it the property value is passed directly from command line for the build (e.g. msbuild mysolution.sln /p:Platform=x86 will have everything built with Platform property set to x86 and overrides in projects won't take effect).
There is a difference between msbuild engine interpreting your projects and Visual Studio showing settings for the project. In some cases you might find that after refactoring .vcxproj files some standard project configuration dialogs not showing information you configured in .props file. To alleviate this, make sure that your <Import> command for .props file is always able to locate the .props file, by setting absolute path to .props file. Second, ensure you specify Label attribute for the <PropertyGroup> element in your configuration file like it was specified in your .vcxproj file.
Finally, make sure your <Import> element is in the right place. Usually you want it to be the very first Import, before you import standard .targets and .props, like Microsoft.Cpp.defaults.props, etc. The reason is msbuild works by performing sequential scans through the statements, so order of instructions matter.
To make #3 and #4 easier, here is a trick to specify absolute path to the .props file. Assume that your solution name is MySolution.sln and custom props file is MyCustomProps.props, placed in the same directory where solution is:
<PropertyGroup>
<RootFolder>$([MSBuild]::GetDirectoryNameOfFileAbove($(MSBuildThisFileDirectory),MySolution.sln))</RootFolder>
</PropertyGroup>
<Import Project="$(RootFolder)\MyCustomProps.props" />
I wrote a library called MyLib with some Visual Studio projects in MyLib\Samples\, and the include files reside in MyLib\inc. In order to make these include files accessible in the projects, I need to add their path in the project properties.
I want to use a relative path, so that I don't need to change the properties each time I move the whole library folder to other places. But what does the relative path look like? For example, one of the project path is: ...\MyLib\Samples\proj1, how do I represent the ...\MyLib\inc relative to the project path?
Use the $(SolutionDir) or $(ProjectDir) MSBuild properties to root the paths. These are replaced at build-time with the directory in which the Solution and Project are located, respectively.
What you're looking for is custom properties for your project.
Visual Studio has support for defining custom properties which you can subsequently use in macro expansions in your include path, for example.
Here's an example of how it looks like:
In visual Studio 2010, I want to make all of the projects in one solution have the same configuration such as the include directory,the lib directory? I know there is a thing called property manager that can do this, but it makes other solutions have the same configuration.
Is there some ways to deal with it:Only let the projects in the same solution have the same configuration and don't affect other solutions?
What you can do is make your own .props file. If you open the .vcxproj file with a text editor, you can find some lines down the file something like this:
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
That imports (or includes or calls) some other .props file. Look for that file and use a text editor to open it, here it is in C:\Program Files\MSBuild\Microsoft.Cpp\v4.0. This gives you and idea of how .props files are structured.
Now, you can make your own .props file and in it set the include and lib paths like you want them (maybe set additional settings as well) and finally you have to add an <Import.../> line in your .vcxproj files manually. Don't worry, VS will not remove it, even if you make changes to the project.
Helpful web sites for .props programming:
Visual C++ Team Blog: http://blogs.msdn.com/b/vcblog/ (look around there, it's a treasure trove)
A guide to .vcxproj and .props file structure: http://blogs.msdn.com/b/visualstudio/archive/2010/05/14/a-guide-to-vcxproj-and-props-file-structure.aspx
Is it possible to use a visual studio macro within a .config file? For example, can create a appSetting like this, where $(ProjectDir) maps to the directory where my .csproj file is located?
<appSettings>
<add key="myDirectory" value="$(ProjectDir)\App_Data\myDirectory"/>
</appSettings>
After searching around, the short answer to this question is 'no'.
Having macros within a .config file would mean that the web.config file would not be able to be properly interpreted when deployed somewhere other than the debug environment.
I'm using vs2010 and I need to log a multithreading application.
So I decided to use log4net, but as I'm not used to work with this, Intellisense is gonna be worth.
I download the .xsd from http://csharptest.net/downloads/schema/log4net.xsd and put this in VSFolder/Xml/Schemas.
But, how can I say to my log4net.config to use the XSD Schema?
Use the menu XML -> Schemas...
The menu is only there if you have the config file (or any other xml file) open.
Instead of putting it into a VS folder, put it somewhere inside your solution's folder tree. It doesn't even need to be included in any projects. just put it there and it works...
Or into: C:\Program Files (x86)\Microsoft Visual Studio 10.0\Xml\Schemas and you're sorted once and forever.