I have a nuget package that references other nuget packages. One of these "inner" packages has a security hole. How can I - without changing the package - overwrite the "inner" reference? Thanks for the help!
Your only option is to directly reference that package in your project/package so that the fixed version is "nearer" to the project that is being restored.
However you cannot change the package identifier, only the version being used (and in worst case szenarios, create your own package from a fork with the same id/name but a custom version - e.g. 1.2.3-workaround.1)
Related
I know, you should not change the Package ID of a NuGet Package. But I did, because of a big refactoring.
Now I want to know if there is a proper way to define a successor NuGet package.
Old ID in Nuspec: OldLibrary1
New ID in Nuspec/csproj file: Library1
If a user opens the NuGet Package Management window for a Visual Studio Solution and the old package (ID OldLibrary1-1.0.0) is installed, he should see an update/upgrade to package Library1-2.0.0.
Is there a possible way to define this in some way?
By the way I use ProGet as NuGet server.
NuGet recently added deprecation information to it's HTTP protocol, however, as far as I know, only nuget.org has implemented it (it's very new, NuGet 5.3, Visual Studio 16.3). If your private nuget server (Proget) hasn't implemented it yet, you can try contacting the developers and ask them to implement it.
Otherwise the best option I've heard about is to create a new version of your old library, do not include any assemblies in it, just have a NuGet dependency on your new package id.
The issue with this is if your package consumer is using PackageReference, Visual Studio's upgrade experience isn't yet great, because when you release a new version of your new package, people getting it as a transitive dependency of your old package won't be notified about the available upgrade. An option to work around this is to include a MSBuild targets file which displays a build warning on every build, telling them to install the new package and uninstall the old package. People who ignore warnings won't see it, so if you want to be extreme, make it an error instead, but it helps get the message out.
We are using an internal nuget server to handle a handful of common class libraries, and we manage our nuget packages at the solution level.
When a project (say MyProject) references a common library, say Newtonsoft.Json, the reference proprerly comes from C:\dev\myproject\packages\Newtonsoft.Json.9.0.1\lib\net461\Newtonsoft.Json.dll. The moment I add another package (say CommonProject) to MyProject that also references Newtonsoft.Json, the reference in MyProject CHANGES to C:\dev\myproject\packages\CommonProject\lib\net461\Newtonsoft.Json.dll.
This causes serious problems and a great deal of dll hell. The moment one of these common projects changes one of their references - let's say CommonProject no longer uses Newtonsoft.Json. The moment MyProject upgrades to the latest version of CommonProject, MyProject will now fail to compile because it can no longer find Newtonsoft.Json in C:\dev\myproject\packages\CommonProject\lib\net461\Newtonsoft.Json.dll. MyProject still lists Newtonsoft.Json as a nuget package reference, and the Newtonsoft dll is still sitting pretty in the Newtonsoft.Json folder of packages, but the dll reference is jacked up from when I first added the CommonProject nuget package. Nuget stupidly CHANGED every single shared package reference to map directly to the CommonProject folder instead of the packages folders for each of those packages. Even if the projects are referencing the exact same version of the same package, nuget still changes the reference.
Moving all shared package references to the folder of the last package added is making me think that nuget isn't managing packages at all.
Please tell me I'm doing something wrong, and let me know how I can get the packages to be properly referenced from their respective folders.
I'm investigating using NuGet internally to share an assembly used across multiple solutions. Despite the documentation making it look simple, I'm just getting a faceful of problems. I have two questions at this stage:
1) When I create the package, NuGet reports it as having 'no dependencies'. In fact, the assembly's project has quite a few dependencies on other (official) NuGet packages. I assumed that NuGet would spot this. Is there something I need to do so that NuGet knows my assembly itself has NuGet dependencies?
2) When I attempt to add the package to a project in another solution, it doesn't actually add the dll to the project (i.e. in the project's References). The package manager GUI lists the package in the installed list, but doesn't show a 'Manage' button, as it does for other packages. Instead, it just shows a 'Uninstall' button. So it's as if the overall solution is now aware of my package, but I can't add it as a reference to any projects, which is obviously of no use. This happens regardless of whether I install using the GUI or the command line. Does anyone know why this might be happening?
Thanks in advance.
For issue 1, if you are using nuget.exe pack and your project installed certain packages, these packages will be added as dependencies. If the packages are installed to another project that the main project is referencing, do nuget.exe pack -includereferencedprojects. For more information, please refer to http://docs.nuget.org/docs/reference/command-line-reference#Pack_Command_Examples.
For issue 2, you have probably installed a solution-level package, which does not have Content or Lib folder inside. If you install a project-level package, you should be able to see the manage button.
Hope this helps.
I'm moving my large project to properly use NuGet packages. However, I know that although they shouldn't, some developers will simply add references to assemblies in packages, rather than properly add NuGet refs, and I want to prevent that.
Is there a solution that either:
Checks this inside Visual Studio, and suggests the correct ref instead?
Checks this in build time, and produces build errors?
NuGet doesn't have any built-in command to validate this, however it would be relatively simple to write some code to do this.
The basic steps are:
for each project in solution
for each reference in project
if reference in path 'packages'
if package not in 'packages.config'
log 'invalid reference: use NuGet'
I've created a NuGet package that contains some custom MSBuild tasks named MyCompany.MSBuild. These tasks have a dependency on Newtonsoft.Json. This means that after my package is installed in a project, Newtonsoft.Json.dll will have to be in the same directory as MyCompany.MSBuild.dll.
I could easily accomplish this by bundling my own copy of Newtonsoft.Json.dll in my package, but I wonder if there's a better way that means I won't have to update my package whenever a new version of Newtonsoft.Json comes out.
If I declare Newtonsoft.Json as a dependency, NuGet will install that package into the project when somebody installs my package, which isn't what I want to have happen.
How can I specify a dependency in my package without having NuGet install it and add project references? Additionally, how can I copy that package's assembly to my own package's folder after it is installed?
A package with a "hidden" dependency is something absolutely undesiderable in my opinion...
I know it's not a real answer but... Have you considered to use JavascriptSerializer instead of Newtonsoft.Json? It's a bit slower but your package will be absolutely self-contained: less pain for you and for your users.