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.
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 coding on a project that has several Azure-based applications, as well as several Windows services, etc. Needless to say, it's just a bunch of individual applications that are deployed out to Azure, or elsewhere, and expected are all expected to work together.
We use Nuget for our underlying library project versioning. Every feature or change results in a bump to the Nuget version, a package published to our private Nuget server, and a subsequent update to every other application that needs the update. This is currently a tedious manual task, but is not even my most immediate source of frustration.
The thing that I struggle with the most, currently, is while doing development on a feature that requires changes across the entire set of applications, from bottom to top, and having to constantly push out Nuget packages and update Nuget packages just to even develop and debug.
Prior to using Nuget, we may have just added all of these projects as direct dependencies on disk, which removes versioning but instantly lets me develop against my local changes.
Now with Nuget, I can't develop against local changes without pushing out a new package.
Is there a workflow that I'm missing that would allow me to still use Nuget but also be able to make changes and work locally without having to push and pull Nuget packages all the time?
Can I somehow develop against local projects, but also somehow have the project dependencies know to use the Nuget packages?
I ran into this issue when setting up a shared NuGet repo for my company. You can set up local a NuGet feed and 'publish' just by dropping files to a folder. This is extremely useful for local testing before you're ready to publish to the shared repo.
Also, NuGet uses semantic versioning. I find it useful to have pre-release versions by using a tag like MyLibrary.1.0.0-prerelease-12345 so you can still have incremental builds, but most other apps will not be notified of the changes until you create a major release such as MyLibrary.1.0.1. This could require you to make some changes to your DevOps process, but it allows multiple developers to test your package before 'officially' releasing it.
If your issue is that you want to be able to easily update multiple applications locally and test those changes. I have occasionally found it useful to create a single solution file encompassing all my projects so I can quickly open, update, and build everything in one Visual Studio instance. However, this solution is not particularly scalable, so you might be better off writing PowerShell scripts for automation.
Update Another solution that you might find useful is NuLink. I have never tried it so I can't actually endorse it, but it purports to provide similar functionality to npm link (and actually uses symlinks just like npm does).
Given the projects are all in the same repo, just use project references instead of package references.
When you pack a project, NuGet will convert project references into NuGet dependencies, and the dependency version will be the same as what the other project is if/when it is packed.
Check this answer, where you could:
build the dependency's code locally to produce DLLs.
replace the DLLs in your machine's nuget cache folder corresponding your dependency with the local DLLs produced in the previous step
That's a quick way to see changes locally without publish-consume cycles
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 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.
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.