Tag: Nuget

Jan10201510 January 201512 January 20155Commentsby Gregor Suttie

Issue I ran into when using Nuget/SlowCheetah

Posted in NuGet, SlowCheetah

nugetCannot add part to the package. Part names cannot be derived from another part name by appending segments to it

Last week I ran into an issue where I was using nuget to package a .csproj file.
What I was after was the contents of the nuget package to contain a Content folder and inside this Content folder have one file called app.config.transform, that’s it.

If my .csproj file contained the following:-

[sourcecode language=”xml”] <PropertyGroup Label="SlowCheetah">
<SlowCheetahTargets>..\.shared\SlowCheetah.Transforms.targets</SlowCheetahTargets>
</PropertyGroup>
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<Import Project="$(SlowCheetahTargets)" Condition="Exists(‘$(SlowCheetahTargets)’)" Label="SlowCheetah" />
[/sourcecode]

Then the package contents had a single file called content – which is incorrect.

The way I fixed this was inside the .csproj file I changed the type of the app.config.transform from Content to None. I then changed my .nuspec file to have the following:-

[sourcecode language=”xml”] <files>
<file src="App.config.transform" target="Content" />
</files>
[/sourcecode]

This fixed my issue with the contents of my nuget package, just incase anyone runs into the same issue.


Tags:

Aug14201214 August 201214 August 20120Commentby Gregor Suttie

Small Nuget gotya with our TeamCity builds

Posted in NuGet

At work we use TeamCity from Jetbrains on our build server, the product itself is the best there is out there.

Good products should be talked up more on twitter in my opinion, so that more people learn about what is good out there. If you’re considering software to use for building software then look no further than TeamCity.

We recently created quite a few nuget packages for internal use at work and we have them building as part of our builds on the buildserver using Teamcity. They used to be class libraries used as externals and these were causing us some pain so we decided to make them into Nuget packages and build them as part of our build process.

Our build process at work is pretty neat, I can push a website/windows service to dev, or staging environments with once click and it build the code, runs all the unit tests, check the level of code coverage is above a certain level and then removes the current installation and installs the new version – all in one click (for production we have 3 clicks due to having to log onto production servers and clicking on a batch file to do remove the old code and install the new version)

To set that up took time but worth doing as it means anyone can build and deploy to any environment with 3 clicks or less, thats quite powerful.

Now before going into the issue, let me say that people use TeamCity in different ways, the way people build Nuget packages will also no doubt differ.

Our Issue
As part of the code we were referencing internal and external Nuget packages, the NuSpec files had the following:-

[sourcecode language=”csharp”] <dependency id="ExamplePackage" version="1.3.2" />
[/sourcecode]

Wasnt till I suddenly realised that this means go get the latest version of the example package from Nuget if one is available, which wasnt really what we wanted in this scenario.

Versioning packages within Nuget is covered here Versioning Nuget packages and was just what I needed.

Once I updated the Nuspec files to have:-

[sourcecode language=”csharp”] <dependency id="ExamplePackage" version="[1.3.2]" />
[/sourcecode]

This square brackets around the version number means that instead of going off to Nuget to get the latest version, go off and get this version (if not installed already).

Now when i do a build it wont try and pull down the latest version of Nuget goodies such as AutoMapper and StructureMap.

Feel free to ask any questions or leave a comment on this post.


Tags: