I have a nuget package that needs to determine its dependencies based on other software already installed on the machine. For example, if an old version of a tool is installed, then it should fetch a particular matching version of a library for visual studio. If a different version is installed, then it should get a different version.
Further, I think this needs to happen during build time, not during install time.
During the build, one of the pre-build steps, I think the following would happen:
Is the local software installed?
-> If no, quit with error.
Get the version number.
If version number > 3.0 install nuget package "new-API-package"
If version number <= 3.0 install nuget package "old-API package"
I was thinking I'd need to implement a custom MSBuild task to do this, and use the nuget API in order to accomplish this. Or somehow a plug-in that runs during the nuget update step in msbuild.
Is this the right way to go? Are there example packages out there that do this?
Related
Let's say I have a nuget package in my Nexus repository called MyPackage.1.0.0. I also have a solution in Visual Studio that has MyPackage.1.0.0 installed. If I make a change to my nuget package in Nexus but I don't change the version number, what happens in Visual Studio? Will Visual Studio know that the installed package is outdated? Will it automatically download the new version next time the solution is built?
No, Visual Studio will not detect this and will not use the updated package. Also, if you are using package reference nuget package management format, the package once installed gets extracted to the global packages folder. If you now try to install this package in a completely different project, nuget first looks in this global packages folder and if it finds it which it will, it will use it and not go to package sources to retrieve it again.
You can clear the local nuget caches by calling
nuget locals all -clear
from the command line.
After that, all packages will be downloaded again. This may be acceptable during development (i.e. if you need to tweak your package until it works), but clearly is not an option if others are using the same version already.
Is it possible that you can be infected with malware by installing nuget packages?
This is especially interesting when you think of Microsoft Visual Studio 2016 which will be fully dependent on Nuget.
NuGet packages can run arbitrary powershell scripts at install or deinstall time.
In addition, they add executable code (through dll they install) to your solution, that you will execute the next time you run it (after all, that's the point of installing a package, right?).
So yes, installing NuGet packages from shady sources is not much different than running executable code from said sources.
However, the same goes for any other executable code you get from the outside world.
I'm trying to figure out a) if I'm going about this in the right way and b) how to update a solution level nuget package.
The core problem is that when a package is installed at the solution level (rather than in any particular project) and you try to update it, it doesn't remove the old reference. It just adds a new package reference, and imports both version. Which typically means (what with how powershell modules work) that the earlier powershell modules override the newer ones.
So what I have to do is uninstall the package and re-install it, which grabs the newer version. Seems inefficient.
Also, I can't seem to install or uninstall a solution level package from console. I have to do it with the Manage Nuget Packages utility, which I hate to use.
Here is some background on what I'm doing, if it helps:
I've set up a system at our company of using solution level nuget packages to add custom powershell script modules to the solution, as well as some more generalized scripted solutions I've written (like deleting TFS work items or changing a project name on the file system as well as within code).
So one project might have the DataServiceUtilities package and another would have the FrontEndUtilities package.
So, how can I update these packages without it adding two references? And can solution level operations be done in the Package Manager Console, which always defaults to targeting a project?
It appears that some of this comes from bugs in the Package Manager GUI tools, and Nuget in general
The Package Manager GUI tool doesn't handle updates properly for solution level packages. But if you run Update-Package from the package manager console it will correctly uninstall/re-install the solution-level package.
As for installing from command line, if a package has only a tools folder and no dependencies you can run install from command line and it sill install in the solution and ignore the default project.
However, as of now (Nuget 2.8) Nuget has a bug in it that causes it to treat solution-level packages with dependencies on other solution-level packages as project-level packages. It's apparently been in for about a year, and they claim it will be fixed in VS 2015. You can see the bug here: https://nuget.codeplex.com/workitem/3642
What this means is you cannot currently create a solution-level package with ANY dependencies. Please note that this is legal according to the documentation. Hopefully it will be fixed next year.
*Update
Just a quick update. It appears that in VS 2015 they have deprecated (or, more accurately, removed) solution level/tools only packages. After some out outcry they also decided to re-implement them in a future version, but it may be awhile before they do so.
Progress on re-implementing the feature can be found here: https://github.com/NuGet/Home/issues/1521
Discussion on how to work around the missing feature can be found here: https://github.com/NuGet/Home/issues/522
We have a very project, and we decided to build it's core as a set of NuGet dependencies using TeamCity. And now we want to import those NuGet packages to the rest of project.
Core can be updated several times a day, and project must use only the latest version. But when we removed version specification or set it as version="", it still used the old version.
So, we want our project to use the latest libraries on each build. Can you post some recomendations?
If you can rely on just TeamCity you could take a look at the NuGet update options that TeamCity provides. They have build options such as Update packages with help of NuGet update command which you could try.
If you want something similar when you build on a developer's machine then you will need to look at some pre-build step that uses NuGet update.
Our build plans for Sitecore (.Net) websites are currently using Bamboo as the build plan master for continuous integration process. Bamboo supports building a .Net project, and that .Net project contains references to several Sitecore binaries.
I have used NuGet as an artifact repository, mostly because that seemed to be the one most people were using.
So, now that I have a nuget repository, am hosting my own feed, and have added the Nuget package to my project (I just installed the package of binaries I created), what more do I need to do?
Should the build call out something special, or am I done? I guess I'm just nervous that bamboo isn't talking directly to my repository....
In the closest analogy I have, namely a Maven/Archiva combo, the maven plan specifically references the artifacts in archiva, pulling the correct version as needed. Does NuGet do this?
Since there have been some new developments in the NuGet package restore approach, I thought I'd post an update on this topic. We're using Visual Studio 2012. I wanted to be able to run MSBuild and make sure that it would first restore NuGet packages without setting "Package restore" to true in the config. Here's what I did (inspired by https://stackoverflow.com/a/23935892/414376):
Upgraded NuGet in my solution to a version later than 2.7 (2.8.3 in my case; this seems like an optional step)
Installed NuGet.exe on the build server
Added NuGet.exe to my remote agent so that it could be run as a command from Bamboo
Added the NuGet command to my build plan with argument restore (so that the command will be nuget restore); I've placed it right before my MSV Build task.
That was all I needed to get this to work properly according to the latest guidelines.
Nuget 1.4+ supports "Package restore" which embeds a call to an MsBuild task in the project file. When the packages are not available it will automatically restore them while building the project.
I'm sure this is old news, but my packages are in \packages. No amount of "dotnet restore" would work, until I explicitly mentioned the packages folder.
dotnet restore --packages .\packages
restored them!
VS2019. just in case it's version specific.