What is the best way to make a .dll available as a NuGet package in a local environment so that others can download that and use it whenever they want. We use TFS as the CI server and I want NuGet package (with a version number) to be copied to a location in the intranet after every build so that users can pull it when they want. (Do not want to push). I want this to happen from the all the feature branches, any feature branch other than main needs to package this as a beta. Thanks.
Take a look here: https://www.nuget.org/packages/CreateNewNuGetPackageFromProjectAfterEachBuild/
This will build a nuget package whenever you build.
Related
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
Is it possible to delete NuGet packages from a Visual Studio Online package feed?
I've setup CI on Visual Studio Online using the Build Tasks for a dotnet core project.
One of the steps is to pack all the projects in the solution as NuGet packages and push these to the package feed.
The build is working fine, however in my first attempt in the pack and push build steps I used a **/.csproj wildcard instead of src/**/.csproj. So it packed and pushed all my test projects too that were under tests/**.
I'd like to delete these packages from the feed. The only option I could find in the UI was to unlist the packages. But the packages still exist after this operation.
I also tried to delete the packages through the CLI: nuget delete. But it just does the same as unlist.
Has anyone been able to delete their packages?
Yes, this is possible out-of-the-box with VSTS' Package Management. Note that there is a difference between unlisting and deleting, which I'll elaborate on further.
The TL;DR story for deleting existing packages from VSTS Package Management is that you must be the 'owner' of a package OR have a 'Project Admin'-like role in order to delete it. To unlist a package, you only require the 'contributor' role. For both options, simply go the package details in VSTS and select the appropriate option from the menu under the ellipses:
Now for some background info which might be useful. There is some official documentation available on visualstudio.com:
There are two options available to remove a version of a NuGet package from a feed.
Unlist: unlisting a version of a package modifies how the package appears in NuGet clients (see the NuGet docs for a full description of how unlist works). Unlisting a version can help you prevent new usage of it without breaking dependent projects and builds.
Delete: Deleting a version of a package makes it permanently unavailable for install or restore.
Unlist and delete both respect feed immutability. Once you publish a particular version of a package to a feed, that version number is permanently reserved. You cannot upload a newer revision package with that same version number, or delete it and upload a new package at the same version.
The important part here is "feed immutability", which according to the canon, translates to:
Once you publish a particular version of a package to a feed, that version number is permanently reserved. You cannot upload a newer revision package with that same version number, or delete it and upload a new package at the same version.
The documentation also confirms, as a footnote at the bottom, what you already discovered about nuget.exe:
Currently, NuGet.exe can only unlist packages; Team Services and TFS interpret nuget.exe delete as an unlist operation to be consistent with NuGet.org. To delete a package, you must use either the REST APIs or the web interface.
Doing it programatically should therefor either be done through the REST API or the VSTS admin section, as described above. NuGet.exe can only be used for unlisting - not deleting.
With all of that taken into consideration, with VSTS you can delete packages but - as always - think twice before you do so. Remember the LeftPad debacle? ;)
I have some 3rd party DLL's i need migrating into a TFS Nuget Feed, and I haven't been able to find many articles on the internet about installing specific versions of a given Nuget Package at runtime, could anybody link me to some relevant material and/or provide some pointers to this effect?
Ideally this would be done as an MSBuild Target I think?
Thanks in Advance :)
To promote a cleaner development environment and to reduce repository
size, NuGet Package Restore installs all referenced packages before a
project is built. This widely-used feature ensures that all
dependencies are available in a project without requiring those
packages to be stored in source control (see Packages and Source
Control on how to configure your repository to exclude package
binaries).
This should help NuGet Package Restore
One of the topics
MSBuild-integrated restore in Visual Studio, for NuGet 2.6 and
earlier.
I have a VS2015 solution with 6 projects in it. I'd like to create a nuget package out of it but:
the project is for internal use only, so I don't want to publish it online
It should include the source code (is it possible?, not a strict requirement)
It should be the final artifact, can I choose a directory where to have such package?
thanks
You can publish nuget in your private host with https://github.com/themotleyfool/Klondike.
you can use nuget Package Explorer to create nuget package. https://github.com/NuGetPackageExplorer/NuGetPackageExplorer
You have multiple options. Either you can use command prompt or Nuget Package Explorer.
In order to publish you can use Nuget official server or private Nuget server. I recommend Nexus Nuget server.
For publish official one, you need to create account and obtain api key.
You can find detailed usage in here.
For including source code, there is no such a thing in official one. Because it aims ready to use artifacts.
You can add your dll, dependencies, extra files such as configs, html etc
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.