We have a set of functionality that was previously in a regular dll file, but that is now in a Nuget package. Naturally, we want to pull it using Nuget instead of having to download and update the dll:s manually. All projects are handled in VS 2013, so we have access to it through the package manager.
Now, we need to go over all the projects in the source tree to update the reference to be a nuget reference instead of the old dll reference.
You can do this on a solution level using the package manager, but since there are several dozens of solutions and well over a hundred projects I'd rather not do it manually.
Is there a way to automate this? That is, to iterate through the source tree, find every .sln file and update the references in its underlying project files?
You can probably do it by writing a small C# program. Install NuGet.Core and NuGet.VisualStudio package to the program to use functions in nuget.core.dll and nuget.visualstudio.dll, plus some DTE functions.
Related
I have a VS (2015) project. I see there's a "References" section in the Solution Explorer view of my project that includes things like System.Core. I'm assuming these are .dlls that have been added to the project?
I can also right-click on the project file (again in the Solution Explorer) and select the option to "Manage NuGet Packages". I know the NuGet allows me to add external code to my project (e.g. external .dlls and associated files).
What's the difference between adding a reference to my project and adding a .nupkg to my project? Is it just that .nupkg can contain a whole bunch of other things aside from a .dll (e.g. documentation)? Why would I use one or the other?
What's the difference between adding a reference to my project and
adding a .nupkg to my project?
NuGet essentially does not differ from manually adding references, and ultimately adds references to the project. It is a tool that automatically adds assemblies to us and manages them, effectively improving the efficiency of our development projects.
For more details, you can check the document about nuget:
Put simply, a NuGet package is a single ZIP file with the .nupkg extension that contains compiled code (DLLs), other files related to that code, and a descriptive manifest that includes information like the package's version number. Developers with code to share create packages and publish them to a public or private host. Package consumers obtain those packages from suitable hosts, add them to their projects, and then call a package's functionality in their project code. NuGet itself then handles all of the intermediate details.
Because NuGet supports private hosts alongside the public nuget.org host, you can use NuGet packages to share code that's exclusive to an organization or a work group. You can also use NuGet packages as a convenient way to factor your own code for use in nothing but your own projects. In short, a NuGet package is a shareable unit of code, but does not require nor imply any particular means of sharing.
.
Is it just that .nupkg can contain a whole bunch of other things aside
from a .dll (e.g. documentation)?
Yes, NuGet package could include specify files in the package.
Why would I use one or the other?
Nuget provides several additional benefits:
it automatically configures your projects by adding references to the
necessary assemblies, creating and adding project files (e.g.
configuration), etc.
it provides package updates
it does all of this very conveniently
I'm sure that once you use it, you'll realize that it has many benefits.
Check Why use NuGet for more details.
Hope this helps.
I've added Autofac library using NuGet and I see it in my references as shown below.
But when I check the properties [F4] of Autofac by clicking on it, it shows empty property box in Visual Studio.
Also, I don't see Autofac folder under packages folder.
I see only Package reference in .csproj file. Then how does it locates the DLL? Where is the actual DLL? I see it's automatically coming inside BIN. How does it come?
Main Issue: Locally I'm able to build the solution but same solution fails on TFS build agents. It's unable to find the NuGet reference. So where can I find DLL references? or how to push it to TFS?
As #magicandre1981 already explained, with PackageReference style package referencing (as apposed to package.config-style, also see this for more background on the differences, in case you didn't know), the packages are not located in a per-solution packages-folder, but in a central one (by default %USERPROFILE%\.nuget\packages). Albeit you can easily change the location using the NUGET_PACKAGES environment variable (which also works as a TFS Build variable, because they are provided as environment variables to build steps).
Furthermore, inside Visual Studio you see no path, because the actual path to the DLL is determined at build time. You can see part of that path in your <project-dir>\obj\project.assets.json file (which is generated during the restore target/operation), but the full path you will only see in the MSBuild logs (for example when actually calling the csc.exe executable/C# compiler or during ResolveAssembyReferences-task).
Note that for .NET Core, i.e. "SDK style" projects, the path is actually shown in properties (as are the actual DLLs in a node underneath the "package" node.
One can only assume that the integration of PackageReference in "old" projects is not fully done yet (if ever).
For comparison a PackageReference in an "old" / non-SDK-style project:
You use the new Package Reference where the NuGet files get get stored into a cache:
Solution-local packages folders are no longer used – Packages are now
resolved against the user’s cache at %userdata%\.nuget, rather than
a solution specific packages folder. This makes PackageReference
perform faster and consume less disk space by using a shared folder of
packages on your workstation.
Assume you are using TFS 2015, the NuGet Restore task name should be NuGet Installer which under Package when you add tasks.
So, if you have installed Nuget in the build machine, then you can use the task directly.
You can also custom nuget.exe for TFS 2015 build -- Just specify the Path to NuGet.exe
You can refer to Mummy's blog- Custom nuget.exe for TFS 2015 build for details.
Add a NuGet Restore task to your build so that the packages are restored.
Cross platform Xamarin Forms project in Visual Studio and Visual Studio for Mac. The project references Akavache. Akavache has a dependency of akavache.sqlite3. I have made a custom change to a DLL in the akavache.sqlite3 repo and built the DLL locally, and would prefer not to have to switch the whole Akavache package tree over to a custom build for all the Akavache dlls and dependencies. So essentially...would like to continue referencing the NuGet package like normal but "substitute" one DLL on the fly. Or something equivalent like that!
But it needs to be portable too. At first I used a post build copy command to overwrite the "standard" dll that gets put in the TargetDir. That works in the sense that it copies to TargetDir, but for Android copying the DLL into the TargetDir does no good. The DLL is already incorporated into the APK in the TargetDir instead. So it would need to happen some other way. Same basic issue if you used MSBuild instead of a post build command line.
Any thoughts?
FWIW, my current workaround is to copy the DLL over top of the cached NuGet package location. But the problem with this approach is anytime the cache would get cleared/updated it needs to be reapplied. That's also not an obvious step to do, or easily automated, when another developer want to get set up on their machine.
Any .nupkg files are just ZIP files with some metadata, so you can change at the contents. The NuGet Package Explorer should make it a little easier to view the contents.
The NuGet Gallery (e.g. https://www.nuget.org/) has a "Download" link on the left hand side, otherwise just install the package into an empty project and then take a peek.
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.
I have a solution with two projects:
.NET application
WiX setup project.
I know, that it is possible to refer to project output in WiX source ($(var.WindowsFormsApplication1.TargetFileName)).
Now I've added a NuGet package reference to my .NET application. So, I want to bring NuGet package content into my setup.
Is there any way to do this instead of adding files manually?
I don't believe there is any linkage. I know what nuget is but I haven't used it much because it's more about brining your .NET dependencies into scope then software distribution. Depending on how nuget lays the files down you might be able to do something like $(var.SomeProject.TargetDir)nuget_fetched.dll.
This is assuming that SomeProject uses nuget in such a way that the references are copied locally and available in the Outdir of the project.
I wrote a Resharper live template to cut out a lot of the typing involved in adding the files, but essentially I've just added the files manually. Creating a Wix component per nuget package keep things neat.