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.
Related
I have the situation where our code base is like so:
/Gui/
/Product1/
/Calc engine/
/Core/
/Product2/
All of these projects are loaded into a Global solution file in Visual Studio.
I want to extract Core to it's own repo and allow different branches of this repo to load different versions of it. I cannot just use references to the binaries as engineers want to be able to debug the core code when running the Products so I have to be able to bring the entire Core codebase in.
Originally, I intended to use git submodules but I am investigating whether Nuget might be a better solution. I have removed /Core/ to it's own repo and created a Nuget package of the Core directory (it contains about 20 different C# projects).
Is there a way I can input this Nuget package into the Global Solution? It would need to put the code into the same directory as it used to rather than a package director.
Is there a way I can input this Nuget package into the Global Solution? It would need to put the code into the same directory as it used to rather than a package director.
You can change the Package Management to "Pakcage.config" in Options\Nuget Package Manager. The package will be stored in solution directory.
and right-click the solution in solution explorer then click "Manage Nuget Packages for Solution"
I am trying to install knockoutjs and typescript in a .net core app via Nuget.
It shows in Packages but doesn't install anything in a scripts folder as has previously in asp.net.
What am I missing?
TL;DR ASP.NET Core no longer works in that way (packages copying javascript/css content into your project). You need to adapt your workflow.
.NET Core projects only work in SDK-style projects, and SDK style projects only use NuGet's PackageReference, not packages.config. The docs on migrating from packages.config to PackageReference list one package compatibility issue as not supporting the content folder, which is how in packages.config those assets are copied into your project on package install.
I can't find a doc listing recommendations for ASP.NET Core apps, but my understanding is you can either use LibMan, or use NPM, which is in line with basically the rest of the web development industry outside of .NET has been doing. If you use the new project templates to create a new ASP.NET Core Angular or ASP.NET Core React app, you'll see they create a ClientApp folder that uses npm and all the official react/angular CLI tools. The MVC template has copies of jQuery and bootstrap, without an obvious way how to update them.
might be some unsync, remove the packages folder from the solution and restore the packages again. It will fix the issue. Also check the output window, that will show the list of errors.
It shows in Packages but doesn't install anything in a scripts folder
as has previously in asp.net.
First, I agree with zivkan. It is a feature of PackageReference Nuget Management format.
VS has two format to manage nuget packages: Packages.config and PackageReference.
Since new sdk format projects(Net Core and Net Standard) only use PackageReference to manage nuget packages,it will be very different from the effect reflected by the packages.config package management format.
When you use Content files from the nuget packages with PackageReference, it will lose files from the Scripts folder.
Just as this document said, it has such compatibility issues.
Actually, you can enter C:\Users\xxxx\.nuget\packages\knockoutjs\3.5.1 and find there is a folder called Content, Nuget will copy the content of that folder into your project when you install this nuget package.
But Content folder can be recognized by Packages.config format, and as far as I know, ContentFiles folder is used in PackageReference to add the content into your project. So in your situation, the nuget package should include ContentFiles folder at the same time. See this official document.
But the knockoutjs nuget package does not have contentfiles folder. That is why net framework projects with packages.config has the content files while new sdk projects does not have it.
And this behavior change can only be effective when you create the nuget package, so you ca n’t make any kind of change, you can only contact the author of the package to make this modification, and let him add this function as soon as possible to apply to the new SDK format project.
Suggestion
So So for now, you can try these:
1) you can either manually Add the content file from C:\Users\xxxx\.nuget\packages\knockoutjs\xxxx\Content to the project by Adding Existing Items.
2) roll back to use Net Framework projects with packages.config.
3) contact with the author on this link.
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.
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.
What is the best way to share dll libraries between projects, through VS2010? For example we have made a generic helper library that is useful in everything. However, we need more than one library to be included (which is a separate project in TFS) so branching is not suitable.
We are using Team Foundation Server 2010 for source control. Is there maybe a simple way to integrate these libraries into a new project, so the new project can come "fully buffed" very fast?
What we do now is go through each project, build them, store the dll files, add a new project then throw them in the Bin folder, which is tedious work when you have many libraries.
Have you thought about hosting your own NuGet feed? I use a pre-build script for NuGet for each of my projects which downloads packages for me before the project is built, and, I assume, keeps them up to date.
I don't think that there is some TFS-based solution for sharing binaries between projects. However you can use NuGet to do it for you. Create nuget package for each project (you can create TFS build definition to do it automatically) and publish it to network share. Than add this share as NuGet feed.