We have a batch-based buildprocess and we are using MSBuild only for compiling our project-files from visual studio. We also have integrated wix into our build-process. To set the version of our software we specify in the main-build-script some environment variables, that we use during the build-process.
My problem is, that i have to set the FileVersion of the Assembly (AssemblyFileVersion) in my assembly-informations.
Is there a way to give the MSBuild-call a property with the version to set? Like this (this doesn't work):
%dotnetdir%msbuild.exe Viewer.csproj /property:Configuration=Release /property:Platform=AnyCPU /property:AssemblyFileVersion=%major%.%minor%.%build%
The resulting assembly should have the fileversion %major%.%minor%.%build%.
It's pain for me to set the AssemblyFileVersion-setting in all projects. And a program which is doing this is against my philosphy (i don't want to change my source with automated processes). The version should be set through the build-script. It is not necessary that the AssemblyFileVersion is set in the AssemblyInfo.cs
Or is there a possibility with MSBuild to specify a xml-configuration-file which describes the assembly-informations?
Would be great if there are any advices.
greetings, thanks,
Martin
The Version and AssemblyInfo tasks from the MSBuild Community Tasks project may help.
Related
What I've been strugling with for some time:
I have a "traditional" (i.e. non-SDK) csproj file. I want to create a nuget package. That's easy but devil hides in the details and I end up in the following catch-22
I can manually call nuget pack .\Foo.csproj, with or without a nuspec file, but then I get the dreaded NU5128 error. The chosen answer suggests to simply ignore the error. I would happily do that, but after publishing the package locally, I noticed that the dependencies are not included. Though there is one dependency to JSON.net that I added for the sake of testing. The same error appears in AppVeyor if I configure my yml to create the package.
I can specify all the packaging related properties in the .csproj file by setting GeneratePackageOnBuild to true. It works and takes the dependencies right but then I can't patch the version like I could do with the replacement tokens of nuspec. The version defaults to 1.0.0.0 even if I change it in the AssemblyInfo.cs to 1.2.3.4.
Notes
This answer suggests that nuspec and csproj configuration can coexist and they are merged. The question is from 2013 so I guess it's not referring to SDK projects. Unfortunately that's not the case for me.
I tried adding a <NuspecFile> in the csproj but then it seems that replacement tokens don't work and I get the error described here. Probably because this instructed nuget to run pack on the nuspec instead of running it on csproj and merge the nuspec. I can't know for sure though as setting the build verbosity to Detailed didn't help to understand what nuget pack tried to do.
Getting the AssemblyInformationalVersion in msbuild and use it straight to the <Version> property isn't as straightforward as one might think and it also defeats the purpose as $version$ is doing exactly that according to the documentation:
AssemblyInformationalVersion if present, otherwise AssemblyVersion
Is there a way to really "merge" .csproj and .nuspec with $version$ patching and get the dependencies in the nuspec right?
So far the best course of action was to convert the project to SDK format. It has several advantages. Less configuration, no need for .nuspec file, no need for AssemblyInfo.cs or VersionInfo.cs files, .nupkg dependencies are correct and AppVeyor can patch directly the .csproj file if it's an SDK project file.
Not a solution per se if one wants to keep the legacy format, but it gets you going with the CI/CD instead of having you fighting with tools.
We are using cc.net (cruise control) and msbuild to build a click once application. This is the msbuild task:
<msbuild>
<executable>C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe</executable>
<workingDirectory>D:\Directory</workingDirectory>
<projectFile>proj.lsxtproj</projectFile>
<buildArgs>/t:publish /p:PublishLocation=D:\Publish\;AssemblyFileVersion=$CCNetLabel;AssemblyVersion=$CCNetLabel</buildArgs>
<targets>Build</targets>
<timeout>600</timeout>
</msbuild>
So I am trying to set the assembly file version and assembly version of the published output.
The issue is that the variable $CCNetLabel does not seem to work. If I set AssemblyFileVersion and AssemblyVersion to something like 3.2.0.0 then the output has this version number but $CCNetLabel just does not work.
Has anyone got any ideas how to make this work?
Thanks
Ian
If the problem is that $(CCNetLabel) is blank try using the 'dynamic' variable. So instead of:
AssemblyFileVersion=$CCNetLabel;
use:
AssemblyFileVersion=$[$CCNetLabel];
Otherwise have a look at this other question which has more information re AssemblyInfo.cs and may help:
Using CCNetLabel to set AssemblyVersion and PublishVersion with CruiseControl.NET
I am using Windows installer xml and now my project moves to Team Services.
However, my Paths wont work anymore and I need to update my setup.
On the local build machine I used this hardlink: C:\Projects\Solution\Project\bin\Release\Assembly.dll
My Question: What is the best way to build 4 projects and then run a 5th project, which uses the assemblies in the bin/release directory?
Add a reference to the project and then use $(var.Project.TargetPath) instead of the hardlink (or $(var.Project.TargetDir)Assembly.dll). The references will add dependencies on those projects to the wixproj which means they all must be build before the wixproj so all the binaries will exist. All the projects should be included in the same solution as the wixproj.
Here's a resource for all the automatically defined compile time variables you can use http://wixtoolset.org/documentation/manual/v3/votive/votive_project_references.html
Alternatively if you can't do it this way you can define the variables in the <DefineConstants> of the wixproj. It would be something like "ProjectDir=$(MSBuildThisFileDirectory)..\Project\bin\Release\" and then in your wix component where you are using the SourceDir hardlink you would use SourceDir=$(var.ProjectDir)Assembly.dll
All of this stuff is taking advantage of MSBuild. It takes a long time to wrap your head around how MSBuild works but it is definitely worth it if you will be using Visual Studio to build all your projects.
I'm trying to use MSBuild to create a target that will create an installer with InstallShield 2012. I'm having difficultly understanding how to access InstallShield. I ran across this mentioning an InstallShield task but I'm not sure how to get access to it. I think I need a UsingTask directive, but not sure what to import. Can someone give me a pointer on how to get this going? Thanks.
You need to import the targets file. Took me a while to figure that out as well since it's in the msbuild extensions directory together with a dll. Here's a basic sample of how to use it (note this is for 2012Spring but you get the idea):
<Import Project="$(MSBuildExtensionsPath32)\InstallShield\2012Spring\InstallShield.targets" />
<Target Name="BuildInstaller">
<InstallShield.Tasks.InstallShield
Project="/path/to/my.ism"
ProductConfiguration="Package"
ReleaseConfiguration="MSI" />
</Target>
Btw if this doesn't work out for some reason, you can always invoke ISCmdBld.exe in an Exec task, it will do the job just as fine.
InstallShield provides Visual Studio integration. When you create an InstallShield project in VS it creates a project file (.ISPROJ) which imports the InstallShield.targets file for that version of InstallShield. The project file contains plenty of examples on how to build a particular configuration and pass in such things as merge module path, properties, path variable overrides and so on.
Please note that building InstallShield requires the x86 MSBuild platform due to COM components.
How do I need to indicate to the msbuild task in my nant script that it should use .net 4.0 rc?
I think the latest NAnt/NAntContrib defaults to .NET 3.5, so you'll have to change that to 4.0. There is a NAnt property to handle that (<property name="nant.settings.currentframework" value="net-4.0" />), which should go near the top of your NAnt build file.
Next, you'll need to go into your NAnt's configuration file and add the 4.0 node, so that NAnt (and by extension NantContrib) are aware of the new CLR version.
The first option is to change the executable that MSBuild task uses. According to the doco this is a framework property so you would need to change it in the main nant config file rather than in you're individual script, and you would have to do it on every machine you plan on building the script on.
The other option is to use the exec task instead. This question and answer should help with that.
EDIT: Forgot to mention the directories MSBuild is in. To change versions just use a different MSBuild.
2.0: %windir%\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe
3.5: %windir%\Microsoft.NET\Framework\v3.5\MSBuild.exe
4.0b2: %windir%\Microsoft.NET\Framework\v4.0.21006\MSBuild.exe