NuGet unable to extract metadata from assembly with XmlnsDefinitionAttribute

I am trying to add XmlnsDefinitionAttributes to my assembly. I use TeamCity to manage my projects. There is a NuGet Package Pack step in my build configuration.

Here is the relevant section of a failed build log.

[16:42:08]: Starting: C:\Windows\system32\cmd.exe /c C:\BuildAgent\tools\NuGet.CommandLine.1.5.20905.5.nupkg\tools\NuGet.exe pack C:\BuildAgent\work\5f0e65f22ca1527\MyProject\MyProject.csproj -OutputDirectory \\server\Packages -BasePath C:\BuildAgent\work\5f0e65f22ca1527 -Verbose -Version 1.0.97.1034 -Symbols -Properties Configuration=Release
[16:42:08]: in directory: C:\BuildAgent\work\5f0e65f22ca1527
[16:42:08]: Attempting to build package from 'MyProject.csproj'.
[16:42:09]: Packing files from 'C:\BuildAgent\work\5f0e65f22ca1527\MyProject\Bin\Release'.
[16:42:09]: WARNING: Unable to extract metadata from 'MyProject.dll'.
[16:42:09]: Using 'MyProject.nuspec' for metadata.
[16:42:09]: The replacement token 'title' has no value.
[16:42:09]: Process exited with code 1

The same section for a successful build looks like this.

[16:42:54]: Starting: C:\Windows\system32\cmd.exe /c C:\BuildAgent\tool\NuGet.CommandLine.1.5.20905.5.nupkg\tools\NuGet.exe pack C:\BuildAgent\work\5f0e65f22ca1527\MyProject\MyProject.csproj -OutputDirectory \\server\Packages -BasePath C:\BuildAgent\work\5f0e65f22ca1527 -Verbose -Version 1.0.98.1035 -Symbols -Properties Configuration=Release
[16:42:54]: in directory: C:\BuildAgent\work\5f0e65f22ca1527
[16:42:54]: Attempting to build package from 'MyProject.csproj'.
[16:42:54]: Packing files from 'C:\BuildAgent\work\5f0e65f22ca1527\MyProject\Bin\Release'.
[16:42:54]: Using 'MyProject.nuspec' for metadata.

At this point it outputs all of the settings.

My XmlnsDefinitionAttribute is defined in AssemblyInfo.cs as follows

[assembly: XmlnsDefinition("http://schemas.company.com/myproject", "MyProject")]

Any ideas as to what I am doing wrong?

Edit

Here is my full AssemblyInfo.cs

using System.Reflection;
using System.Runtime.InteropServices;
using System.Windows.Markup;

[assembly: AssemblyTitle("MyProject")]
[assembly: AssemblyDescription("MyProject Description")]
[assembly: AssemblyConfiguration("")]
[assembly: AssemblyCompany("Microsoft")]
[assembly: AssemblyProduct("MyProject")]
[assembly: AssemblyCopyright("Copyright © Microsoft 2011")]
[assembly: AssemblyTrademark("")]
[assembly: AssemblyCulture("")]

[assembly: ComVisible(false)]

[assembly: Guid("23774732-4f22-4366-a150-03745e93111b")]

[assembly: AssemblyVersion("1.5.2")]
[assembly: AssemblyFileVersion("1.5.2")]

[assembly: XmlnsDefinition("http://schemas.company.com/myproject", "MyProject")]
[assembly: XmlnsDefinition("http://schemas.company.com/myproject", "MyProject.Namespace1")]
[assembly: XmlnsDefinition("http://schemas.company.com/myproject/newschema", "MyProject.NewSchema")]
[assembly: XmlnsDefinition("http://schemas.company.com/myproject/newschema", "MyProject.NewSchema.Namespace1")]

Edit 2

I installed NuGet locally and I am getting the same error. TeamCity does not appear to have any effect.

Nuget will try to get metadata from the assembly, and by doing do, it will load all assembly attributes.

This issue occurs because XmlnsDefinition is defined in System.Windows assembly (System.Windows.dll), and that particular assembly is normally not outputed to the build folder, so NuGet can't find it and throws an exception (you can only spot the exception if you run NuGet from code!)

Best way I found to bypass this issue is to make sure the System.Windows.dll file is in the same folder as the main assembly when you run NuGet.exe

A solution is to compile with Platform set to AnyCPU.

I am facing this problem as well - building it in TFS Build-Agent.

I have 2 "solutions" to this problem, but both have their own "problems":

1.) Activate "Copy Local" for reference "System.Windows".

• the problem with this approach....System.Windows.dll might be included in XAP, which it normally isn't. This sounds dangerous....
  • (although - one could argue that "XmlnsDefinitionAttribute" will never be used in the "App" Assembly, but only in Library DLLs....so this "problem" is moot?

2.) Copy the Silverlight System.Windows.dll into the nuget.exe path - for TFS (2017) Build Agent, on 64bit systems (which - contrary to some earlier comments - does work):

copy "c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\Silverlight\v5.0\System.Windows.dll" "C:\agent\externals\nuget"

• the problem here could be:
  • Silverlight SDK Updates? (do the copy again?)
  • Non-Silverlight Builds? (would NuGet pick up the wrong System.Windows.dll?)

So - which solution would you guys choose?

Update: For now I will use solution #1, as it sounds less dangerous.