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.
Related
Is there a way via NuGet.exe or within Visual Studio 2022, natively or via the Package Management Console, to only re-download all packages for a given solution and/or project without re-installing them?
This may sound odd, but we occasionally run into a scenario where our packages path mappings get wonky, and we correct the paths in the .csproj files and whatnot, but Visual Studio believes that the packages are installed due to their listing in the packages.config, yet in our mapped packages path, they are not downloaded.
We do not want to reinstall, as for many projects, that uninstalls and reinstalls the packages, causing unwanted changes to the code, as default templates and other things get changed.
We simply want to say "Hey Visual Studio, you see all these packages that you think are downloaded and installed in C:\NuGetPackages...? Yeah, they are not there. Please just download them. Don't reinstall them please."
Any way to do this in 2022 yet?
Only re-download all packages … without re-installing them.
If you only downloading the NuGet packages, they are just .nupkg files. If you download and install them, you will get some files like .dll files, .nupkg files, .xml files and so on. If you download and install them, then reference them in your project(such as installing them into your project by using VS or configuring in packages.config file), your project will connect to these NuGet packages.
The third situation obviously doesn’t meet your requirements, so just focus on the first and the second situation. For only downloading the NuGet packages, I don’t find many good methods. Maybe manually or writing some scripts to download them from nuget.org? But you want to use VS or NuGet.exe, so not possible I think.
For downloading and installing NuGet packages, or installing them to a specific folder for preparation. You may try and modify following command(nuget.exe, install command):
nuget install <packageID> -version X.XX.X -OutputDirectory c:\XXXX
BTW, based on my check, there’s no options in VS 2022 to only downloading the NuGet packages without installing them. And for above situations, perhaps some third-party tools will work.
I was wondering about the right way to do this. For example, let's say you have a number of projects (part of a solution) that uses boost. Let's say you want to put the boost package in the solution so the entire thing is more portable.
How do you do that? Do you install boost in a directory within the solution? Can you reference it using relative directories, so it isn't portable?
Under Linux, for completeness, one could just store a tarball in the code under control, but it was left to the developer to bring it out and install it. I'm wondering how this is done (best practices) under visual studio.
[NOTE: I understand this might make the solution large, but the benefit would be a development environment that would run immediately without a bunch of package installs for each development system accessing the code.
In this case you could use the nuget package manager in visual studio to add the nuget boost package to your solution then boost will be available to the projects that need it. You can then enable package restore so that whenever the solution is built if the boost files are missing from the solution then nuget will restore them on build.
If you haven't already you will need to install the nuget package manager plugin for visual studio.
Where the package isn't available on nuget there are a number of options; you can build the package and then reference the assembly that's been built - you just store assemblies you need in a references directory. If your using source control software Svn or tfs possibly git ( I don't know) then you can store these in source control and then include them in the target solution via links. The final option I can think of is you can build the package into a nuget package and then store the result in your own private nuget store visual studio allows for this. Which solution works for you will depend on the size of the project, development team and the source control software you use.
Is it possible to manually install, or perform an offline installation of, SpecFlow? I can install the VS plugin for SpecFlow, but it seems the only way to install the SpecFlow dll is online through NuGet.
My team is behind a firewall without internet access so I am curious to know if this is possible.
Any info/suggestions is greatly appreciated.
If you have the VS extrnsion you don't need the NuGet package. However using the Nuget package and adding it your source tree would ensure that specflow tests can be run even on machines without VS such as build servers, and other developers machines that do not have the SpecFlow extension installed.
Also, you can quite easily add a new NuGet source which can be configured to any folder, either locally or on your internal network. So if you can the SpecFlow extension msi into the office, you can also download the NuGet and make it available.
We sell source codes for some of our apps and try to keep dependencies to a minimum. Currently, when customer gets the source codes, he can open a solution and start coding right away, the only prerequisite is to have VS 2010 or more.
We considering using Nuget. Is it safe to manage project dependencies with Nuget even if most of our customers don't have it installed?
I can see that Nuget saves all needed libraries in the "packages" folder and adds references to them, so it appears pretty safe to me. I've done some testing: uninstalled Nuget and tried to build the project, all worked fine, but I only have VS2012.
I couldn't find any accurate info on this topic nether in official documentation, no on other web-sites. So, does anyone know for sure, is it required to have Nuget installed in Visual Studio to work with nuget-enabled projects?
If it is your intention to redistribute those packages as binaries bundled with your sources, then NuGet is not required. However, if you don't plan to redistribute those packages, then the customer must have NuGet installed.
<opinion>
I don't think it's unreasonable to make NuGet a requirement for the use of your sources. It's easily installed into VS2010 and present by default in VS2012. Microsoft is increasingly relying on it as a core part of the tool chain. Resistance is futile. :) </opinion>
I've added some libraries to a VS 2010 solution using Nuget (RestSharp, Twilio, etc.). When I pull the same solution down to a new PC from TFS and try to build it, all the references to those assemblies are broken (error "namespace cannot be found..."). Is it necessary for each developer who works on this VS solution for the first time to independently install the same Nuget packages on their PCs?
Thanks,
Jim
As Andrew already have said it's all about the packages' location.
Either you have to check in the entire packages folder with all the packages, or each developer have to install the packages after first checking out. But there is a better way to do this, namely to use NuGet Package Restore - which will automatically install all missing packages when the project is built.
If you use package restore, you only need to check in the repositories.config into your VCS. With TFS you can cloak the entire packages folder except for the repositories.config, so that TFS doesn't annoy with pending checkins for new packages.
Also see this answer for guidance on how to use TFS + NuGet.
No, but you need to be sure the assemblies are all included in the same relative path so Visual Studio can find them. You can include the solution's nuget packages directories, which is where I think it stores a copy of the libraries to be referenced by the project(s).
Incidentally, including said diretories may be effectively the same as "installing the packages". If you include all the files that NuGet uses in its management of packages, NuGet will behave the same as if you had installed them. But you don't need to do the actual package install via NuGet for it to work... or even have NuGet installed in Visual Studio in the first place. It's just a matter of the proper files being where the Visual Studio project files expect them to be.