I have a question about MSBuild.exe and Environment Variables. First, the development environment:
The code is mostly C++ with some C#. There are over 5,000 classes, 340 projects and 200 solutions arranged in a deep source tree. There is a solution at the root of the tree and at various other points in the tree. We use TFS and maintain multiple active branches for a series of future releases. Each developer uses a local view to modify and test code. Some developers work on multiple branches concurrently. Sometimes developers build solutions from different TFS branches concurrently.
We use about 70 environment variables for locating shared header files, libraries, etc. In VS2008 we used a file with the same base name as the solution file and an extension of .slnenv for defining the environment variables. All variables are defined relative to the base of the source tree. This .slnenv file is read by a custom VS2008 AddIn that creates Environment Variables in the VS2008 process space, i.e.
MyProjectDir=$(SolutionDir)\..\..
MyRoot=$(MyProjectDir)\..\..
MyInstallDir=$(MyRoot)\Install
MySourceDir=$(MyRoot)\Source
MyUnmanagedSourceDir=$(MySourceDir)\My\Unmanaged
MyIncludeDirs=$(MyProjectDir);$(MyUnmanagedSourceDir)
This AddIn does not work correctly with VS2010 because MSBuild does not inherit the environment variables that are created after the solution is loaded.
My question is how do I get these environment variables to MSBuild? I have found two methods that work, but are not as convenient as the AddIn we had been using.
VS2010 can be started with a command script that first sets Environment Variables in the process space and then starts VS2010. MSBuild does inherit these Environment Variables. This is unsatisfactory because the scripts would need to be customized for the various points where a solution can be loaded.
The second method I have tried is defining the Environment Variables as Properties in property sheets and .vcxproj files. We have a base property sheet that all .vcxproj files load. In that property sheet:
<PropertyGroup>
<MyRoot>$(MyProjectDir)\..\..</MyRoot>
<MyInstallDir>$(MyRoot)\Install</MyInstallDir>
<MySourceDir>$(MyRoot)\Source</MySourceDir>
<MyUnmanagedSourceDir>$(MySourceDir)\My\Unmanaged</MyUnmanagedSourceDir>
<MyIncludeDirs>$(MyProjectDir);$(MyUnmanagedSourceDir)</MyIncludeDirs>
</PropertyGroup>
Then I can define the base directory in each .vcxproj file:
<PropertyGroup>
<MyProjectDir>..\..</MyProjectDir>
</PropertyGroup>
This method uses relative path names where the AddIn resolved all Environment Variables to absolute path names. I'd rather not have to edit 340 .vcxproj files where the definition of "MyProjectDir" would vary depending on how far from the source root the project file exists. So far I've tried this method in just one project.
I have tried to modify the AddIn to create Properties rather than Environment Variables. I tried using ENV2.get_Properties(), but that seems to work only for Properties that are defined in VS2010, not for Properties I've defined.
Thank you,
Dan Kary
After discussion via email, we figured what were Dan needs and following message helps him with question issue. He agrees that this could be helpfull to other SO members:
Aha, I get it now.
As I did understand from that topic - you really need all that stuff only for build step (paths for include clause, paths to built tool to resolve dll\exe dependency), and no regular developer activities depends on it.
It's good, cause we don't need to fight VStudio about not reinitializing env vars after first load. We just need somehow edit and implement your solution for huge amount of proj files ;) Task become much easier :D
Small disclaimer - I'm writing this on the road and have no access to fully fledged dev env to check and bulletproof all further recomendations, so take my apologizes in advance for any mistakes I will make ;)
I would like to bring your attention to some msbuild features:
http://msdn.microsoft.com/en-us/library/ms164309.aspx
You have predefined properties, that available for all scripts and projects, it looks like this will help you solve first issue - absolute paths instead of relative. This is small excerpt from the link for further reference
$(MSBuildProjectDirectory) -
The absolute path of the directory where the project file is located, for example, C:\MyCompany\MyProduct.
$(MSBuildProjectFile) -
The complete file name of the project file, including the file name extension, for example,
MyApp.proj.
$(MSBuildProjectExtension)
The file name extension of the project file, including the period, for example, .proj.
$(MSBuildProjectFullPath)
The absolute path and complete file name of the project file, for example, C:\MyCompany\MyProduct\MyApp.proj.
$(MSBuildProjectName)
The file name of the project file without the file name extension, for example, MyApp.
So you should be able to use this defined properties in your Property sheets.
Now, with msbuild 4.0 toolset (toolset defined by attribute ToolsVersion="" on the root script element) there is interesting trick
Microsoft.Common.Targets define 2 variables to conditionally import custom msbuild script before or after itself
CustomBeforeMicrosoftCommonTargets and CustomAfterMicrosoftCommonTargets
You can use it the following way ( I think it will possible help you to avoid editing of all proj files or at least - reduce editing to very simplified copy-paste part)
Define it using relative path to include your property sheet files
<CustomBeforeMicrosoftCommonTargets>$(MSBuildProjectFile)\ConcreteProjectCustomProperties.propz</CustomBeforeMicrosoftCommonTargets>
Take a note that CustomBeforeMicrosoftCommonTargets should be global scoped property to be inherited by all secondary
And if you properly define your ConcreteProjectCustomProperties.propz I think you could achieve what you need.
"Properly" is that you will include there your global properties file (with relative or absolute path) and then define all your project-level properties.
NB:
Also take a note that later defined properties not available for reference to early defined
Your example defines $(MyIncludeDirs) with reference to $(MyProjectDir), but $(MyProjectDir) declared and defined a bit later.
It could be due to "exampling" and fast churning that code, but if you define your vars same way in production - it could lead to subtle error.
I hope I got your problem properly and my explanations will help you to quickly move all your properties from custom add-on to simpler and native msbuild script ;)
Related
I'm currently trying to make a library with several variable definitions I can use in different Setup Projects but without success.
I have several huge *.wxs files which are build into a library where the File/#Source should depend on project settings. The reason for that is our internal directory structur which looks like any\path\Redistributables\In-Test\X64\productA or any\path\Redistributables\RC\X86\productA so the last 2 parts of my path should change e.g. on x64 and x86 build.
Now I have several Setup Projects too which uses the same path but working in another subdirectory e.g Redistributables\In-Test\X64\AnyOtherProductB.
I dont want to pass preprocessor variables with the same values to each project because the path could change later and I would have to edit too many project settings then.
So my question:
Is it possible to build something like a "Variable/property Container" with public variables/properties so I could just reference that library to use the variables defined in it for my <component><file source...>?
I've tried to achieve that with prepocessor variables before $(var.sourcedir)$(var.compilemode)$(var.platform) with no luck. These 3 are the parts I need to define once to use them in nearly all projects.
Small edit here, I do this a lot where I read the question quickly and make an answer then reread the question and think my answer doesn't quite fit the question but in this case I hope it is still helpful and maybe one of the other resources referenced here will help as well.
Ah I did something like this and banged my head against the wall for a while trying to figure it out.
The problem is you can't use variables like $(var.sourceDir) in the wixlib and then change it later on when you use the lib in a project. What happens is the compiler replaces $(var.sourceDir) in your wixlib with the actual value of this variable when you build it. You can verify this by opening up your obj file and looking for a component or something that uses this directory and see that it has the value of the sourceDir variable not $(var.sourceDir).
To solve the issue we are going to use bind/wix variables (not sure of the terminology) which get evaluated at linking time.
This was the "how to" that I eventually got to which helped me a lot
So, update your variables to something like this !(bindpath.SourceDir)
<Fragment>
<util:RegistrySearchRef Id="MSVCPPRedist_x64_12"/>
<PackageGroup Id="MSVCPPRedist_x64_12">
<ExePackage
Id="MSVCPPRedist_x64_12_0_21005"
Cache="no"
Description="Visual C++ 2013 Redistributable needed for [WixBundleName]"
DetectCondition="MSVCPPRedist_x64_12 OR NOT VersionNT64"
DisplayName="Prerequisite - Visual C++ 2013 Redistributable (x64)"
InstallCommand="/install /quiet /norestart /log vc12log.txt"
PerMachine="yes"
Permanent="yes"
SourceFile="!(bindpath.PrerequisitesDir)VC++\vcredist_x64_12.exe"
UninstallCommand="/uninstall"
Vital="yes"/>
</PackageGroup>
</Fragment>
And then in some props file or project file on the build machine you can include something like this:
<LinkerAdditionalOptions>-b "PrerequisitesDir=$(PrerequisitesDir)\"</LinkerAdditionalOptions>
Where the $(PrerequisitesDir) property was set based on a relative path in a msbuild file on the build machine like so (or use absolute path is also fine):
<!-- Directories -->
<PrerequisitesDir>$(MSBuildThisFileDirectory)..\..\..\Installers\Prerequisites\</PrerequisitesDir>
Now when you build the linker phase will use the build time defined bindPath to find the source files.
In regards to the platform and configuration vars, I think you can use WixVariables referenced as !(wix.VariableName) but I'm not sure off the top of my head and without more experimenting myself. You can take a look at this answer here to help get more acquainted with the different types of variables. If WixVariables don't work you can just build several flavours of yoru wixlib and reference the appropriate one in your wixproj themselves by using the MSBuild properties $(configuration), ect.. in the hintpath of the wixlib file.
I have a custom tool that I run on certain file types using the .targets mechanism in Visual Studio 2015.
Projects exist at many levels, and I want to reference this tool when the code is pulled to ANY drive/folder, including the TFS CI agent.
I tried using a relative path, but because the files are at different levels, it doesn't work for all projects.
I tried using a registry setting and environment variable, but that doesn't bode well for the CI machine which might build in a different folder each time.
Is it possible to get the solution folder of which the project/file is in, then I can use a relative path to the tool directory?
All I can find is these properties, which do not seem to help:
General MSBuild properties:
https://msdn.microsoft.com/en-us/library/bb629394.aspx
https://msdn.microsoft.com/en-us/library/ms164309.aspx
Registry and environment variables:
https://msdn.microsoft.com/en-us/library/ms171458.aspx
You can use all the standard tokens within .targets.
Just use
$(SolutionDir)
See https://msdn.microsoft.com/en-us/library/c02as0cs.aspx
Self-service answer: use visual studio's property editing for a vcxproj in preprocessor macros or include paths or such to look at a bunch of available variables. You can usually find what you need in there, by name, or by example, including the one you need here. Better than any documentation.
I want to use Visual Studio's property pages to define some commonly-used paths as user macros - e.g., to the location of third-party libraries, or the base directory of the repository.
However, I'm only managing to define user macros either:
Using an absolute path -- obviously wrong
Relative to the project directory
Relative to the solution directory.
None of those work for me, since our codebase has multiple VS solutions and some projects are shared between solutions.
For example, if I have the following structure:
$(BASE_DIR)/dirA/Solution1/Project1
$(BASE_DIR)/dirB/dirC/Solution2/Project2
$(BASE_DIR)/ThirdPartyLibs
... and I want to define a $(ThirdPartyLibDir) macro. Or, heck, a $(BASE_DIR) macro.
Let's say Solution 1 has only Project 1, and Solution 2 includes Project 1 and Project 2. In this case, I can't define these macros relative to $(SolutionDir), nor to $(ProjectDir).
Is there any way I can define such a macro?
(If there were a macro for getting the location of a property page file, I could put a .props file in $(BASE_DIR), and define the macros that way. It doesn't look like that exists.)
One way to achieve this is to do the following -
Create one property sheet per solution and create a user macro BASE_DIR inside it with a relative path (....\ etc.).
Create a common property sheet that contains the actual library locations etc. based on the BASE_DIR macro. Add this sheet to the projects too.
This allows you to specify include directories and other "common" properties using the $(BASE_DIR) macro in the common props file. The solution-specific property sheet provides the $(BASE_DIR) value relative to the projects in the solution.
There a lots of environment variables in my project properties that I do not understand. Clicking on macros (Is there a list of Visual Studio environment variables?) gives me a list of their values, but I am unable to figure out where some of these are set.
For example, I am trying to figure out where the variable $(IntDir) is being set.
What file is responsible for setting these variables? How can I modify them?
These are not environment variables.
They're just macros defined by the build system that you can use for setting build properties for your project. They automatically expand to things like the target platform ($(Platform)), the path to store intermediate files for your project ($(IntDir)), and the name of your project ($(ProjectName)).
You can't change them directly, but you can change them by modifying your project's properties. The project file (created automatically by Visual Studio when you create a new project) is responsible for setting them.
You already found a link to the big list of 'em, which is helpful in explaining what they are and what they do. As the documentation says, you can use them anywhere in your project's property pages that string values are accepted. They keep you from having to hard-code paths and other information, which is exceptionally useful.
Unlike environment variables, they do not persist or have any meaning independent of your build system. Once your project has been built, they go away. They're not used during debugging or deployment.
.If you want to see actual values for a specific VS instance for both 'standard' and 'custom', see if this answer helps. (Basically, you can use Process Explorer to find that out.)
Is there any way one can define for a solution a global variable accessable by any project file or project property sheet included in the solution?
One variable is enough if that can define a path for a property sheet that every project can include.
This is desirably for a solution.
An environment variable would be ok though less desirable.
** (visual studion 2010)
Poking at it again, I can't see how to set a user defined $(xxx) vartiable in a project - yes you can in a property sheet, but In a project I have reference to the $(ProjectDir) -
The problem is I want to define a $(tree of projects root) that any project that references a specific poject can access and the root will be relative to that project.
An alternative would be if a property sheet can have access to its own path and define the project collection root (of a tree of related projects with common resources) relative to that.
It seems every one building a big system with VS has the same problem.
I don't know your use case but it doesn't sound like the best idea. This will tie all of your projects together very tightly, which violates good OO design. Microsoft hasn't included any solution-level properties for this reason. However, if you really want to do something like this, you have two ways (at least) to go about it.
The first way, and the way I would recommend against, would be to store the variable in one of your projects and make it public. Then all of your projects could access it as long as they include the project as a reference.
The second way, and the way that will retain some OO principles, would be to create a config file that all projects looked at for the variable. This could be an XML file, a CSV file, or even a simple text file. If you wanted to get more complicated, you could point to a database location since this is one of the roles of a database.