We are hosting our own nuget server through Teamcity. Is there any other way to add an icon to a .nuspec file other than specifying a web url (http://....)?
Or is there a place in Teamcity that these icons could be hosted?
As of NuGet 5.3.0 you can now use <icon> to provide a relative path to your JPEG or PNG icon file located within your package.
<package>
<metadata>
...
<icon>images\icon.png</icon>
...
</metadata>
<files>
...
<file src="..\icon.png" target="images\" />
...
</files>
</package>
Source: https://learn.microsoft.com/en-us/nuget/reference/nuspec#icon
<iconUrl> is now deprecated.
If you have your icon in a GitHub repository, you can locate it on GitHub.com, right click and "Copy image address". Then place this in your .nuspec. This worked for me:
<iconUrl>https://github.com/tcs1896/SharpChecker/blob/master/SharpChecker/SharpChecker/SharpChecker/Icon.png?raw=true</iconUrl>
No, this is the only option using the iconUrl property - See the NuSpec Reference
I would generally choose to host shared images like this on a CDN service rather than TeamCity - CloudFlare provide a free service.
The Documentation is as following
PackageIconUrl is deprecated in favor of the PackageIcon property Starting with NuGet 5.3 and Visual Studio 2019 version 16.3
So the way to do it is to add the following to your .csproj
<PropertyGroup>
<PackageIcon>icon.png</PackageIcon>
</PropertyGroup>
<ItemGroup>
<None Include="YOUR_PATH_TO_ICON\icon.png" Pack="true" PackagePath="\" />
</ItemGroup>
You can host icons on your TeamCity server, quoting Orn Kristjansson in TeamCity to serve static HTML page:
It's a Tomcat server, just go on your file system where you installed Teamcity and you should be able to find out where you can park some html that will then be available on the Teamcity urls.
So copy your icons into C:\...\TeamCity\webapps\ROOT\ and the will be served as static files.
I have a work around solution. I tried successfully on windows 10. It is useful if you have to install your application on the offline PC, without internet.
step 1:
add tag to the content of nuspec file. Something like the following:
<metadata>
<id>....</id>
...
<iconUrl>file://C:\app.ico</iconUrl>
...
<copyright>....</copyright>
</metadata>
step 2: generate the nupkg file from the above nuspec
step 3: generate the exe file from nupkg file
step 4:
put the app.ico file at location: C:\app.ico . You can choose any location according to <iconUrl> in the nuspec file. Almost windows PC have "C" drive disk. So that it is comfortable to install .exe in the other PC if you use "C" drive).
step 5: run exe file to install application on PC.
========= RESULT =============
At C:\Users\"user_name"\AppData\Local\"app_name" you can see the app.ico appears on the installed application folder.
I hope it may help you!
You can add file to nuspec content folder and specify link in such manner:
"file://content/images/icon.ico"
You can find more info here: Packages containing Icon and License
Related
I have a set of Nuget Libraries that I compile and modify myself.
I build them without publishing on any Nuget server. (It is not my library)
On the other side, I have a project that use such Nugets, but I wish to debug them...
In the best situation I wish to:
use my local .dll and .pdb
debug by using local .pdb and (updated) source code
I'm looking for the best possible solution, if possible by loading all local symbols,
but I'm not sure it is possible.
Maybe I have to build on my own local Nuget server and use a local Symbol server too, but it looks overkill?
Maybe I have to build on my own local Nuget server and use a local
Symbol server too, but it looks overkill?
As far as l know, when you want to debug a nuget library in a new project, you must add the required nuget.pdb and related xxx.cs source files in the new project.
According to your description, the nuget package is created by yourself which is more easiler to realize it:
1) If you have the nuget.pdb file and the corresponding cs file on the local, you just need to put the PDB file in the output file of the project which references the nuget, and then right-click on the Solution-->Properties-->Common Properties-->Debug Source Files-->to add the folder path which the cs files exist into it.
2) If you do not have the current nuget.pdb file and related cs source files for debugging on the local, you need to include these files in nuget.nupkg when creating the nuget package by using nuget.exe cli with xxx.nuspec, so that these files can be added to the current agent when you install the nuget package.
**Note:**This is the special steps for creating your nuget package:
A) please make sure that you have downloaded the nuget.exe and then set its path to environment variables so that it can be called in CMD. You can refer to this.
B) Open CMD, type cd xxxxxx(the path of the project which contains xxxx.csproj)
C) type nuget spec to generate the xxx.spec file
Then open it and add like these:
<?xml version="1.0" encoding="utf-8"?>
<package >
<metadata>
........
</metadata>
<files>
<file src="bin\Debug\ClassLibrary11.pdb" target="lib\target framework version (like net472 or netstandard2.0)" />------ClassLibrary11.pdb is the nuget.pdb
<file src="Class1.cs" target="src" />------Class1.cs is the source file
</files>
</package>
D) then type nuget pack to generate the nuget package which contains these debug files.
E) when you install this nuget package in a new project, please do not forget to clean the nuget cache first. After that, you should add the path of the resource files into Debug Source Files.(the resource files exists in the C:\Users\xxx\.nuget\packages\package name\src or C:\xxxxx\ConsoleApp(project folder)\packages\package name\src)
Edit
F) When you start debugging it, please do not forget to disable Just My Code In Tools-->Options-->Debugging-->General-->uncheck Enable Just My Code.
Also, you can consider source links as source control so that you won't configure the source path by Solution=>properties.
In addition, you can refer to this similar issue.
I Create a NuGet package and install into another project. but don't copy a file into the location project. only my file reference to NuGet package and I change the code, The package also changes! I want to copy the package to the target project.
<?xml version="1.0"?>
<package>
<metadata minClientVersion="3.3.0">
<id>MyPackage</id>
<version>1.0.0</version>
<authors>Meysam</authors>
<owners>Meysam</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>
<contentFiles>
<files include="cs/*.*/**" buildAction="Compile" />
</contentFiles>
</metadata>
<files>
<file src="ConsoleApp1\CustomClass\CustomClass.cs" target="contentFiles\cs\any\CustomClass" />
</files>
</package>
Copying files into the project that uses a nuget package is only supported when using packages.config, which isn't supported by SDK-style projects, which are required for .NET Core projects. As your screenshots show, contentFiles in PackageReferences projects are included at build time. The little arrow icon in the bottom right corner of the C# and folder icons you pointed to in your screenshot are visual indicators that the file and folder are different to the other files and folders in your project. In fact, that little icon overlay is similar to what Windows adds for shortcuts, so if you understand a shortcut is a file that "points to" another file, it should make sense that these are shortcuts to files outside your project, but are included as part of your project.
Anyway, it's working as designed.
You'll need to find another way to do whatever you want, but you didn't describe why you're trying to include a file in the project that references your package, so I can't give direct advice. My best advice, if you are experienced with ASP.NET and ASP.NET Core is think about how ASP.NET used to read a lot of settings directly from web.config, but ASP.NET Core instead uses a builder pattern, so that users are not forced to store settings in web.config and can store settings anywhere they want. If what you're doing is similar, your package users will have a better experience if you provide them with a configuration builder that they can override, rather than having a file in their project that they must edit and gets overwritten every time they upgrade to a new version of your package.
Cannot copy folder with nuget package in .net core
Yes, just like zivkan said:
Copying files into the project that uses a nuget package is only
supported when using packages.config
But, we could use a workaround to resolve this issue. We could add a copy task in the xx.targets file, and set this file in the \build folder in the .nuspec file.
The content of mypackage.targets file:
<Target Name="CopyFile" AfterTargets="AfterBuild">
<ItemGroup>
<CopyFiles Include="$(NuGetPackageRoot)\mypackage\4.0.0\cs\*.*\**" />
</ItemGroup>
<Copy
SourceFiles="#(CopyFiles)"
DestinationFolder="$(ProjectDir)"
/>
</Target>
And the .nuspec file:
<file src="xxx\xxx\mypackage.targets" target="build" />
Hope this helps.
I have a solution in Visual Studio 2015 with about 40 projects in it. Some of these projects have some NuGet packages referenced.
Due to a combination of our branching strategy (where each project folder is branched individually) and our security requirements (that the NuGet binaries are actually checked into TFS) I would like the NuGet packages for each Project to be installed into each Project's folder, not in the solution's folder. Space usage is not a concern here.
I've looked at:
https://docs.nuget.org/consume/nuget-config-file
https://docs.nuget.org/Release-Notes/NuGet-2.1#Specify-packages-Folder-Location
And they've helped my understanding of how the config files work... but I can't seem to get it to do what I want.
I've tried this in my config file:
<configuration>
<config>
<add key="repositoryPath" value="$(ProjectDir)\Nuget\" />
</config>
</configuration>
But it creates a folder in the solution folder actually called '$(ProjectDir)'.
And I can't hardcode the path to the project folders (i.e. 'C:\myteam\teampackages' in the NuGet docs) as pretty much everyone in the team have different paths to their local workspaces!
How can I do this?
Firstly, you should not check in NuGet packages into TFS Version Control. As one of the advantages of using NuGet is that you can use it to avoid checking in binaries to your version control system.
Instead, you need to restore NuGet packages during TFS build process and the required packages will be downloaded. In VS2015, you need to follow steps in this blog: https://docs.nuget.org/consume/package-restore/team-build).
Some key steps are (assume you're working with XAML build):
Add following items to the solution. (Content of the nuget.config and .tfignore file can be found here)
Add one build.proj file under the root path of the solution folder. (Content of the build.proj file can be found here)
Create one folder named tools under the root path of the solution folder. Create NuGet sub-folder under tools folder, download and save nuget.exe under tools\NuGet path.
Check in nuget.config, .tfignore, build.proj and tools\NuGet\nuget.exe into TFS version control.
Modify the build definition to choose to build the build.proj file.
Then you will have NuGet packages restored successfully during the TFS build process.
The Nuget docs mentions specifying package folder location is to have many different solutions share the same package. This is an opposite scenario as your. Repository path setting only allows you to install the NuGet packages in the specified folder (like C:\teampackages ) or for relative path (like ../Nuget).
To make installing package in different repositoryPath, you can try:
<configuration>
<config>
<add key="repositoryPath" value="../Nuget" />
</config>
</configuration>
Check case: Is it possible to change the location of packages for NuGet?
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.
We have successfully set up a couple of local package repositories using the NuGet.Server package and hosted them on a local IIS webserver. We are able to connect from the Package Manager and install no problem. So these are working fine.
In order for us not to have to check in our packages folder we have included the following command line in each project file that includes NuGet references. This works, if the NuGet.exe is in the path on the CI build agent.
However, I would like to move the source configuration form the command line in every project file and put it in just one place, preferably where other pesky developers can't change it ;)
<Target Name="BeforeBuild">
<Exec Command="nuget install $(ProjectDir)packages.config -s
http://domain:80/DataServices/Packages.svc/;
http://domain:81/DataServices/Packages.svc/
-o $(SolutionDir)packages" />
</Target>
Is there a better way?
Yes there is ;-)
Take a look at NuGetPowerTools. After running Install-Package NuGetPowerTools, it adds a .nuget folder to your $(SolutionDir) containing nuget.exe, nuget msbuild targets and settings (which you will need to check in).
After that, you simply run Enable-PackageRestore and it sets up msbuild targets into your visual studio project files which will make sure that packages will be fetched in a prebuild step, even on your build server, without checking in any packages. (don't forget to check in the .nuget folder though!).
This way, you simply manage the nuget package sources in a nuget msbuild settings file (in the .nuget folder) central to your solution, instead of in each project.
Cheers,
Xavier
I finally got NuGetPowerTools to install after the advice from digitaltrust on http://blog.davidebbo.com
Although NuGetPowerTools solved my problem, it was overkill for what I wanted. It requires that you check in to version control a .nuget folder that it creates in your solution root. The folder contains NuGet.exe, and a couple of target files. I don't like this as I think version control is for source code, not tools.
I came up with the following solution.
Save NuGet.exe to a folder on your local drive, both on dev and continuous integration machines. I chose C:\tools\nuget\
Add that filepath to the Path Environment Variable in all environments
On continuous integration machines, find %APPDATA%\NuGet\NuGet.Config and enter the following
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="LocalRepositoryName" value="http://Domain/DataServices/Packages.svc/" />
</packageSources>
You can add more than one entry to packageSources and NuGet will search them in the order that they appear
The after build code from my question can now be amended to the following.
<Target Name="BeforeBuild">
<Exec Command="nuget install $(ProjectDir)packages.config
-o $(SolutionDir)packages" />
</Target>
The end result of this is that whenever the approved repository location is changed, the config has to be changed in only one place rather than in every csproj file. Also, it is the continuous integration server administrators who determine that location, not the developers in their command line calls.