I should use a nuget package or a github source for reference on my project?
For example, I am using libraries like Template10 and Prism 6, and I started using them, when they did not exist on nuget, then I was using their github source to reference, but now both are on nuget, do I should migrate the references for nuget? or not?
TL;DR: Switch to NuGet packages for ease of use, stick with the source if you want to tweak it.
You can indeed clone the source of GitHub, build it yourself and add the dlls, or just add the complete projects to your own solution. It's necessary if you want to use a certain library before it's available on NuGet (or through another way as like e.g. a vsix installer). But it's a lot of work to keep that code in sync with new versions (and you're not always sure the version you just cloned is a stable version).
However there is a reason for the existence of NuGet, and that's ease of use. You pick a package version and work against that, you're the one deciding when/if you'll update to a new version of the package. You're 100% sure that the version you're using is working as intended (of course bugs do exist :)). You basically trust the experience of the library creators with which they decide when the code is stable enough to give a public release.
So except for when you're tweaking the library's source yourself, I would suggest to use the NuGet package for ease of use.
Related
I want to produce a set of NuGet packages written in C#.
These packages are class libraries, referencing each other in the way like:
MyGreatPackage.Core - no references
MyGreatPackage.Feature1 - references the core
MyGreatPackage.Feature2 - also references the core
MyGreatPackage.Feature2.SubFeature1 - references the Feature2 package and, respectively, the core
During the development stage, there is often a lack of real-world use-cases, so I decided to develop those packages as a part of a real project.
To implement it, I extract those packages as a git submodule(s) and connect them to the repository of the main application.
As a result, there is a .net solution like that:
MyApp.sln
MyApp.Host.csproj
MyApp.ClassLibrary1.csproj - references MyGreatPackage.Core.csproj
MyGreatPackage.Core.csproj - in the submodule
MyGreatPackage.Feature1.csproj - in the submodule, references MyGreatPackage.Core.csproj
MyGreatPackage.Feature2.csproj (references the core csproj)
MyGreatPackage.Feature1.SubFeature1.csproj (references the feature1 csproj)
Everything goes smoothly here, as I can develop both the app and the packages.
But, when it comes to the distribution stage, this configuration doesn't seem to work, as I can't simply push the submodule contents to the NuGet and replace the submodule references with the NuGet references.
The problem is that the Feature1 package when prepared for pushing to the NuGet, should have a reference to the MyGreatPackage.Core package and not a reference to the csproj. Also, the Feature2 package and subfeature1 package.
So how should I prepare this setup for both the development and the distribution stage?
I don't know a trivial answer to your question. But here are some possibilities:
Use some kind of tool that easily allows you to switch between project references (for working locally, being able to easily debug code, etc.) and NuGet references (for publishing your applications). RicoSuter/DNT has a switch-to-projects command that does exactly this.
Always use NuGet package references, and publish new versions whenever you need it: either to a local or to a private NuGet feed. You can debug NuGet packages with the use of tools like SourceLink, or punctually include projects. Depending how tightly coupled your projects are and the stage of development you're at, this option can be more or less viable.
The poor's man alternative to the first one when using the second approach: having a git stash that includes those projects in the solution and replaces the NuGet references with the project ones. If you work on your own, this can be an option to sporadically change to project references and debug something. If used often, this can be a pain due to those change being accidentally commited, etc.
I'm creating a private NuGet package for my company and I want to distribute two different versions of my .dll. The release .dll was for some developers who can call this dll for development. And the debug .dll id for some developers to develop the dll itself for the second version.
So my question is that if I wanted to accomplish this by using only one NuGet package, is this possible? Do I have to create a script on the installation of the package that adds references in the MSBuild, or am I overcomplicating things?
Any suggestion? Thanks in advance.
Do I have to create a script on the installation of the package that adds references in the MSBuild, or am I overcomplicating things?
To my knowledge, you may overcomplicating this things. That means you want to use one dll for debug mode to test and another dll for release mode to develop, so those two dll files should be independent, which should be distributed to different packages. Because a NuGet package will normally hold just a single set of assemblies for a particular target framework. It is not really designed to ship a debug and release version.
Besides, when we publish nuget package, the release version of your dll is the best choice since users wont debug into your dll, they will only care about if it works fine and how it works.
In addition, NuGet supports use any string as a suffix to denote a pre-release version, as NuGet treats any such version as pre-release and makes no other interpretation. So you can use -beta to specify a new version of that dll for develop.
https://learn.microsoft.com/en-us/nuget/reference/package-versioning#pre-release-versions
Basically per my understanding, use a different version of the package should be better. Of course, if you persist on using one package, Nekeniehl provided the correct direction.
Hope this help you.
You can create the same dll and each team can get the dlls like yournuget -release or yournuget -debug.
I normally use a buildscript to create the nugets, paket and FAKE will help you do the job.
And here a related answer to your question:
How to create a nuget package with both release and debug dll's using nuget package explorer?
I have a library written in full .NET and I am porting it to .NET Core. I intend to make it target the .netstandard1.1 (in order to be also compatible with .NET45).
When I create the project with visual studio, it automatically depends on the NETStandard.Library nuget package.
My library only needs two packages:
System.Runtime
System.Runtime.InteropServices
Two questions :
Do I need to restrict my project dependencies to only these two packages? Rephrased: may be nuget (or visual studio or another magic stuff) manage to restrict on its own to only the needed packages and not the full NETStandard.Library?
If the answer to the first question is no, is it a good idea to perform that restriction?
Thanks in advance.
(Sorry for my english, I am not a native speaker)
There are some aspects in your question...
The netstandard1.1 framework choice will limit your available API surface in the editor (here VS Code) to what is available that version. Just tested with File.OpenRead on VS Code for netstandard1.1 (not available) and netstandard1.6 (available).
The NETStandard.Library dependency (version 1.6 is good for both cases) is a package dependency. Once the assembly is compiled, the assembly itself will declare external assemblies (aka referenced assemblies) which were actually used (e.g. System.Runtime and System.Linq) and not all assemblies found in the NETStandard.Library meta package.
As long as you are not packaging it up for NuGet, assembly reference restrictions are anyway done for you. NuGet packaging however would refer to the NETStandard.Library package
If you use NuGet and that reduction is important to you, I guess the correct term is NuGet dependency trimming, a manual process explained here (short version: copy all references from the meta package and remove all you do not use).
I am not sure if it's a VS bug, however seems like VS doesn't like building a library and not having a NETStandard.Library package included :) So, no.
Unless you use Visual Studio Code or Notepad etc. this will slow down your development, since VS will prevent you from building the project etc. So, no again.
The bottom line.
Premature optimization might cause more issues than benefit. Port your library first, and only then check if you need to optimize it.
I'm making a complex application and I would create more little packages to include. I have installed a nuget package "CreateNugetPackageFromProjectAfterEachBuild" that create or update automatically a package of my application. In this moment I create two types of package Debug and Release but from VS15 I see only one package to install. Why? Is the correct way to work?
Thank you!
It's not clear from your question, what exactly you want to create NuGet packages for.
In any case, it makes no sense to have separate Release and Debug versions of packages. You could separate them by version, though:
have stable releases built as Release
have prereleases built as Debug
Make sure that each NuGet package you build has a different version, otherwise you'll cause yourself a lot of grief. NuGet has no way to differentiate between different packages with the same version. You can only update a package to a different version and individual versions are cached. It's best you create and publish new package versions from a build server, not directly from a development environment to avoid confusion.
Also, keep in mind that you should really only be using NuGet packages for libraries which have an independent lifecycle and are used in multiple projects. You will want stabilize a library before creating a new version of the package and then stick with this version in your application until you have a new stable version of the library ready.
If your libraries are more tightly coupled to the application - they don't have a separate lifecycle and you tend to modify them together with the application, then referencing them in the application as a NuGet package is not that good of an idea. You're better off just having both the libraries and the application as part of the same solution.
We've recently started using our own internal NuGet server to house packages that are common to many of our internal projects. Originally, every project we work on is versioned with the build date in the format:
[Year].[Month].[Day].[DailyBuildCount]
However, during our process to upgrade to .NET 4, we've decided to start versioning our packages with SemVer starting with v4.x. The problem is that NuGet treats the v4.x versions as OLDER than the ones versioned with the date format. In addition, projects referencing the v4.x versions think they need to upgrade to the versions with the date format, which aren't even targeting the same framework version.
Is there some way to configure NuGet such that package upgrades can't cross these versioning lines?
For inter-package dependencies, we have configured them with specific version dependencies such that dependencies themselves work OK. It's the main project reference that is the issue where "upgrades" may accidentally happen to an older version.
Offhand, I think your best bet is to rename the packages slightly. That will cause them to be considered as completely separate packages and break the version chain altogether.
I have a series of three blog posts that would help you:
Performing a safe update using NuGet and Powershell
Performing a safe update using NuGet and Powershell with pre-release packages
Coercing the jQuery NuGet package version and downgrading jQuery
The last link shows an example (in this case jQuery, but can be applied to any package) on how you can coerce the version to a specific range. This will ensure that when you issue an Update-Package command, the project is updated only with references that have a version between a minor and major value).
However, in your case probably the best solution would be as Eric Lloyd suggested before to completely break your dependency chain in order to keep a clean dependency structure.