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.
Related
I'm building a NuGet library (.NET standard), and I'm using some other NuGet dependencies.
They have other dependencies that my code doesn't need (I don't use the code that use that indirect dependencies).
Is there any way to remove the unused indirect dependencies from my package, so it will be smaller?
Those indirect (or transitive) dependencies won't become part of your NuGet package. NuGet is smart enough to detect that and restore the transitive dependencies on nuget restore YourPackage.
You can easily check this when opening your nupkg file with a tool like dotPeek - you won't see the transient dependencies inside.
Or let's take Newtonsoft.Json: as you can see in the sources, a bunch of other packages are referenced when targeting .NET Standard 1.3, e. g. System.Xml.XmlDocument.
But when looking inside the package, it's only the Json.NET assembly:
So you don't have to worry about that.
I have a project (a PowerShell module) that relies upon a NuGet package, whose assemblies are loaded into my module via the Add-Type cmdlet. I would like to install this package via NuGet instead of manually copying it into the correct folder. This would save me from committing it's binaries to source control. Also: when thinking about CI/CD, I'd hate to have them in my repo.
I know I can curate a packages.config file and use nuget install instead. But this command installs the package together with it's dependencies into a separate folder and therefore the framework will (runtime) not find the required dependencies.
I know I could also provide a script that performs the nuget install and then copies the required .dll files into a single folder. But I would have to deal with the fact that the package might have different versions for different target frameworks and I'd need to handle the compatibility. Or maybe the package has other additional required files that I know nothing about.
So here my question: there has got to be a simpler way to do this? Something less ... circuitous and cumbersome?
I have my own Nuget package source for internal libraries. Some of the projects reference other projects in the same solution. Currently the dependencies are referenced to the Nuget package. Management of this be becoming a pain since if a project that has a dependency is updated, I have to wait for that dependency package to update so I can update the other project with the new reference. Some of the projects have multiple layers of dependency, so in some cases I to wait for 5 builds (build, update package, build, update package in next level, etc.) to get the package into the main project. Is there a better way to manage this or is this just the price to pay for using Nuget?
Ideally you wouldn't include your libraries in the solution for a given application and only add them to the solution via NuGet. You can manage versioning between the NuGet Packages in the packages.config file of a given library and by referencing NuGet Package versioning.
When I have a situation where I need to step through the library code from the consuming application then I remove the NuGet package and add the library project to the solution. Then add a project reference from the application to that library project. Ideally this should be a rare occurrence.
Is it true that for every dependency that a package has on some other library, that those libraries need to be resolved and installed as well?
For example, I created a package which uses NLog, Postsharp and WindowsAzure.Storage:
Do clients of my package now have to install these packages as well? Why is it not possible to include these dependency DLLs within the package?
When a consumer installs your nuget package, nuget will automatically resolve and install the dependent packages as well.
It is possible to include the dlls within the package but it is not recommended. Because one way or another they will have to have references to the dlls they need to use your package( in this case NLog, PostSharp and WindowsAzure.Storage). Its better that the consumer have controll over what libraries are installed.
Another benefit of having dependencies via nuget is that the consumer may decide to install a newer version of WindowsAzure.Storage library which he can do easily when you don't have the dll injected into the package. Otherwise you can get into some messy assemblies runtime errors.
You control what your package contains via nuspec file used to build the nuget package.
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.