When I run nuget pack MyProject.csproj from the command line, I get the following error:
The replacement token 'author' has no value.
I checked my AssemblyInfo, and the AssemblyCompany is specified as "AJ Richardson". I tried manually replacing $author$ with AJ Richardson in my nuspec file, but then I got a slightly different error:
The replacement token 'description' has no value.
But the AssemblyDescription is also specified. It seems that NuGet is not reading anything from my AssemblyInfo. I have verified that AssemblyInfo is included in my project and the build action is set to Compile.
I have made a couple of NuGet packages before and did not have any issues. The only difference between this package and my previous packages is that this one has dependencies.
For reference, here is my nuspec:
<?xml version="1.0"?>
<package>
<metadata>
<id>$id$</id>
<version>1.0.0</version>
<title>$title$</title>
<authors>$author$</authors>
<owners>$author$</owners>
<licenseUrl>https://github.com/my/repo/blob/master/LICENSE</licenseUrl>
<projectUrl>https://github.com/my/repo</projectUrl>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>$description$</description>
<releaseNotes>Initial release.</releaseNotes>
<copyright>Copyright AJ Richardson 2015</copyright>
<tags></tags>
</metadata>
<dependencies>
<dependency id="Newtonsoft.Json" version="6.0.1" />
</dependencies>
</package>
So my question is, why isn't NuGet reading my AssemblyInfo, and how do I convince it to do that?
I was also experiencing issues in this regard; my updates to AssemblyInfo didn't seem to be being picked up - despite me building and rebuilding, etc.
I was able to resolve the issue by explicitly telling NuGet to build (in my case in Release, with pdb symbols):
nuget pack foo.csproj -Build -Symbols -Properties Configuration=Release
I think the problem was that I hadn't built my project since modifying the AssemblyInfo. I did a rebuild and it's working now.
(As a side note, I also had the <dependencies> in the wrong section - it should be inside of <metadata> - but that was not causing the error in my question.)
Same problem here, but it turns out that someone introduced a signing key, and I was referencing assemblies that didn't have a strong name.
Weird that I didn't get a different error.
Related
I created a small executable that is used to run and debug specific libraries from other solutions. The executable is given the path to a library as a command line argument which the executable loads at runtime.
I want to put my executable in a Nuget package, and have consuming libraries just add the Nuget package to be able to run and debug, using a launchSettings.json.
Because the executable is in the tools/ directory of the Nuget package, its path is put into the PATH environment variable by the Package Manger Console. Therefore the launchSettings can simply just call the executable.
I create my Nuget package with nuget.exe pack my.nuspec -Version 1.0.0, with my.nuspec containing:
<?xml version="1.0"?>
<package xmlns="http://schemas.microsoft.com/packaging/2011/08/nuspec.xsd">
<metadata>
<id>DebugHost</id>
<version>$version$</version>
<title>DebugHost</title>
<authors>Some company</authors>
<owners>Some company</owners>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>DebugHost</description>
<summary>DebugHost</summary>
<copyright>2020, Some company</copyright>
</metadata>
<files>
<file src="bin\Debug\netcoreapp3.1\*" target="tools" />
</files>
</package>
From consuming library projects I put in Properties\launchSettings.json containting:
{
"profiles": {
"DebugHost": {
"commandName": "Executable",
"executablePath": "my.exe",
"commandLineArgs": "$(ProjectDir)$(OutDir)$(TargetName)$(TargetExt)"
}
}
}
I have three different questions that are somewhat related, as any might answer another:
This setup only works as long as I keep the Package Manager Console opened. If I try to Debug / Launch the library without first opening the Package Manager Console, the launch fails because it cannot find the executable. Unable to start program 'my.exe'. The system cannot fint the file specified.
Can I for example add a targets file in the Nuget package that will hint its path during build/launch, which in turn I can use as a variable in the launchSettings.json? (If so, how?)
This setup requires that a Properties\launchSettings.json is used in the consuming project. Can I make my Nuget package create that file?
Can the file be an asset in the Nuget that gets copied to the correct place?
Or can I even have an install.ps1 script that creates the json, with the correct absolute path to the executable in it? This would make question 1 answered as well.
The above situation only works with nuget.exe pack and a .nuspec.
Can I instead move stuff into my (new style) .csproj and get this to work with just dotnet.exe pack and the .csproj? (or msbuild.exe -t:pack and the .csproj?) So ultimately I can also just create the package by simply right clicking the project in Visual Studio and selecting Pack from the context menu?
When I run "Inspect > Code Issues in Solution", R# tells me "Cannot resolve assembly System.Drawing" and points to this line of xml in a *.resx file:
<assembly alias="System.Drawing" name="System.Drawing, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
I looked at my System.Drawing assembly in my project's list of References. It is version 3.5.0.0, not 2.0.0.0, so I changed the version number in the xaml in the .resx file from 2.0 to 3.5. That still elicited the same warning from R#, though.
So then I thought maybe it was the PublicKeyToken that was the culprit; so I changed that value from "b03f5f7f11d50a3a" to "969db8053d3322ac" (as found here); but then the project wouldn't even build; I got:
Invalid Resx file. The located assembly's manifest definition does not match the assembly reference.
Although these "issues" exist, the app seems to be working okay - the image that follows the assembly alias:
<data name="pictureBox1.Image" type="System.Drawing.Bitmap, System.Drawing" mimetype="application/x-microsoft.net.object.bytearray.base64">
<value>
blee blah bloo
</value>
</data>
...displays fine.
Still, when R# raises its finger, it makes me nervous; how can I rectify this flubup?
NOTE: This is a Visual Studio 2008 Windows CE/Compact Framework app.
I had a similar problem in the resx file in one of my C# projects:
Once I installed the relevant reference (System.Windows.Forms etc) - for that project - that particular resharper issue went away:
I have issues that I am dealing with where certain nuget installed package added via VS2012 have the copylocal value set to true where as others don't have any value set.
How does nuget know when to add copylocal and not to?
Is there some setting that I am missing in the nupkg file that I am missing?
I had a look at the source code for nuget (briefly) and it the copylocal value exists then it should be set to true.
e.g.
Install-Package System.Web.Mvc
resolves to
<Reference Include="System.Web.Mvc, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
<Private>True</Private>
<HintPath>..\packages\Microsoft.AspNet.Mvc.4.0.30506.0\lib\net40\System.Web.Mvc.dll</HintPath>
</Reference>
However
Install-Package Newtonsoft.Json
Resolves to
<Reference Include="Newtonsoft.Json">
<HintPath>..\packages\Newtonsoft.Json.5.0.6\lib\net45\Newtonsoft.Json.dll</HintPath>
</Reference>
I kind of figured this out.
The answer lies partly here:
http://msdn.microsoft.com/en-us/library/vslangproj.reference.copylocal
Although "Newtonsoft.Json" doesn't have the copylocal=true explicitly set in the csproj file, it seems the visual studio evaluates automatically when copylocal=true is set or not.
It seems nuget relies on the DTE integration to help it determine the value for copylocal.
I tested this out by running msbuild out of VS2012, removing System.Web.MVC from the GAC and it is copied to the bin dir.
I guess this only becomes an issue when one wants to open a compiled website the dll doesn't exist in the bin e.g. System.Web.MVC.
VS in this case does not know it should look in the GAC.
I have a library with a pretty verbose configuration section. I've created an XSD and would like to distribute that with my package so that when a user installs the package, Visual Studio knows about the XSD without the user needing to do anything extra. How do I do this?
You can include any files you want in a nuget package by placing them in the content directory. These will then be installed into the root of your target project when the package is installed. If you're using a nuspec file to build your package you would add the following element under the element.
<files>
<file src="Configuration\MyXsd.xsd" target="content\TargetFolderName" />
</files>
This will create the following file in the target project
\TargetFolderName\MyXsd.xsd
Once the xsd is in the target project visual studio should pick it up automatically for validating your config section.
This has recently become more complicated with SDK style projects and the different ways of referencing nuget packages.
Note the end of this section.
Basically, if a nuget project is referenced by package.config file, the files from the content folder of the nuget package will be copied to the referencing project. If the nuget package is referenced by PackageReference in the project file, the files from the contentFiles folder within the package will be used. It is recommended to include both.
Now if you are using a .nuspec file to configure your nuget package, you can use SynXsiS answer to include the file to both directories:
<files>
<file src="Configuration\MyXsd.xsd" target="content\TargetFolderName" />
<file src="Configuration\MyXsd.xsd" target="contentFiles\any\any\TargetFolderName" />
</files>
However, if you want to configure it in the .csproj file of SDK projects, you have to add the file you want to include in the nuget package into the project file with the following properties:
<ItemGroup>
<None Include="MyXsd.xsd">
<Pack>true</Pack>
<PackagePath>contentFiles\any\any\TargetFolderName;content\TargetFolderName</PackagePath>
</None>
</ItemGroup>
The any\any\ part of the path for the contentFiles specifies for which language (cs, vb, ...) and target framework the file is meant.
Note, that the item not necessarily has to be of type "None" it could also be "Content" and others as described here.
You can find all information for this structure here, general information of the folder structure can be found here and help for the SDK style projects here.
Is NuGet suitable for pulling down assemblies which are not required for compilation, but are at runtime? I have a Visual Studio solution which contains a number of NuGet packages required for compilation - these packages are not kept in source control. At runtime there are a couple of extra dll's which are required. Would it be bad practice to create a VS post-build step which calls NuGet.exe to download these packages and then copies the binaries to the required location? It doesn't look like the intended use of NuGet, but I don't see any obvious flaws with this approach.
I not sure if this would be a good way to do it, but it might solve your problem:
Create a NuGet-package with the DLL's in question as content. You should have the following in your nuspec-file:
<files>
<file src="path\to\dll\one.dll" target="content\dlls\one.dll" />
<file src="path\to\dll\two.dll" target="content\dlls\two.dll" />
</files>
When installing this NuGet package in your project, you'll get a folder dlls added to the project root. You can then go to the property tab of all the included files and set Always for Copy to Output Directory.