Paket Issues

Photo by Olav Ahrens Røtne on Unsplash

I’m using Paket in my C# libraries and applications. I like the format and find it much simpler than some alternatives.

As I’m a relative novice I’m coming across occasional issues. I decided to document them here in the hope that they will be useful to someone. This post will expand over time as I come across more issues

Package Microsoft.CSharp contains libraries, but not for the selected TargetFramework net461 in project …

This happened in a net framework 4.6.1 application that was also using a variety of net standard 2.0 libraries. Some of the libraries were external as in the case above so I couldn’t change them.

It turned out that the solution was to restrict the framework. In my paket.dependencies file I added the line

framework: netstandard20

and everything worked. This is an example of the simplicity of paket that I find so attractive.

error : Could not find nuspec files in “obj\Debug” (Version: “0.5”), therefore we cannot call “paket fix-nuspecs”
and have to error out!

This is one of those annoying errors that googling doesn’t really help as it seems pretty rare, it is of course down to user error. Here is an extract from the project file that was having this issue

...
<TargetFramework>netstandard2.0</TargetFramework>
<LangVersion>7.1</LangVersion>
<Version>0.5</Version>
<Company>My Company</Company>
<Authors>Me</Authors>

The solution is trivial but it’s one of those things that may not be immediately obvious. The third line should be

<Version>0.5.0</Version>

i.e. the version number must contain the patch number. When you realise this, everything goes green and work can commence

The second time this happened was due to something different, this time the thing that fixed it was again in the project file, in this case I had the following line

<GeneratePackageOnBuild>true</GeneratePackageOnBuild>

removing this line resolved the issue

Locking dependencies

By default paket will use the latest version of a dependency that it can find. This is one of the reasons I prefer it over nuget. Occasionally this behaviour is not what you want. Paket has a number of ways of dealing with this sort of issue. In this case I wanted a library to be fixed to a specific version for a dependency chain. The way to do this was to use the == operator e.g. MyNewLibrary I have the following

MyLibrary == 3

in paket.dependencies will lock MyLibrary at version 3, however that does not persist throughout the chain, ie anything that depends on MyNewLibrary will use the latest version of MyLibrary. To prevent this you need to add the line above to MyNewLibrary even if MyLibrary is not explicitly used in it.

Error MSB4064 The “BuildOutputFolders” parameter is not supported by the “PackTask” task. Verify the parameter exists on the task, and it is a settable public instance property.

It’s rather debatable whether this is a paket issue Fortunately there is currently a simple answer. If you double click on the error it takes you to the location of the error. Simple change BuildOutputFolders to BuildOutputFolder on that line and the issue is resolved, at least until the file is regenerated

The "PackTask" task returned false but did not log an error

This started happening with a .net 3.1 LTS. This is one of those issues that may or may not be due to an undocumented change in Nuget. There are a few suggestions on how to resolve this but the simplest is to reduce the SDK version in global.json until it works. For me what worked was using

{
"sdk": {
  "version": "3.1.301",
  "rollForward": "latestPatch",
  "allowPrerelease": false
  }
}

Nuget package extraction issues on TeamCity

I had a very simple library that was failing to build on TeamCity. To add insult to injury it succeeded every time when I remoted onto the box and ran it manually. The errors appeared to suggest the file was corrupted or that it couldn’t be extracted.

Nuget package couldn’t be extracted to “…\packages\System.Threading.Overlapped”. System.IO.InvalidDataException: End of Central Directory record could not be found.. Trying to extract files individually.
Something went wrong while downloading System.Threading.Overlapped 4.3
Message: Error during extraction of C:\TeamCity\buildAgent\work\1db24e5278c21e6e\packages\System.Threading.Overlapped\system.threading.overlapped.4.3.0.nupkg.

For some reason it always seemed to be a small number of microsoft packages that were affected in particular from the system namespace. I tried uploading the particular package to my local nuget sources but that made no difference. Adding the paket verbose flag

paket restore --verbose

gave some clues. Specifically in the case of the above —

System.Threading.Overlapped 4.3 already downloaded.  
Package ...\packages\System.Threading.Overlapped\system.threading.overlapped.4.3.0.nupkg couldn't be extracted to "...\packages\System.Threading.Overlapped". System.IO.InvalidDataException: End of Central Directory record could not be found.. Trying to extract files individually.  Package ...\packages\System.Threading.Overlapped\system.threading.overlapped.4.3.0.nupkg couldn't be extracted to "...\packages\System.Threading.Overlapped". System.IO.InvalidDataException: End of Central Directory record could not be found.. Trying to extract files individually.
Something went wrong while downloading System.Threading.Overlapped 4.3  Something went wrong while downloading System.Threading.Overlapped 4.3
Message: Error during extraction of ...\packages\System.Threading.Overlapped\system.threading.overlapped.4.3.0.nupkg.  Message: Error during extraction of ...\packages\System.Threading.Overlapped\system.threading.overlapped.4.3.0.nupkg.

The clue here is the first line. This means that the package has been cached. In order to resolve this issue the answer was to clear the paket cache

paket clear-cache

After doing that it all ran as normal.

Paket refuses to install a library

This is a very strange one. My setup is that when I create a library I store it on an internal nuget server that is based on BaGet. This has worked pretty smoothly for some time. I have a few minor issues with BaGet but on the whole I like it and it fits nicely into my workflow.

When I recently updated one of my libraries I pushed it to BaGet as usual. This particular library was an RC, so for example the Version element in the csproj file looked something like

<Version>0.5.1-RC2</Version>

I always use capitals for RC which I believe is quite common. When I build the package this is maintained in the package name: however when the package is pushed to BaGet the RC turns to lower case. I believe this may be part of the explanation, though perhaps not all of it. When I tried to do a paket update on the application that used this library as a top level reference, it didn’t update. Eventually after some trial and error I came across a solution that appeared to work. Simply re-adding the library e.g.

> paket add My.Library --version 0.5.1-rc2

This installed the library as normal and everything appeared to be fine afterwards.