Fixed - see Sara Lui's link to document in comments.
I have created several NuGet packages which are available on our private Corporate NuGet gallery.
Several of these packages are dependent upon one common package.
However, when I add this to my Nuspec file:
<?xml version="1.0"?>
<package >
<metadata>
...
<dependencies>
<dependency id="MyCommonPackage" version="1.0">
</dependency>
</dependencies>
</metadata>
</package>
Then it fails to install because it can't find "MyCommonPackage" - it's not looking for it in our corporate gallery:
NotFound
https://api.nuget.org/v3-flatcontainer/MyCommonPackage/index.json
NotFound
https://dotnetmyget.blob.core.windows.net/artifacts/roslyn/nuget/v3/flatcontainer/MyCommonPackage/index.json
Visual Studio has this gallery referenced, but I suspect I need to reference it in the nuspec file (just not seeing how to do this).
I fixed it by referring to link provided by #Sara Lui:
please check this doc: https://learn.microsoft.com/en-us/nuget/create-packages/creating-a-package and make sure the required file 'MyCommonPackage' is under the folder structure before we run the nuget pack command to generate the .nupkg file.
I removed the package references, deleted the folders from the NuGet gallery and then re-published them from the bottom-up. This time it just worked like a dream (with no changes apart from re-publishing).
Related
I generate a nuget package using my nuspec file below:
<?xml version="1.0" encoding="utf-8"?>
<package >
<metadata>
<id>CommonLib</id>
<version>1.2.3</version>
<authors>ABC</authors>
<owners>ULC</owners>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<license type="file">Licenses\License.txt</license>
<icon>Icons\Icon.PNG</icon>
<description>Common References</description>
<copyright>Copyright (c) 2020</copyright>
<tags>Common</tags>
<dependencies>
<group targetFramework="net48" />
</dependencies>
</metadata>
<files>
<file src="lib\net48\Common*.dll" target="lib/net48" />
<file src="Licenses\License.txt" target="Licenses\" />
<file src="Icons\Icon.PNG" target="Icons\" />
</files>
</package>
The folder structure for the source data for packing is as the following:
RootDir
Icons
Icon.png
lib
net48
Abc.dll
Common1.dll
Common2.dll
xyz.dll
Licenses
License.txt
My.nuspec
I successfully generate it. However, whether I host it locally or in my Azure Artifacts as private feed, then when I browse in VS2017 (that's what I currently have installed) to install for a project then the generated package doesn't show its embedded icon, instead, it shows the default nuget pack icon. I tried browsing either from my local feed or from Azure private feed, same thing. What's the reason my embedded into nuget pack icon is not being used?
Embedded into NuGet package icon doesn't appear in VS
Actually, this is a well-known issue for nuget and for creating our own nuget feed, package source, or local address, the nuget icon cannot be displayed in the package manage UI. See this similar issue.
So if you add comments in this github link to get the staff's attention so that they can focus on the issue and fix it.
In your situation, you use private local nuget feed to install such nuget package and it cannot be realized and the latest version nuget.exe v5.5.1 does not support this so far.
Solution
Please upload your nuget package into nuget.org website an then use nuget.org nuget feed to install your nuget package.
And nuget.org supports the sustom icon to show your nuget package.
And then you can directly use nuget.org to install your own nuget package.
l have test it:
local feed:
nuget.org website:
Besides, you could suggest this feature in Our User Voice Forum to reflect your thoughts
Suppose we have a Visual Studio template that we would like to distribute within our organization. This template is hosted on an SVN server. I would like users to be able to point Nuget to the SVN location and get the template installed in the proper location just like any other package. Is this possible?
Is this possible?
We can do it but individuals do NOT recommend it.
How
According to the NuGet document:
Put simply, a NuGet package is a single ZIP file with the .nupkg
extension that contains compiled code (DLLs), other files related to
that code, and a descriptive manifest that includes information like
the package's version number. Developers with code to share create
packages and publish them to a public or private host. Package
consumers obtain those packages from suitable hosts, add them to their
projects, and then call a package's functionality in their project
code. NuGet itself then handles all of the intermediate details.
However, the Visual Studio Template is a file with the .zip extension, which could not be recognized by NuGet. Even if we point NuGet to the SVN location, NuGet still can not recognize it.
To resolve this issue, we have to create a NuGet package to include this Visual Studio Template .zip file, like:
<files>
<file src="TestDemo.zip" target="Tools\TestDemo.zip" />
</files>
Besides, there is another question, when we install this nuget package to the project, this Visual Studio Template .zip file would be downloaded to the \packages folder in the solution folder. We have to move it to the Visual Studio Templates folder.
So, we have to add .targets with copy task in that nuget package to copy zip file to the Visual Studio Templates folder.
The content of .targets file:
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="CopyTemplate" BeforeTargets="Build">
<Message Text="Copy Template to template folder."></Message>
<Copy
SourceFiles="$(SolutionDir)packages\MyTemplatePackage.1.0.0\Tools\TestDemo.zip"
DestinationFolder="$(USERPROFILE)\Documents\Visual Studio 2017\Templates\ProjectTemplates"
/>
</Target>
</Project>
Finally, the .nuspec file like following:
<?xml version="1.0"?>
<package >
<metadata>
<id>MyTemplatePackage</id>
<version>1.0.0</version>
<authors>Tester</authors>
<owners>Tester</owners>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>Package description</description>
<releaseNotes>Summary of changes made in this release of the package.</releaseNotes>
<copyright>Copyright 2018</copyright>
<tags>Tag1 Tag2</tags>
</metadata>
<files>
<file src="TestDemo.zip" target="Tools\TestDemo.zip" />
<file src="MyTemplatePackage.targets" target="Build\MyTemplatePackage.targets" />
</files>
</package>
Then pack this .nuspec file, add this nuget package to the SVN location, add the SVN location to the nuget package source, you can install this nuget package to the project, and build the project, Visual Studio will download that nuget package and copy .zip file to the Visual Studio Templates folder.
I have created a sample test nuget package and it work fine on my side with Visual Studio 2017, you can test it on VS2017: https://1drv.ms/u/s!Ai1sp_yvodHf2Vax7TzuC6HQUD5w
Why not recommend
Just as you can see above, it is not easy and simple to do this, we have to do a lot of things to create that nuget package. What`s more, in order to get the template we have to create a project and install that package and build the project. It pulls in too many extra operations. Besides, when you change anything in the template, you have to re-create this package and install it.
Since this template is hosted on an SVN server, you can just check it to the Visual Studio template folder, this will be more effective.
Hope this complicated answer helps.
The nuspec reference says about the releaseNotes tag
v1.5 A description of the changes made in each release of the package. This field only shows up when the Updates tab is selected and the package is an update to a previously installed package. It is displayed where the Description would normally be displayed.
I created two nuspec files, both containing (with different version tags of course)
<?xml version="1.0"?>
<package >
<metadata>
<id>TestReleaseNotes</id>
<version>1.0</version>
<authors>adrianm</authors>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>Description</description>
<releaseNotes>Release notes</releaseNotes>
</metadata>
<files>
<file src="Test.cs" target="content" />
</files>
</package>
I installed 1.0 in VS2013 and selected the update tab but I can't see the release notes.
What am I missing?
Found this out myself.
The release notes are displayed if I open the "Manage NuGet packages" dialog from the project.
but not when I open it from the solution.
The behaviour is the same for my own packages as well as nuget.org
This still seems to be an issue in Visual Studio 2019 as at March 2021.
We publish a number of nuget packages internally using Azure. The Package Release Notes show up in the Azure UI but not in Visual Studio. However, the "Description" does show up in Visual Studio, so I've tweaked the Description to include the release notes. This is actually from the Directory.build.props file, but could equally well be embedded in the project file:
<PackageReleaseNotes>
Release notes added to .nuspec file as <Release Notes> and also to end of Description
</PackageReleaseNotes>
<!-- Don't indent text, it makes it hard to read in the nuget package manager-->
<Description>
Description:
This is the description of our internally produced nuget package
Release Notes:$(PackageReleaseNotes)
</Description>
This issue is tracked in the NuGet repo regarding VS2015.
https://github.com/NuGet/Home/issues/1823
I want to add a new <Import> to a project when I detect that a particular type of file has been added to the project. (the <Import> adds a task to the build process that takes the file and performs work during a build).
(Detection of a file having been added to the project is done using IVsSolutionEvents.HandleItemAdded).
I currently have code that uses Microsoft.Build.Evaluation.Project to add an Import element to the project. However this is an edit to a project file on disk. If I use this code to add an Import after detecting the addition of a new item to the project I create a conflict between a change on disk (the new Import) and an in-memory change (the addition of the new file). The user is then presented with a dialog where they must choose which change to throw away.
My question is this:
Is there a way to add a new <Import> to a project via the visual studio extensibility API in such a way that the modification to the project would be "in-memory", avoiding a conflict between the addition of the new project item, and the addition of the Import?
For existing project types, I've found the easiest way is leveraging NuGet. You can define a NuGet package which contains the .targets file in a special build/ folder, and NuGet will automatically add the <Import> when it is added to a project within Visual Studio. It will also update the references if you upgrade the package in the future. A full example is the packaging of the Antlr4BuildTasks package, which currently uses the following .nuspec file to create the package. The key here is the section following the <!-- Build Configuration --> comment.
<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
<metadata minClientVersion="2.7">
<id>Antlr4</id>
<version>0.0.0</version>
<authors>Sam Harwell, Terence Parr</authors>
<owners>Sam Harwell</owners>
<description>The C# target of the ANTLR 4 parser generator for Visual Studio 2010+ projects. This package supports projects targeting .NET 2.0 or newer, and built using Visual Studio 2010 or newer.</description>
<language>en-us</language>
<projectUrl>https://github.com/sharwell/antlr4cs</projectUrl>
<licenseUrl>https://raw.github.com/sharwell/antlr4cs/master/LICENSE.txt</licenseUrl>
<iconUrl>https://raw.github.com/antlr/website-antlr4/master/images/icons/antlr.png</iconUrl>
<copyright>Copyright © Sam Harwell 2014</copyright>
<releaseNotes>https://github.com/sharwell/antlr4cs/releases/v$version$</releaseNotes>
<requireLicenseAcceptance>true</requireLicenseAcceptance>
<developmentDependency>true</developmentDependency>
<tags>antlr antlr4 parsing</tags>
<title>ANTLR 4</title>
<summary>The C# target of the ANTLR 4 parser generator for Visual Studio 2010+ projects.</summary>
<dependencies>
<dependency id="Antlr4.Runtime" version="$version$" />
</dependencies>
</metadata>
<files>
<!-- Tools -->
<file src="..\tool\target\antlr4-csharp-$CSharpToolVersion$-complete.jar" target="tools"/>
<!-- Build Configuration -->
<file src="..\runtime\CSharp\Antlr4BuildTasks\bin\net40\$Configuration$\Antlr4.net40.props" target="build\Antlr4.props"/>
<file src="..\runtime\CSharp\Antlr4BuildTasks\bin\net40\$Configuration$\Antlr4.net40.targets" target="build\Antlr4.targets"/>
<file src="..\runtime\CSharp\Antlr4BuildTasks\bin\net40\$Configuration$\Antlr4BuildTasks.net40.dll" target="build"/>
</files>
</package>
This link How do I create an XML Intellisense file for my DLL? explains how to build your dlls so that an XML file is included containing all your documentation headers so that they are available in those IntelliSense popups.
In my company we frequently distribute our own dlls using an internal NuGet package source. When I create NuGet packages for the package source, how do I ensure that someone else gets the dll from the package source, IntelliSense displays the documentation headers for them?
If you distribute your XML files with your NuGet package in the same folder as your Dlls then Visual Studio will then find these XML files and show IntelliSense for your assemblies.
To distribute the IntelliSense XML files you will need to add them to your .nuspec file, for example:
<files>
<file src="bin\IronPython.dll" target="lib\Net40" />
<file src="bin\IronPython.xml" target="lib\Net40" />
</files>
tl;dr documentation files need to be .xml not .XML
I was able to get the XML files included by first enabling the production using the Build tab, checking XML Documentation File in the Output section. Note: for some reason I had to manually change the extension from .XML to lowercase .xml. YMMV. This is the same as the question you referenced, How do I create an XML Intellisense file for my DLL?.
Once done, I created the Nuspec file in the project directory. Here's a sample, you can also generate it with nuget spec MyAssembly.dll - but make sure to edit it and set the values appropriately.
<?xml version="1.0"?>
<package >
<metadata>
<id>$id$</id>
<version>1.0.0</version>
<title>Title for your package</title>
<authors>Package Author</authors>
<owners>Package Owner</owners>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>A description of your library</description>
<releaseNotes>Release notes for this version.</releaseNotes>
<copyright>Copyright 2013</copyright>
<tags>tag1 tag2</tags>
</metadata>
</package>
Once that was done, I used Nuget to package. Note I had to specify the platform because I'm using a 64-bit OS, but I don't have any targets in the project for x64, only AnyCPU
nuget pack MyAssembly.csproj -Prop Configuration=Release;Platform=AnyCPU -build
The assembly and it's associated documentation were automatically included in the package. In addition any packages that you've used in your project are added to the dependency list.
See http://docs.nuget.org/docs/creating-packages/creating-and-publishing-a-package for more information.