I'm trying to customize an existing NuGet package to add some new behavior, specifically into a package called StyleCop.MsBuild
Downloaded the source of the package from bitbucket repo (https://bitbucket.org/adamralph/stylecop-msbuild/wiki/Home)
Changed id of package in *.nuspec file from StyleCop.MSBuild to MyCustomPackage
Created *.nupkg file using NuGet Package Explorer
Uploaded *.nupkg file to my local NuGet server
So the only change was the id of the original package.
But now when I try to install MyCustomPackage into a project, it is installed on the solution level and not on the project level. Visual Studio creates a folder called '.nuget' in the root of the solution and places the packages.config file in there.
Not sure what causes this change since all I did was to change the package id.
Any help appreciated.
The StyleCop.MsBuild package has an msbuild target in the build folder and the convention is that the name should match the package id. So by changing the package id, the msbuild target file was not referenced anymore and the package became a solution level one.
https://docs.nuget.org/create/creating-and-publishing-a-package#import-msbuild-targets-and-props-files-into-project
Related
How do I disable "transitive package management"?
I wish to do so, so that I can install a package that I "packed" locally and have in a .nupkg file. When I attempt to do so, I get a messaging stating that The 'Source' parameter is not respected for the transitive package management based project(s) {csproj file}. The enabled sources in your NuGet configuration will be used.
Complete Context
When developing a NuGet package that's not ready for distribution via our NuGet feed, I often create a local .nupkg file like this from the package manager console:
nuget pack {path-to-csproj-file}
This generates a {project-name}.nupkg file, which I can then install in another project by opening it in Visual Studio, navigating to the package manager console, and entering the command
Install-Package {path-to-nupkg-file}
This has worked great and once the NuGet package is ready for distribution, we push it up to Azure DevOps and let the build pipeline there push it into our feed.
However, I just recently inherited a project where the prior developer apparently setup "transitive package management" that prevents this workflow. Here's what I get when I try to install directly from a .nupkg file:
Install-Package C:\Users\Josh\source\repos\SpeakerDiscountManager\SpeakerDiscountData.1.0.5.nupkg
The 'Source' parameter is not respected for the transitive package management based project(s) MembershipApplicationWidget\MembershipApplicationWidget.csproj. The enabled sources in your NuGet configuration will be used.
<snipped several lines of unsuccessfully searching configured package sources>
Install-Package : NU1102: Unable to find package SpeakerDiscountData with version (>= 1.0.5)
Obviously, it doesn't find the package I've specified via file, because it is searching online feeds and it doesn't exist in any of our online package sources--the package is in a testing state, not ready for anyone to use but me.
Based on the error message, I need to turn off "transitive package management" so that I can specify a file source for the package, but I've been unable to turn up any information online about how this is configured.
I did try installing this exact same .nupkg file in another project, using the same Install-Package {path-to-nupkg-file} procedure. This works.
How to disable “transitive package management” for a Visual Studio
project
I think this problem transitive package management is related to your current project structure which has some intricate dependencies, custom rules and so on. Therefore, turning off transitive package management is unpractical. If you create other projects and then install this package by your way, I think it probably will not occur.
As a best workaround, as you said(hint from the message The enabled sources in your NuGet configuration will be used.), add the the local nuget package's path into Nuget Package Source.
In your side, I think you specify -Source xxxxx(the path of the nuget package) to install this package in the package manager console, if so, this function actually is inconvenient.
You can just add the folder path which SpeakerDiscountData.1.0.5.nupkg exists into global nuget package source. Once you have done it, it will applies to any projects in this machine.
It has two ways:
1) VS IDE UI
Tools-->Options-->NuGet Package Manager-->Packages Sources-->add a new key and input the path of the nuget folder. Also, check its option.
2) global NuGet.Config file
(C:\Users\xxxx\AppData\Roaming\NuGet\Nuget.Config and step 1 is just add the path into this file by VS UI Control)
add these:
<packageSources>
<add key="Local Packages Source" value="C:\Users\Josh\source\repos\SpeakerDiscountManager\" />
..........
</packageSources>
After that, you can use your command to install this nuget package.
Note: If the root directory of your solution also has a file named nuget.config, the parameters in it will override the global file. It has the highest priority.
Just go to Vs IDE Tools/Nuget Package Manager/Package Manager Setting And Check The address of Package Sources.
it's something like "C:\Program Files (x86)\Microsoft SDKs\NuGetPackages".
Then Copy your package file into that folder and at last run this command in Package Manager Console:
install-package packagename
My team has an internal Nuget package source in the form of a local folder synced to a NAS. The files have configuration (release/debug) and platform (always "AnyCPU") in the file name, e.g:
MyPackage.1.0.6017.25342.Release.AnyCPU.nupkg
This works fine in VS 2015 but in VS 2017 the packages aren't found by the package manager unless we remove the "Release.AnyCPU" part.
Does anyone know why? Can this be fixed?
The name of the nuget package is composed of the package ID and the version when we pack a package. For example, Easyfy.Commerce.Model.1.0.x.x.nupkg. If you specify Configuration info into the name, the name of the package changed to Easyfy.Commerce.Model.1.0.x.x.Release.AnyCPU.nupkg, but the package ID the has not changed, is till Easyfy.Commerce.Model. In this case, the package name do not match the package ID and version, then the version of the package could not be list in package manager.
As test, you can open a package with NuGet Package Explorer, then change the package ID, you will get below prompting:
To resolve this issue, you just need to change your package ID to "Easyfy.Commerce.Model.Release.AnyCPU" by NuGet Package Explorer and change the package name to "Easyfy.Commerce.Model.Release.AnyCPU.1.0.6017.25342".
Besides, the reason for this issue occurred on the Visual Studio 2015 but does not occur in Visual Studio 2017 is that more restrictions in nuget 3.5 and later.
Hope this can help you.
OK,
So i recently reinstalled windows 10 and upgraded vs2013 -> vs2015. At this point i tried to grab a couple of nuget packages.
The problem i am having is that i have a .nuget/packages folder at the same level as my solution file (set via NuGet.config) but i also have exactly the same folder getting created in the root of my user folder.
the packages folder for my solution contains the packages installed for that solution, while the one i don't want in my user directory contains all the packages for all the projects and solutions i am working on.
Is there a way i can prevent this .nuget folder being created in my user directory? it seems useless when i already have package folders for my solutions
Thanks
You can clear the .nuget\packages directory under your user profile however the packages will be downloaded again if you install them again.
Package retrieval
%USERPROFILE%\.nuget\packages is the local machine cache used by NuGet v3 when installing NuGet packages for new project types, such as Universal Windows projects.
For a C# console project NuGet will use the %LOCALAPPDATA%\NuGet\Cache directory which is also what NuGet v2 uses.
ASP.NET Core projects currently use their own %USERPROFILE%\.dnx\packages directory for NuGet packages.
Specifying a custom NuGet package location
To prevent NuGet from copying the packages to your user profile you can create a new %NUGET_PACKAGES% environment variable pointing to the location where you want NuGet to copy the files e.g. C:\git-repositories\.nuget\packages.
To prevent NuGet from copy the packages to the solution folder too you can create a new NuGet.config file either in the solution folder or at any higher level up to the root. As content you can specify following XML.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<config>
<add key="repositoryPath" value="C:\git-repositories\.nuget\packages" />
</config>
</configuration>
As help for configuration inheritance please follow this link: NuGet Configuration Inheritance
I'm attempting to create a nuget package using Nuget Package Explorer. The project is just a collection of dlls and files I need copied to the output (bin) directory of the project in which it is used, which unless I'm mistaken is pretty much the way nuget packages work.
However, after creating the package the path to the files I want copied appears to be incorrect, even though I specified no such path in my package.
I created the package, added the libs added the two platforms I want to support (Win8.1 and WP8.1 RT) and added the files for each platform in their respective libs container.
When I install the package into my project it creates the package folder with the exact same structure. Everything looks good.
However, when I then build the project, instead of trying to add the contents of for example:
packages/MyPackage/libs/wpa81/MyProject.WindowsPhone.Data.xml
it's instead attempting to find this:
packages/MyPackage/libs/wpa81/MyProject.WindowsPhone/MyProject.WindowsPhone.Data.xml
and so I get an error like:
C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\v12.0\AppxPackage\Microsoft.AppXPackage.Targets(1496,9):
error APPX0702: Payload file 'C:\Users\Me\Visual
Studio\AnotherProject\packages\MyPackage\lib\wpa81\MyProject.WindowsPhone\MyProject.WindowsPhone.Data.xml'
does not exist.
now, MyProject.WindowsPhone IS the name of the original project I used to create the content I want to include in the package, but I make no reference to this folder anywhere in the nuget package or manifest.
If I manually create that folder and move everything inside it works, but none of the other packages I use require me to do this. I want to simply reference the files that are there, where is it getting this folder name from?
does anyone have any idea what I'm doing wrong? please let me know what information I can add to help identify the problem...
How can I get Visual Studio to build a NuGet package for my library component on build?
I’m using a Portable Class Library as the example project.
Ensure the NuGet.exe file in .nuget folder is latest.
Default values come from AssemblyInfo.cs, so clean that up.
Add a NuGet package reference if you do not reference any, preferably something simple like JSON.NET. Often, PCL projects have no external dependencies, in which case no NuGet refs and without any NuGet refs, the required MSBuild config won't get set properly, so we need to add a 'dummy'.
Enable NuGet Package Restore.
Edit the NuGet.targets file and ensure BuildPackage is true.
<!-- Property that enables building a package from a project -->
<BuildPackage Condition=" '$(BuildPackage)' == '' ">true</BuildPackage>
Edit your .csproj file and add this to the first, default PropertyGroup
<BuildPackage>true</BuildPackage>
Rebuild your project and then search in the Output for nupkg and confirm creation and location of the package file.
Remove the dummy NuGet package reference and build again and check the Output.
To further customize the package creation, you can stick a MyProjectName.nuspec file next to your .csproj file.
See http://docs.nuget.org/docs/reference/nuspec-reference for more on the NuSpec format. You can also pull one from an existing package (its just a zip file) and have a nose around, see how it was done.
Add a post-build event like this:
$(SolutionDir)\.nuget\nuget.exe pack "$(MSBuildProjectFullPath)" -p Configuration=Release -o "$(MSBuildProjectDirectory)\bin\Release" -symbols"
And download and place nuget.exe in the .nuget folder alongside your solution file.
You can use nuget update -self to keep the .exe fresh.
Note
nuget.exe pack has a bug currently where it'll see a packages.config file and try to look for the packages it mentions in your solution but it fails to find them if the packages folder is in a strange place, e.g. if your solution file isn't a level up from the project.
To workaround this, add another post build event to copy the packages folder into the project folder.
The repositorypath config setting seems to do nothing for me.
See GitHub reports:
https://github.com/NuGet/Home/issues/5316
So funny. I was having problems with my usual way of auto-building a package on build when I arrived at this new way. So I looked for a suitable SO question to answer with my new post-build method when I came across my own question here!