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.
Related
We would like to have one solution packages.config rather than individual packages.config at the project level. We have a rather large solution (over 300 projects) and we have had issues with project config like people forgetting to upgrade all projects to a specific version of a package. We realize that it will lock us to a single version of each package across all projects and we are ok with that. I've attempted do this to a few projects by deleting all packages in the project and then trying to re-add them through the solution rather than the project but its just re-adding the package.config at the project level. I even tried to manually delete the project level packages.config file and add them to the solution level and then using the solution level "manage nuget packages" dialog but the same thing happened.
I'm kind of going off this post which is quite old:
Manage packages at the solution level
Dependencies issues with multiple Project packages.config files in solution
You could not consume NuGet package for solution level with package.config. That because NuGet team deprecated solution level packages in NuGet 3.0. So you could not consume NuGet package for solution level with package.config.
Besides, you can use Manage NuGet Packages for Solution.. to manage the packages for all projects in the solution:
Right-click your solution > Manage NuGet Packages for Solution...
or
Tools > Library Package Manager > Manage NuGet Packages for
Solution...
Then add it to all the projects by browsing for your package, then checking the top checkbox, and clicking install.
Or you can simple add following NuGet command line in the Package Manager Console:
Update-Package <package_name> -version
This command line will update package for all projects.
If manage NuGet package at solution level is your persistence, you can consider Martin`s advice using PackageReference.
Hope this helps.
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'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).
I have a package Ninject.Extensisons.Wcf which shall be installed differently depending on the type of the project to which it is installed. In the case where WCF is hosted in IIS (any project containing global.asax) a second package Ninject.Web.Common needs to be installed together with the package. For all other project types such as libraries, Console, WinForms, WPF applications this package should not be installed.
Is it somehow possible to achieve this e.g., using a powershell script? Or do I have to deploy two different packages in this case?
Unfortunately the current nuspec file does not provide for managing dependencies based on project type. We currently support targeting different framework versions, but that doesn't apply in your situation.
It is recommended that all dependencies are handled using package references. Although it would be technically possible to download and install a package using a PowerShell script, this is not supported and will most likely break in future versions.
First determine if it would actually be a problem to reference a web package in a non-web project. Just because assemblies are referenced, if they are not used, it should not have an impact.
If it turns out that having the web dependency causes undesirable side-effects, then you'll need to create separate packages.
I would split up your package into logical pieces. As you state, you have a package that is used by non-web projects. Web projects require a dependency on a different package.
So now you have 2 logical packages:
MyProject
MyProject.Web
MyProject (dependencies)
SomeOtherPackage
So a user would Install-Package MyProject for non-web projects, and Install-Package MyProject.Web for web projects.
At this point you would be done and everything would be fine. But I think you should consider another step. One of the issues I see with these split packages is that I have to figure out which particular package I need to install. I have to know that I need the "Web" version.
At this point, determine the typical use case for your package. If 90% of your users will be installing the Web version, then I would make a "meta" package that simply has dependencies for your common packages.
In your case I would make 3 packages:
MyProject (meta package)
MyProject.Web
MyProject.Web
MyProject.Core
SomeOtherPackage
MyProject.Core (common non-web package)
By creating the "meta" package, you can reserve the "short" package name for the most common case. This meta package only has dependencies to other packages.
A good example of this is the SignalR package.
Hope this was helpful.