We have 1 solution that contains all of our shared assemblies. Currently we are referencing these assemblies based on relative path (../../../../../SharedSolution/bin). It would be nice to create a nuget package (or a few based on various dependencies) to reference these assemblies so I can get easily update and I don't have to worry about having the exact same directory structure as everyone else on the team and all the other benefits of nuget.
However, let's say that when I'm working in my ProjectASolution, I realize that I need to make a change or add a shared class to SharedSolution. In my ProjectASolution if I have referenced the assemblies from SharedSolution with a nuget package, but I want to test my changes to SharedSolution before committing them, is the only way to copy the assemblies from the SharedSolution bin to ProjectASolution's packages folder?
Since we are frequently editing classes in SharedSolution, I'm beginning to think that nuget might not be the right way to share these assemblies.
Another possible solution is to add the projects from SharedSolution as links to any of my ProjectSolutions that need to reference them. Is this a better alternative?
Is there a better way to share these assemblies than relative path? Is there an easy way to test changes made on a dev machine to a nuget package?
You can build a pre-release package. Only developers who set their nuget to use pre-release packages will see them, everyone else will be still using the latest stable.
A good explanation and How-To can be found on the NuGet Pre-Release Package page.
To address the questions you raised in your comment:
You can build nuget packages locally, based on the .nuspec file which is usually next to the .nupkg file in the packages folder. You can use NuGet Package Explorer to do so in a GUI.
To distribute them, you can store the pre-release packages on a network folder. Any developer interested in the pre-release package can add this network folder to their nuget sources and can then use the Visual Studio-integrated nuget as usual. Or you can just copy them the .nupkg file.
You should be using as much self-contained testing as possible for an assembly before publishing a new package. Ideally, anything you would be putting into a NuGet package would be fully covered by unit tests and, if necessary, some kind of test app.
Also, if you're going to use NuGet, I would look at splitting up some of those assemblies if possible. It's easier to maintain references and track real updates to packages if they're in logically separated sets rather than one mega package.
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.
Let's say I have a windows forms application with a few Nuget packages that are important and need to be kept up-to date.
Is it somehow possible to update Nuget packages programatically from a non-development environment? With a non-development environment I mean a random user that is running the WinForms application (having it installed on their pc).
I've read some things about using nuget.exe, but updating the nuget packages should result in .dll files to be placed in the installation folder.
You can do that, but you should not do it. NuGet packages are development dependecies and not meant to be updated arbitrarily in an already compiled application or at the customer site, because
You cannot be sure that your application will work with the updated assemblies, since they may introduce changes that will lead to crashes or unexpected behavior at runtime.
NuGet packages not only include assemblies, but also build scripts and resources that may depend on MS Build or other tools that run in your development environment to be deployed or even included in your own assembly, like embedded resources.
Packages have dependecies to assemblies and other packages. You will need to update the dependencies, too, and there is a lot of potential to break anything with it.
You would need to include the NuGet CLI executable when shipping your application and your customer would need to a allow for pulling and installing packages.
Installing packages without testing them first may harm the quality of your application and could also introduce security issues. Remember that you may be dealing with executables from a potentially public package source.
That being said, do not do it. Instead, follow a responsible software develpment cycle, where you update packages and test your application throughly before delivery and provide frequent updates of you whole application to your customers.
Nevertheless, for educational purposes, you can install packages locally with Nuget CLI tools, in this example nuget.exe. You need to specify the package identifier, the output directory and the framework, like net472 for .NET Franmework 4.7.2. This will extract the contents, as well as the package itself to the output folder in the package folder structure that will not match your target directory structure. From there, you would need to copy the assets that you need into your install directory e.g. with a copy script. Apart from not being the right thing to do, this is very cumbersome and most likely deemed to fail.
nuget install <PackageId> -OutputDirectory <OutputDirectory> -Framework <Framework>
If it is auto-update, just think about if some method is supported in old version of dll, and in the new version it has been removed.
Though you can update the package suring build time.
Enable automatic package restore by choosing Tools > Options > NuGet Package Manager, and then selecting Automatically check for missing packages during build in Visual Studio under Package Restore.
Reference: https://learn.microsoft.com/en-us/nuget/consume-packages/package-restore#restore-packages-automatically-using-visual-studio
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?
We've got about two dozen projects, which all use different NuGet-packages and a bunch of Telerik WPF libraries, the latter are usually added by GAC, which on its own does not add a hint path to the csproj-File. (Good)
As soon as we use Telerik's upgrade wizard to simultaneously upgrade the references of all projects, Telerik starts copying the files to a local lib folder next to the bin folder and adds hintpaths, which do not exist on other developers machines AND need to be discarded before pushing to Git every time. (Bad)
BTW: We regularly get the same problem (regarding hintpath) with the Spire NuGet-Package.
Now we came up with some suggestions, which we internally valued differently and therefore did not come to an accord:
Keep discarding the chunks containing the hint path
Ask Telerik to fix the wizard
Check the libraries into Git
Add Telerik libraries using their NuGet server
Create a Libaries-Path we manage by hand, maybe as a network drive
What's other peoples approach to handling those issues?
I'd go for "Check the libraries into git".
Rationale: when a developer (or CI system) checks out your project from source control, he should be able to build it right away without having to install dependencies like GAC assemblies.
You need to use NuGet for that, it's the easiest and most organized way, you should not have a problem for other developers when you install a new package as long as you are committing package.config file, in this case any one will do a build of the solution visual studio will automatically restore NuGet Package.
Make sure to set your NuGet settings as below image shows:
Don't use the Telerik wizard. Add the Telerik dependencies using NuGet. They have a private NuGet repository. See the tutorial here.
I have an asp.net application using EF, MVC4 and some additional packages. Whenever I try to open the project on a different PC I have issues with the installed packages. My references are marked as missing, and the code is far from compilable. Last time I solved it by deleting references and packages and installing the needed packages one by one. I find the solution tedious. Is there any better, global solution for this? How is this supposed to be done? Shouldn't this be automated?
Thanks for the help and pointers!
UPDATE
I DO use NuGet Packages, (otherwise it would be very hard to get all these dlls) but somehow I always end up with uninstalling and reinstalling the packages to make my project work. I always end up with wrong versions and not compiling code.
I end up doing the following:
Delete package.config
Delete dependencies from the web.config file
NuGet Package Manager Console:
PM> Uninstall-Package A.B.C
PM> Install-Package A.B.C
Clean - rebuild project and hope for the best
I think Uninstall - Install can be replaced with Update-Package –reinstall A.B.C
I was hoping that there is a simpler solution for this.
If using visual studio; you can enable automatic package restore; this article outlines nuget in detail.
If you go to Tools -> Options -> NuGetPackage Manager you can make sure that the auto download is enabled. See the screenshot below.
Without knowing which references are broken, I would assume that you can at least use NuGet Packages to manage Entity Framework and additional framework references.
As lucian.jp said nuget it probably the way to go. At my company, we usually will go out of our way to find and use only packages that have maintained nuget packages, and even most of the core Microsoft ones have them, for example https://www.nuget.org/packages/Microsoft.AspNet.Mvc/
For the other ones, keeping a little thirdparty folder with external assemblies/dlls in the root of your repository and then reference from your project to that instead of from some random place on your hard-drive. I.e. check the third party assemblies into your project somewhere that is not your bin directories.
So if you have an existing project, here is what I suggest you do to avoid future issues:
For each of the assemblies, including your MVC ones, find the nuget equivalent, remove the dll from your project and add it back using the nuget package manager.
Get a copy of all the remaining assemblies and create a folder in the root of your repository and place them in there, then delete all of them and add them back in referencing the dlls from that folder.
If you are using git I'd also use .gitignore to not check in your bin directories. Which will force a new deployment of your code to get the assemblies from their respective sources.
Use Nuget for DLL packages like EF and MVC. But do not use Nuget for JS / CSS packages instead go for bower. Nuget packages for CSS and JS libraries are good but just their installation and uninstallation is tricky and may not match your project structure.