3

I have a .Net Standard 1.5 library and try to get an automated .NET Core build within Visual Studio Team Services, but somehow the NuGet Packager Task generates an error: 

MSBuild auto-detection: using msbuild version '4.0' from 'C:\Windows\Microsoft.NET\Framework\v4.0.30319'.
Attempting to build package from 'My.Shared.csproj'.
##[error]The default XML namespace of the project must be the MSBuild XML namespace. If the project is authored in the MSBuild 2003 format, please add xmlns="http://schemas.microsoft.com/developer/msbuild/2003" to the <Project> element. If the project has been authored in the old 1.0 or 1.2 format, please convert it to MSBuild 2003 format.  C:\a\1\s\src\My.Shared\My.Shared.csproj

The package should use automated semantic versions, which why I used the GitVersion extension. The GitVersion extension doesn't support .NET Core, which is why I need to create a separate NuGet Packager Task. The thing that wonders me is that the auto-detection is using MSBuild 4.0, because i'm building this using .NET Core (screenshot).

Things I've tried so far:

  • force other MSBuild using -MSBuildVersion 15, but that gives an error Cannot find the specified version of msbuild: '15' (or 14 for that matter)
  • create a .nuspec file with a NuGet Command Task and use the generated .nuspec instead of the .csproj. Unfortunately I don't know how to find the generated assembly-filename to pass it on to the AssemblyPath-argument (screenshot).

Any tips, tricks or ideas what's going on here and how to fix it? E.g. could it be fixed by instructing NuGet Packager Task to use MSBuild 15 and if so: how would I do that?

Martin
  • 1,149
  • 7
  • 13
  • Link to gitversion documentation stating it's not supporting .NET Core: http://gitversion.readthedocs.io/en/latest/usage/msbuild-task/ – Martin May 02 '17 at 13:01
  • MSBuild version would be 15.1 not 15 – Hexo May 09 '17 at 07:15
  • According to the docs it should be 15: https://learn.microsoft.com/en-us/nuget/tools/nuget-exe-cli-reference#restore – Martin May 11 '17 at 10:04
  • Possibly a documentation error. 15.1 works fine. However, here's the bug - read the first comment also: https://github.com/NuGet/Home/issues/5170 – Hexo May 11 '17 at 14:18

2 Answers2

2

Turns out it was the wrong Task for the job: I should've used a .NET Core Task with the pack command.

screenshot

Martin
  • 1,149
  • 7
  • 13
0

Based on your first screenshot, It seems you only want to package *.csproj file(s), so if you use NuGet Command task (nuget spec) without additional arguments (-AssemblyPath).

The method to create a .nuspec file and then use it in NuGet Packager task can work fine.

After the NuGet Command task, it will create a Package.nuspec file in $(Build.SourcesDirectory). So you can specify Path to cspro or nuspec file to pack as $(Build.SourcesDirectory)\*.nuspec.

enter image description here

Marina Liu
  • 36,876
  • 5
  • 61
  • 74
  • The NuGet Command Task created an *empty* Package.nuspec file. The NuGet spec Task doesn't know where the dll is, hence my question on how to pass the assemblyfilename to the NuGet spec command. Any ideas? – Martin May 04 '17 at 07:54
  • So where is the `.dll` located, is it a reference for your `.csproj` file? – Marina Liu May 04 '17 at 08:08
  • I used a .dll which was created by build, in Nuget Command task, it just need to specify the detail directory as `-AssemblyPath $(Build.SourcesDirectory)\projectname\ClassLibraryStandard\bin\$(BuildConfiguration)\netstandard1.4\ClassLibraryStandard.dll`. – Marina Liu May 04 '17 at 09:26
  • It feels a little dirty to hardcode projectnames and folders into the NuGet Command Task. I was hoping to use wildcards for the -AssemblyPath argument, but unfortunately it doesn't support that. Looks like I'll have to find an alternative. Do you have an an idea why the NuGet Packager Task uses MSBuild 4.0 instead of 15? – Martin May 04 '17 at 09:48