In the .NET doc, I see a lot of explanations around nuget metapackages, bu all the samples are with .NET Core. Is it possible to create metapackage for full .net framework assemblies and consume this with a .net framework app?
Will it be possible only with ProjectReference and not with packages.config?
Thanks!
A metapackage is just a package that doesn't contain any content/libraries of its own and has dependencies to all the other packages that it encompasses. This isn't something specific to NuGet, by the way, many package managers have the same concept and usually call them meta packages too.
About NuGet specifically, since NuGet has to deal with different target frameworks and asset selection, which many package managers don't have to worry about, it might be necessary to put some fake information in the nupkg to make it work properly. What I think I've seen before is to create an empty file named _._ in the lib\target framework folders that match the TFMs that the dependant packages use. For example, if you create a metapackage for packages that have libs for net45 and netstandard2.0, then you'd have two files in the nupkg, lib/net45/_._ and lib/netstandard2.0/_._, both are empty. However, I haven't tested this myself, so you should, but just in case a nupkg with only a nuspec and nothing else doesn't work, try this.
Since meta packages aren't otherwise special (they have the same package type as "regular" packages), they work just fine with both packages.config and PackageReference. Meta packages are perhaps most useful for PackageReference, because it supports transitive dependencies. In other words, the user adds the metapackage, their csproj gets one reference and is otherwise "clean". With packages.config, when they add the metapackage, all of the transitive dependencies will also get added to packages.config and csproj.
Related
When installing the two Nuget packages Hl7.Fhir.DSTU2 and Hl7.Fhir.R4, we get something like this:
The package DSTU2 seems to have issues using Hl7.Fhir.Support.Poco version 3.4.0.
If we install DSTU2 on it's own, all packages are using the version 1.9.0.
Is there a way in the .csproj file to specify sub dependencies versions and have the .dll installed in specific folders?
Here are the 3.4.0 versions .dll in my debug folder
Yes, you just add a PackageReference in your project for the transitive dependency as well. NuGet picks a single version to use for each package you depend on, and if you have a direct reference to a package then NuGet will always pick this version due to its nearest wins rule.
As you've spotted though, this can't be a lower version than any of your dependencies require themselves, or you get a package downgrade error. This is intentional - if you reference packageA which says it needs at least a particular version of packageB, then given that you can only use one version of each package it stands to reason that you need at least that version of packageB.
I've added new models and helpers to my project, but when I run nuget pack and install the package in my project I don't see the new items in the Assembly Explorer nor can I use them. Am I missing something during the build that wouldn't include new files added to the package?
I'm using visual studio 2017 and the nuget cli
At a guess, you didn't change the package version when you changed the code and packed again. NuGet is designed such that the package id/version produces an immutable package. This means it's valid to download a package, say Newtonsoft.Json 12.0.1 from nuget.org just once, and every time you use that package in any project on the same computer you can re-use the same download, rather than having to download it every time you restore/build the project.
This causes some people problems when they're trying to test their packages. One option is to take advantage of Semantic Versioning and use 1.0.1-preview.1, 1.0.1-preview.2, so every single build of the project has a unique version number. In addition, or instead, you could use a nuget.config to set the globalPackagesFolder to a different location that gets cleared every time you change the package. If you delete the "cache", it can't reuse the old contents. But this only works if you control the machines that use the package. Once you publish the package where anyone else can use the package, you will cause problems if you change the contents, which is why nuget.org doesn't allow deleting packages, only unlisting them.
However, another possible solution is to just not use packages and simply use project references. Some people have the misconception that if you have two packages, one depends on the other, that they need to use package references to make sure NuGet dependency information flows. That's not correct. If you pack with the MSBuild pack targets (highly recommended, and the default option for SDK style projects), NuGet will always convert project references into NuGet dependencies. nuget pack will convert project references into dependencies when the other project also has its own nuspec file. When you test your project with project references, you never have to worry about immutable packages. Just pack when it's ready, but it's not needed for testing.
Maybe you have a .nuspec file (at the same level than your .csproj) that you need to edit to include new files?
Today I was adding a NuGet package DocumentFormat.OpenXml into my C# project. My C# project is targeting.Net framework v4.5. In NuGet package manager it shows the information of dependencies of the NuGet package as shown below:
There is no information corresponding to .Net Framework v4.5. So, how do I interpret this information if my project is targeting .Net Framework v4.5. Is this information missing or there is any default assumption in such cases may be no dependencies. Can someone share some information in this regard
Note: This question might look like a non-programming question but I got stuck even before writing a single line of code so asking it in this forum.
.NET Frameworks are backwards compatible. Meaning if your project is targeting v4.5, you can consume packages with lower versions, such as v4.0, v3.5.
NuGet's specialty is compatibility checking (if packages are authored correctly ofc) :)
NuGet knows the available frameworks are v3.5, v4.0, v4.6 and netstandard1.3.
The "nearest" compatible framework with v4.5 is v4.0, so it'll pick the v4.0 assets when you install it.
So the answer, it has no dependencies in your case.
Please note that framework compatibility is not always apparent from just looking at the TFMs on nuget.org, there's different fallbacks that NuGet will attempt.
So really the best way to figure out what the dependencies are would be to install it in the project, since NuGet might need to resolve conflicts etc. if you have other dependencies.
When merging two projects, we're in need of Install-Package several 100 times. Doesn't Nuget support package restore, once Package.config is edited. The way it works like charm for Node JS package?
Once package.config is edited, why can't we fire Update-Package to
restore all packages?
Is it supported in the successor Dotnet CLI?
While packages.config tells NuGet which packages to download and extract (for which target framework), the process of installing package references may also modify the .csproj file. So if you update only one of these after a merge, you could find yourself trouble.
The successor of this mechanism is PackageReference (NuGet blog post), which replaces packages.config and only requires listing the referenced packages and versions (and even some additional MSBuild logic could be used by projects to manage shared versions / packages etc.). However, there is no migration tool available, so you'd need to uninstall all packages and add the package references you need. Some NuGet features also changes - for example the support fo content files (=> files copied into the project directory) was removed which may still be used by some projects (e.g. web projects assuming that jQuery or other JS libraries would be acquired in this way).
So I used to use the old packages.config method of installing nugets which worked by installing any dependencies when installing a package: i.e.
Package 1
Dependency 1
Dependency 2
I have now changed to use PackageReference but noticed as I was installing "Package 1" it would not automatically install the dependencies. As I wasn't sure I went and installed "Depdendency 1" and "Dependency 2" manually
Do I need to manually install "Depndendency 1" and "Dependency 2" when using PackageReference?
The direct answer to your question is simply no, you should not need to manually install the dependencies.
There have been a few changes and performance improvements in the recent VS 2017 and MSBuild work. There's some good information on what this means here:
In the past, if your project referenced package A, which in-turn referenced packages B, C and D, you would see all of them listed as your dependencies. With Transitive Package Restore, NuGet dynamically resolves dependencies giving you an uncluttered view of the packages you care about.
That explains the "missing" package references. If you're interested in the "missing" files themselves, there's more information on that too:
Solution-local packages folders are no longer used – Packages are now resolved against the user’s cache at %userdata%.nuget, rather than a solution specific packages folder. This makes PackageReference perform faster and consume less disk space by using a shared folder of packages on your workstation.
The reason I said should not need to is that there is a known issue around this area when mixing .NET Standard and .NET Framework.