by ·0 Comments

With a continuous integration and release pipeline configured and working, I was going back through projects and creating the necessary build and release tasks. One build job however was failing with the following error:

2016-03-04T13:04:26.3021168Z Set workingFolder to default: D:\TFS\tasks\NuGetInstaller\0.1.16
2016-03-04T13:04:26.3391205Z Executing the powershell script: D:\TFS\tasks\NuGetInstaller\0.1.16\NuGetInstaller.ps1
2016-03-04T13:04:26.6061472Z D:\TFS\agent\worker\tools\NuGet.exe restore "d:\TFS\_work\1\s\src\MySolution.sln"  -NonInteractive
2016-03-04T13:04:26.9761842Z MSBuild auto-detection: using msbuild version '14.0' from 'C:\Program Files (x86)\MSBuild\14.0\bin'.
2016-03-04T13:04:27.0951961Z ##[error]There are duplicate packages: log4net.1.2.10
2016-03-04T13:04:27.1041970Z ##[error]Unexpected exit code 1 returned from tool NuGet.exe

The error causing the job to fail is:

There are duplicate packages

Checking The Build

So I checked out the project and compiled with Visual Studio, no problems. Then I tried using the nuget command from the command line.

D:\Projects\MySolution\src>nuget restore
ll packages listed in packages.config are already installed.

The packages folder already exists so we have to clear it first. Since I have Cygwin installed (and I prefer the Unix tools), I just deleted the folder from the command line:

rm -rf Packages

You can obviously do this from the Windows explorer shell or use the native DOS commands.

So running the command again, all of the packages restore without issue. Hmmm…

Replicating The Error

So next, I run the identical command that was logged in the log output for the build job:

D:\TFS\_work\1\s\src>D:\TFS\agent\worker\tools\NuGet.exe restore "d:\TFS\_work\1\s\src\MySolution.sln"  -NonInteractive
MSBuild auto-detection: using msbuild version '12.0' from 'C:\Program Files (x86)\MSBuild\12.0\bin'.
There are duplicate packages: log4net.1.2.10

And now we finally get the error to duplicate.

But why?

Let’s check the versions of our NuGet utility.

On the build server, we have:

D:\TFS\_work\1\s\src>D:\TFS\agent\worker\tools\NuGet.exe
nuget Version: 3.2.1.10581

On the workstation with Visual Studio (with NuGet specified in the path), we have:

D:\Projects\MySolution\src>nuget
NuGet Version: 2.8.50926.602

Different NuGet Versions

So the build server is using the 3.x branch of NuGet which doesn’t handle XML errors as gracefully (or is more strict) as the prior version. So now we know the cause of the problem, let see if we can find the duplicate.

And sure enough, inside of a subproject we have the following inside of the packages.config file:

  <package id="log4net" version="1.2.10" targetFramework="net45" />
  <package id="log4net" version="1.2.10" targetFramework="net45" />

Remove the dupliate line, recommit and push the code.

Problem SOLVED!

by ·2 Comments

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

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.

<?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:

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:

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

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

[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!