I have a question regarding the commandline options of msbuild. I am
currently using msbuild to build projects using the existing solution
files. These solution files have references to external dll which have
different paths on each machine. I am currently writing a build script
and passing the specific path to the project file via the /p: switch of
msbuild.
My current build line is:
msbuild test.sln /p:ReferencePath="c:\abc" /p:ReferencePath="c:\rca"
What i have noticed that Reference Path now contains only c:\rca and
not c:\abc. this is causing problems for me since, the external dlls
lie in two different directorys. I am allowed to keep multiple
reference paths via visual studio, but not via the commandline.
Is there any known way by which i can do this
I believe you can use this /p:ReferencePath="c:\abc;c:\rca"
At least that is what that link is hinting at, they are using %3B to encode the ";" within the build file.
Although the correct syntax for providing more the one reference path is listed above, I would suggest solving the root cause which in my opinion is the different locations of your referenced assembly. I would suggest you put all thirdparty dependencies, apart from the framework assemblies in your source code repository for the following reasons:
Relatitve paths are consistent across computers
The source code is always in sink with the correct version of your thirdparty assembly (if you for instance need to build an old version of your software 2 years from now).
Upgrading your thirdparty assembly is as easy as upgrading on one machine and then committing your changes to the repository. (In a previous project we even went as far as checking in the entire java runtime environment and were quite happy with the given setup.)
Try seperating your pathes with a semi-colon (;)
Like this:
c:\abc;c:\rca
You may be better off by synchronizing your libraries across machines. I have found that Visual Studio makes this easy. Simply add a solution folder, and add your libraries there. Then, in each project, reference the libraries from this common place. This way, each developer has them in the same place.
This will remove one of variables you have when trying to script out builds.
The command line options for setting the reference path will work just fine (assuming you escape the semi colon, it seems both %3B and ; will work). However, when the argument was passed in from nant (and I needed multiple paths), creating a 'Visual Studio Project User Options file' seemed to work better.
I just emit (echo) a file to the file system with the following format:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<ReferencePath>
C:\abc;c:\rca
</ReferencePath>
</PropertyGroup>
I give the *.user file an appropriate name (given a project file MyProject.csproj, my user file would be MyProject.csproj.user)
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'm looking for a way to call MSBuild with all possible configurations/platforms defined in the solution file.
I've looked here:
Using MSBuild to Build Multiple Configurations
which requires explicit knowledge of the configurations, as you must enumerate them on the command line,
and here:
http://social.msdn.microsoft.com/Forums/vstudio/en-US/066c9dbf-d191-4b8c-8ee1-b9709b56c500/msbuild-for-visual-studio-2010-build-all-configurations-of-a-vcxproj-file?forum=msbuild
which leads to another page that suggests defining another project file to encapsulate the msbuild calls. Unfortunately, it too requires explicit knowledge of the configurations.
So then, is there any way to obtain through the command line, the list of configurations/platforms availalbe to a given project? (It must be the same list that is modified in Visual Studio. ie: adding/removing a configuration in Visual Studio, saving, exiting, and getting the list, would reflect the changes.)
Parsing the solution file as XML is not an option, as it wouldn't be stable if Microsoft decided to change how it is formatted.
You can't parse a solution as XML it's not a markup file without having MSBuild emitting a meta project first. I recommend you play the odds and be pragmatic, read the .sln as a text file and RegEx it on SolutionConfigurationPlatforms pairs, then build the ItemGroup and batch it. If you are truly utterly paranoid about Microsoft completely reengineering the solution file syntax then look inside Microsoft.Build.Construction and/or .Evaluation, the internal SolutionParser, or Roslyn or even Mono since if the syntax changes then those parsers and loaders would be updated accordingly and in case of Microsoft.Build and Roslyn -- simultaneously.
That the logical follow-up for the my previous question: "How to check all projects in solution for some criteria?"
I was given quite a good answer to use CustomAfterMicrosoftCommonTargets, CustomBeforeMicrosoftCommonTargets. They do work, so I decided not to stop in the middle.
Issue is that I don't want machine-wide tasks. It's not a good idea neither for me (it will affect other builds. sure, this can be handled, but still), nor for my teammates (I don't want to let them put something in system folders... ), nor for build server.
What is needed: solution to be built from scratch out of source control on clean machine with either Visual Studio or MSBuild.
It appeared that Custom*MicrosoftCommonTargets are regular properties.
So, how to specify this property? It works pretty fine when to set it from command line.
That's strange, but it appears that bit of magic present here: property passed as command line parameter to one build is transitively passed to all nested builds!
That's fine for build server. But this won't work with Visual Studio build. And even declaring solution-level property won't help: neither static, nor dynamic properties are transfer to nested builds.
...I have a hacky idea to set environment variable on before solution build and erase it on after. But I don't like it. Any better ideas?
I use a bit different technique then #Spider M9. I want that all projects in solution tree/all subdirectories from current directory use extended build throw Custom*MicrosoftCommonTargets. I don't like to be forced to change every new project to import custom targets/props.
I place special file, let's say msbuild.include, in the root directory and my custom targets loader for every project tries to find it in ., ..\, ..\..\, and so on. msbuild.include contains flags that triggers execution of custom actions. If loader can't find this file it disables loading all custom targets and stoppes. This gives me ability to use my build extensions with projects from work repositories and to not use with opensource projects.
If you are interested in I can publish loader. It's a pretty simple and elegant solution.
For example I can sign any assembly in all projects in all subfolders with my key.
I always set up every project to import a standard .props file. Use the GetDirectoryNameOfFileAbove property function (see MSDN) to find it. Do this as the first line of every project file. Once established, you can redirect from that file to other imports. Another trick is to have that standard import (that would obviously be under version control) import conditionally another .props file only if it exists. This optional file would not be in version control, but is available for any developer to create and modify with their own private/temporary properties or other behavior.
My solution has a library project which needs a special environment to be built (lots of external libraries and tools)... but it is not vital to our application. We'd like to avoid installing these tools when not necessary (most of our developers work on other parts of code).
We have created another project which has the same API, but has an empty implementation and is compilable without those external tools. I'd like to be able to easily switch between those projects and still get all the references in other projects correct.
I don't know VS/MSBuild very well, but willing to learn whatever is necessary. Is it possible? I am looking for ideas... We're using Subversion, and solutions involving some hacks inside VCS are also welcome.
It sounds as if your library project is one that can be separated from your primary solution, taking the tool baggage with it. Doing that, you could build the speciality solution separately, an link the compiled assembly from the main solution.
Create another build-configuration for your project.
So you will have at least 2 build-configurations e.g. Debug_SpecialNeeds and Debug.
For discussion, I'll assume you have a project directory containing your solution file, a "RealLibrary\RealLibrary.csproj" project file (your "real" library, with the dependencies), and a "MockLibrary\MockLibrary.csproj" file (your "mock" library, with the empty implementations).
If I understand correctly, you want to easily "swap" the MockLibrary for the RealLibrary in your solution, and vice-versa.
The easiest/hackiest way to do this, assuming your solution (and dependent projects) are configured to look for the "RealLibrary.csproj" project, is to rename the "RealLibrary" directory (it doesn't matter to what), and rename the "MockLibrary" directory to "RealLibrary" and rename "MockLibrary.csproj" to "RealLibrary.csproj". This will effectively "trick" your solution and dependent projects into loading the "mock library" even though they are referencing the "real library".
A slightly more complex (and perhaps cleaner) solution is to actually modify your "sln" and "csproj" files to reference "MockLibrary.csproj" instead of "RealLibrary.csproj". In the "sln" file, you'll need to change the path to the project in the section near the top:
Microsoft Visual Studio Solution File, Format Version 10.00
# Visual Studio 2008
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "RealLibrary", "RealLibrary\RealLibrary.csproj", "{E1714F9A-E1D9-4132-A561-AE2B4919391C}"
EndProject
You need to change that path "RealLibrary\RealLibrary.csproj" to "MockLibrary\MockLibrary.csproj". If you're going for completeness, you can change the name as well (or perhaps just use a generic name like "Library" for the name).
Likewise, in the dependent csproj files, you'll need to find all instances of the "ProjectReference" node where you reference "RealLibrary.csproj" and modify the path. These sections look like this:
<ProjectReference Include="..\RealLibrary\RealLibrary.csproj">
<Project>{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</Project>
<Name>RealLibrary</Name>
</ProjectReference>
You could relatively easily write some scripts to perform this swap. However, I think there's a deeper problem here that can be addressed more directly. I'll post that as a separate answer, but I wanted you to have the actual answer you were looking for first.
The deeper problem I see here is that your library "needs a special environment to be built", specifically because it depends on "lots of external libraries and tools". I would suggest that you NOT go down the path of creating the mock library, but instead focus on getting the library to build correctly without a special environment. You can achieve this by including all of those dependencies in source control along with your project, and reference those dependencies via relative paths inside your working copy. In my build environments, I try to avoid static environmental dependencies as much as possible (ideally limiting it just to the .NET framework itself).
To get the dependencies into source control, you can either check them directly into the project itself, or you can check them into a different location and then "reference" them in your project via svn:external definitions. In my environment, I have a separate "bin" repository used just for these kind of third party library dependencies, and then many dependent projects can pull them in via externals.
If you can eliminate your library's build-time environmental dependencies, your build will be much more robust and it will be much easier for developers to work with the project.
Let's say you have a class library project that has any number of supplemental files that also need to be included with the compiled assembly (e.g. simple text files or even a legacy unmanaged DLL that's wrapped by the assembly as an interop layer). While embedding the supplemental files into the assembly itself is relatively straightforward, we have situations where this is not possible or just undesirable. We need to have them as "sidecar" files (i.e. files alongside the assembly, potentially in subdirectories relative to the assembly)
Adding those files to the project with an appropriate value for "Copy to Output Directory" specified appears to be sufficient for projects that are completely self-contained within a solution. But if a separate project in another solution adds a reference to the assembly, it does not automatically pickup its sidecar files. Is there a way in the project to somehow mark the resulting assembly such that anything referencing the assembly will also know it needs to include the associated sidecar files? How do you do this?
You can use al.exe, but there also appears to be a C# compiler option. You want to create a multifile assembly using the /linkresource C# compiler option. Instructions are here, but the command is similar to this:
csc /linkresource:N.dll /t:library A.cs
Where N.dll is a native DLL that will go wherever the managed assembly goes (including into the GAC.) There's a very clear description at the link I provided.
Have you tried creating a setup for your solution ? There's an option of including sidecar files targeting to application installation directory.
Another option would be to include the sidecar files in the Assembly resources and un-wrap them to disk when run for the first time.
What if you create a merge module containing the library plus its dependencies? Your installer will then need to reference this module, but you will ensure all of the necessary files will be present.
Unfortunately there doesn't appear to be a lot of built-in support in Visual Studio for this, although I can definitely see the use case.
If you use Subversion for your source control, then you could link in an external reference as an externals definition. This would bring in the source code, and you'd be making a reference to the necessary assembly as a project reference instead of a DLL reference, and then the copy to output directory rules would come into play.
If that's not possible, another solution would be to include commands in the pre/post-build events of your in-solution project to copy the most up-to-date sidecar files from the remote assembly on a build. Of course this comes with the caveat that it doesn't set itself up automatically when you include the DLL in your project; you have to take manual steps to set it up.
I deal with this some time ago. Its a common problem.
You can create some postbuild actions:
http://www.codingday.com/execute-batch-commands-before-or-after-compilation-using-pre-build-or-post-build-events/
Hope this helps... :)
It appears to me that you're using the wrong type of reference. There are two types of references- Reference and ProjectReference. Reference is an explicit reference to a specific assembly. ProjectReference is a reference to another project (say .csproj).
What you're looking for is ProjectReference. VS and the default MSBuild targets are setup to do CopyLocal. If you set CopyToOutputPath true for your "sidecar" files, any ProjectReferences to this project now will also pull in the same files.
I'm not sure if you can to ProjectReferences across solutions in the IDE. I deal a lot with MSBuild where sln files are not relevant and this is how I deal with it.
What we did in our project is that we created as separate build file to do all those stuffs.
In your build file you can have tags to build your main solution, then add tags to copy files you need after build.
NAnt is also your option, but right now I'm happy using Rake as my build/debug automation.
Since this cannot be integrated within Visual Studio, what I'm doing is I create a task (either in MSBuild, NAnt or Rake), that executes vsjitdebugger.exe in the end to attach it to my Visual Studio when debugging.
These are just my styles for now, you can maybe create your own style.