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
Related
NuGet apparently has some logic to determine what MSBuild Executable to use. Is there a way to override this behavior? Or at least a way to tell it to use the x86 MSBuild instead of x64?
MSBuild auto-detection: using msbuild version '14.0' from 'C:\Program Files (x86)\MSBuild\14.0\bin\amd64'.
From the command-line documentation, you can specify -MSBuildPath or -MSBuildVersion on the command line.
MSBuildPath (4.0+) Specifies the path of MSBuild to use with the
command, taking precedence over -MSBuildVersion.
MSBuildVersion (3.2+)
Specifies the version of MSBuild to be used with this command.
Supported values are 4, 12, 14, 15. By default the MSBuild in your
path is picked, otherwise it defaults to the highest installed version
of MSBuild.
The msbuild version used by nuget command line on mono is hard coded:
Cf source code https://github.com/NuGet/NuGet.Client/blob/f24bad0668193ce21a1db8cabd1ce95ba509c7f0/src/NuGet.Clients/NuGet.CommandLine/MsBuildUtility.cs
The offending method is GetMsBuildFromMonoPaths(...)
There is no env var to override it. It's called "auto detection" lol.
A solution is to move away the /Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/15.0 folder, install msbuild 16.0 using dotnet-install.sh method (use version 5.0.402 for msbuild 16), and create a symbolic link from dotnet/sdk/$netcoreversion to the hard coded path /Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/15.0
We have been using a Bamboo build server for a while now and we have GitVersion installed so it can be selected as a task in the Build plan. We typically use the /UpdateAssembleInfo argument when we run the task. For .NET Framework projects, this would update the assemblyinfo file in the source with the bamboo versioning settings so the .NET assemblies had the same version info as our Bamboo builds and subsequent Bamboo deployment, allowing us to know the version of the deployed project in the field by examining the assembly file properties. This was all working quite well.
However, we are now building and deploying .NET Core 2.0 solutions and are finding that GitVersion /UpdateAssemblyInfo is not working.
I searched for a fix for .NET Core but was only able to find solutions that involved using the project.json file, which is no longer used with .NET Core 2.0 ( it changed to the *.csproj file).
I looked at http://gitversion.readthedocs.io/en/latest/usage/command-line/ and I tried running
gitversion.exe /UpdateAssemblyInfo MyProjectName.AssemblyInfo.cs /EnsureAssemblyInfo
where MyProjectName represents the actual project name suffix for the assemblyinfo.cs file in the .NET Core 2.0 ..\\obj\release\netcoreapp2.0 folder. But it did not update that file.
I have to assume that there has to be a solution for using GitVersion with Bamboo and.NET Core 2.0 but I am having a hard time finding one.
Any ideas?
The latest version of GitVersion provides /updateprojectfiles switch to update version info in the Sdk-style .csproj/.vbproj/.fsproj recursively.
From GitVersion/Usage/CommandLine/Arguments:
/updateprojectfiles
Will recursively search for all project files
(.csproj/.vbproj/.fsproj) files in the git repo and update them
Note: This is only compatible with the newer Sdk projects
It produces the needed attributes even if they are not present in the project files, resulting in following properties:
<Project>
<PropertyGroup>
<AssemblyVersion>1.0.0.0</AssemblyVersion>
<FileVersion>1.0.0.0</FileVersion>
<InformationalVersion>1.0.0-versionNumber.N+Branch.branchName.Sha.commitId</InformationalVersion>
<Version>1.0.0-versionNumberNNNN</Version>
</PropertyGroup>
As a workaround, you may consider specifying the assembly info as project properties in .csproj
<PropertyGroup>
<Version>1.2.3.4</Version>
<AssemblyVersion>2.0.0.0</AssemblyVersion>
...
</PropertyGroup>
and then setting values during dotnet build. In addition to its options, the dotnet build command accepts MSBuild options like /property
/property:name=value
/p:name=value
Set or override the specified project-level properties, where name is the property name and value is the property value. Specify each property separately, or use a semicolon or comma to separate multiple properties.
So your build command will be something like
dotnet build /p:Version=1.2.3.4;AssemblyVersion=1.2.3.4
I recently updated to Visual Studio 2015 and am using the new C# 6.0 features. In VS, everything builds correctly.
However, I use PSake as build script language, and the build always fails at places where I use c# 6.0 features. How can I tell psake to use MSBuild 14.0, so that the new c# 6.0 features build correctly?
Tried & failed:
Passing in the framework version to psake: Unknown .NET Framework version, 4.6
Call the vsvars32.bat of VS2015 prior to invoking psake. PSake still uses the old MSBuild version.
I had the same issue & fixed it by configuring PSake build script to use .Net Framework 4.6, simply by adding Framework "4.6" in the beginning of the file. You may check this unit test from PSake code base dotNet4.6_should_pass.ps1
The solution described by #WahidShalaly seems to be the correct one, so use that. However, on my machine it still didn't find the correct MSBuild version so here is the workaround that I have in place instead:
Add the following task to your PSake script:
Task SetEnvironment {
Exec { & $env:VS140COMNTOOLS\vsvars32.bat }
}
This sets the environment for VS2015 compilation from within PSake.
Now add a dependency to SetEnvironment from every task that calls MSBuild and use msBuild.exe instead of just msbuild. Example:
Task Compile -Depends SetEnvironment {
Exec { & "msbuild.exe" "theSolution.sln" /p:VisualStudioVersion=14.0 }
}
I've got a project that's using SpecFlow, NUnit and Coypu to do acceptance tests on a web application. I've got the project building OK via Jenkins on a build server. Jenkins calls a psake script which runs msbuild on the specs project, then the script calls nunit-console to run the specs/tests, and then I want to generate a report from SpecFlow.
Framework "4.0"
task Default -depends RunSpecs
task BuildSpecs {
$env:EnableNuGetPackageRestore = "true"
msbuild /t:Rebuild ReturnsPortal.Specs.csproj
}
task RunSpecs -depends BuildSpecs {
exec { & "C:\path\to\NUnit 2.5.9\bin\net-2.0\nunit-console-x86.exe" /labels /out=TestResult.txt /xml=TestResult.xml .\bin\Debug\TheWebApp.Specs.dll }
exec { & "C:\path\to\SpecFlow\1.8.1\specflow.exe" nunitexecutionreport TheWebApp.Specs.csproj /out:SpecResult.html }
}
That last exec call to specflow.exe fails though, with:
The element <ParameterGroup> beneath element <UsingTask> is unrecognized. C:\Program Files (x86)\Jenkins\jobs\TheWebApp\workspace\Web\Sites\TheWebApp.nuget\nuget.targets
A bit of googling hints that maybe it's a problem with the msbuild version being used (e.g. here, here). But I have Framework "4.0" in my psake script, and the Specs project is targeting .NET Framework 4.0, and it builds fine in the build step, so I'm not sure why specflow seems to be using an earlier version of msbuild. Or is maybe the problem somewhere else?
This was the answer for me, from the SpecFlow Wiki:
Important for .NET 4.0 projects: Because specflow.exe is compiled for .NET 3.5, it cannot load .NET 4.0 assemblies by default. To generate this report for .NET 4.0 projects, you have to force specflow.exe to use the .NET 4.0 runtime by using the config file. Just copy the config below and create a specflow.exe.config file and put it next to your specflow.exe and you will be able to create the step definition report.
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<startup>
<supportedRuntime version="v4.0.30319" />
</startup>
</configuration>
I attempted to use the config file solution suggested above. It worked for testing locally, but as soon as I pushed my code to our CI environment it choked on it since the CI environment doesn't have that config file. We restrict out CI environment to only use clean versions of the various packages, so we didn't want to try to inject the special config into the CI server.
We noticed that SpecFlow works just fine with several of our .NET 4.0 projects without the special config file. After a little research, the actual 'problem' appears to be NuGet 2.1. Everything works fine for .NET 4.0 projects with NuGet 1.7.
Somewhere between 1.7 and 2.1 NuGet introduced new features in the NuGet.targets file that aren't supported by the older versions of MSBuild. Specifically the problem seems to be the <ParameterGroup> beneath element <UsingTask>, as explained by the error message.
A cursory glance at the targets file indicates that the section is responsible for keeping NuGet up to date. Removing this section completely resolves the issue in the same manner that adding the config file above does, albeit also removing the self-update functionality that is seems to provide. Given that the .targets file is committed to the repository, this solution also works on our CI environment with out any changes on the CI side.
It's not necessarily a better solution than ngm's, it's just a different one. Depending on your environment, this may be a preferable way to go, or perhaps not.
In prior versions of MSBuild, you could set an environment variable named MSBUILDEMITSOLUTION to 1 to get an XML version of a solution (.sln) file that could be parsed. According to the MSBuild Team Blog, that's still in the version that ships with Visual Studio 2010, but it does not seem to be working.
Has anyone managed to get this working with MSBuild 4.0? If so, what is required?
(We use this to find and run convention-based unit tests with an NAnt script.)
Set MSBuildEmitSolution=1 and then build from the command line. You should then see a MySolution.sln.metaproj file near MySolution.sln.
Notes:
If you open a command prompt window, then set the env var via System Settings, you will have to open a new command prompt.
You'd think you could also use msbuild /p:MSBuildEmitSolution=1, but you can't.