by ·2 Comments

While working on packaging some internal .Net libraries for publishing to our internal NuGet server, I encountered the following cryptic error:

1
2
3
4
5
D:\Projects\Company\Web>nuget pack Web.csproj -Prop Configuration=Release
Attempting to build package from 'Web.csproj'.
Packing files from 'D:\Projects\Company\Web\bin\Release'.
Using 'Web.nuspec' for metadata.
An error occurred while parsing EntityName. Line 10, position 35.

An error occurred while parsing EntityName. Line 10, position 35.

“EntityName”? What?!? Where did that variable or name come from? Checking my NuGet spec file. Everything looks fine.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
<?xml version="1.0"?>
<package >
  <metadata>
    <id>$id$</id>
    <version>$version$</version>
    <title>$title$</title>
    <authors>George Heeres</authors>
    <owners>$author$</owners>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <description>$description$</description>
    <releaseNotes>Initial release.</releaseNotes>
    <copyright>Copyright 2014</copyright>
    <tags>company web mvc api webapi http json xml javascript</tags>
    <dependencies>
      <dependency id="Castle.Core" version="[3.0.0.4001,4.0)" />
      <dependency id="Castle.Windsor" version="[3.0.0.4001,4.0)" />
      <dependency id="Company.Core" version="(1,)" />
      <dependency id="Company.Logging" version="(1,)" />
      <dependency id="Company.Security" version="(1,)" />
    </dependencies>
  </metadata>
  <files>
    <file src="bin\Release-Net45\Company.Web.dll" target="lib\net45" />
    <file src="bin\Release-Net45\Company.Web.XML" target="lib\net45" />
  </files>
</package>

The NuGet spec allows for variables ($id$, etc.) to be replaced by values defined in our Assembly (typically AssemblyInfo.cs). In our AssemblyInfo.cs file we have the following:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
using System.Reflection;
using System.Resources;
using System.Runtime.InteropServices;
 
// General Information about an assembly is controlled through the following
// set of attributes. Change these attribute values to modify the information
// associated with an assembly.
[assembly: AssemblyTitle("Company.Web")]
[assembly: AssemblyDescription("Custom Web, Mvc & Http components, object and extensions.")]
#if DEBUG
[assembly: AssemblyConfiguration("Debug")]
#else
[assembly: AssemblyConfiguration("Release")]
#endif
[assembly: AssemblyCompany("Company")]
[assembly: AssemblyProduct("Company Web Framework")]
[assembly: AssemblyCopyright("Copyright © 2012,2013,2014; Company")]
[assembly: AssemblyTrademark("")]
[assembly: AssemblyCulture("")]
[assembly: NeutralResourcesLanguage("en-US")]
 
// Setting ComVisible to false makes the types in this assembly not visible
// to COM components.  If you need to access a type in this assembly from
// COM, set the ComVisible attribute to true on that type.
[assembly: ComVisible(false)]
 
// The following GUID is for the ID of the typelib if this project is exposed to COM
[assembly: Guid("1943f4e9-b0c0-4daf-bd62-27e2e33f9dc0")]
 
// Version information for an assembly consists of the following four values:
//
//      Major Version
//      Minor Version
//      Build Number
//      Revision
//
// You can specify all the values or you can default the Build and Revision Numbers
// by using the '*' as shown below:
// [assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyVersion("1.1.0")]

Note: The assembly file version (AssemblyFileVersion) is dynamically generated by the build script & tasks.

So can you spot the problem? I’ll give you a hint, it’s in the AssemblyDescription.

The problem is that “&” sign. Because our NuGet file is an XML file, the “&” value must be escaped. The solution is simple:

1
[assembly: AssemblyDescription("Custom Web, Mvc &amp; Http components, object and extensions.")]

Or optionally, we can leverage the English language and not be lazy…

1
[assembly: AssemblyDescription("Custom Web, Mvc and Http components, object and extensions.")]

The later solution may be preferrable because the Windows explorer file properties would display “&amp;” instead of “&”. Using “and” would be more agnostic.

Hopefully this post will save you some time!