I have a fairly complex and large project that I want to attempt to package as a nuget package for internal use. I want to avoid copying files, because there are quite a few (150 MB+ of binaries). Instead, I am trying to point a package blueprint file to the files using the <file ...>
element. Here's a simplified version of the file that I can reproduce my problem with:
<?xml version="1.0"?>
<package >
<metadata>
<id>AgentCore</id>
<version>6.1.0</version>
<authors>kkm</authors>
<description>AgentCore</description>
<references>
<reference file="Utils.dll" />
</references>
</metadata>
<files>
<file src="Kigo\bin\Release\Utils.dll" target="/lib/net40"/>
</files>
</package>
Whatever I try, I am getting the error:
Invalid assembly reference 'utils.dll'. Ensure that a file named 'utils.dll' exists in the lib directory.
I tried suggestions from this answer, but to no avail.
Is it possible to avoid laying out the directory physically, as explained in the NuGet documentation, and use file references instead?
The problem was in the target=
directory of the <file ...>
element. It must not contain the leading /
, i. e. should contain a relative path. The leading slash does not change package layout, but apparently confuses a reference evaluation device in NuGet. A correct line in the above specification should be
<file src="Kigo\bin\Release\Utils.dll" target="lib/net40"/>
Wildcards also work (and that was my original intention):
<file src="Kigo\bin\Release\*.*" target="lib/net40"/>
With the wildcard spec, a <reference=...>
correctly accepts any binary packaged by way of wildcard expansion.