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.
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 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.
I have a C# DLL that in turn calls a C library. How do I package these libraries in a NuGet package?
For example, I have two DLLs MyCSharp.dll and MyC.dll
How do I package both these DLLs so that when I add the NuGet package to a Windows Universal/UWP project, MyCSharp.dll is able to call MyC.dll successfully?
I tried adding copying the MyC.dll to the same folder as MyCSharp.dll during install time, but this doesn't help.
I was able to get this working by placing my MyC.dll & MyC.winmd libraries in the build folder of the NuGet package. See http://blogs.msdn.com/b/mim/archive/2013/09/02/packaging-a-windows-store-apps-component-with-nuget-part-2.aspx for very elaborate write up on packaging WinRT components with 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.
I have created versions of NuGet packages,uploaded and it is working fine.
I have set of libraries in my package which has been populated in different directories inside the package.
Some users might require a particular directory of my NuGet package, and some of the libraries might not be needed. While installation I should prompt users that which part they need to install.
One Solution:Logical seperation of packages may be one solution. Like packing libraries in separate packages, and required packages can be installed.
But If it has been made selective installation, then it would be more easier. I have no idea whether NuGet have such an option. Any help would be appreciated.
NuGet has support for framework versions and platforms using conventions, you can read up on them in the docs. You can group them by target framework version or by target framework profile.
If you want to selectively install libraries, you are saying you want to selectively install dependencies: you should split them up in separate NuGet packages and declare your dependencies. These dependencies also can be grouped.
If your condition cannot be defined using framework version or profile, you should come up with your own entry-level NuGet packages and bring down the proper dependency chain (or use PowerShell hooks for this).