I currently have a Nuget Package (MediatR) at the Solution Level (via Manage Nuget Packages for Solution). I have a project that needs that package. Do I need to install it also at the Project level? When do you manage them at the Solution level vs. Project level?
The "Manage NuGet Packages for Solution" shows an aggregate of all the projects. When installing a package, you must still select which projects to install them in.
It provides a convenient location to automatically update or install packages across multiple projects.
When you manage packages for a single project you get a project-only view.
How packages are installed is no different between the two options.
Related
I am working with Visual Studio 2017. I started from; Basic Node.js Express 4 Application.
I have a private Nuget in VSTS which has a .Net tool I would now like to use in the Node.js project (to perform some domain specific build-like tasks).
Is it possible to add a Nuget reference into a Node.js project (just to download the tool)?
I've seen that VSTS provides npm, but this would seem to be incompatible with my existing Nuget packages.
Is it possible to add a Nuget reference into a Node.js project (just to download the tool)?
I am afraid you can not do that at this moment.
Because Nuget does not currently support the node.js project even if you just download the tool. When you use nuget on the node.js project, we always get the error 'Project "Default" is not found.'. npm is the right solution for package management for node.js project.
See similar issues on GitHub for some more details:
Cannot install packages in Node.js project - Project "Default" is not found
Nuget package manager cannot 'see' Node.JS projects
Hope this helps.
I have a general framework project which is referenced by many solutions. Whenever there is an update to a component which I would like to upgrade to, I normally right-click on the solution > Manage NuGet packages for solution > upgrade component for all projects. The problem is that for all other solutions, their projects (except from the common referenced one) is not updated to the latest one. If I try to do the same, it will not let me click on 'Update' to update all projects, as it detects that one project is already using the latest version. I have some other 4 or 5 projects in most solutions, and it is quite a headache to update them manually. Any ideas about it? I am using the latest version of NuGet and VS2012.
Right-click the outdated project in the solution and select Manage NuGet Packages from the context menu. Your Manage NuGet Packages window will now only affect the scope of that one project you selected and you should be able to perform an update to the project directly. Repeat for all your other packages.
It seems whenever a package is installed through nuget TFS doesn't pick up the dlls files for that pacakge and it's becoming a pain working on the project with multiple developers when new DLLs are being added and old ones updated.?
The 'packages' folder is being checked in.
I've searched google and seem to find people with the same problem but no solution.
Is there a solution to this problem?
I would suggest not checking in the packages folder, and instead enable Package Restore.
Check out TFS NuGetter, an integrated NuGet solution into TFS build process.
I have an application that uses unity and the logging application block. I recent checked-out the application from the repository after these assemblies were added and I got a few error. Eventually I installed enterprise library on my pc and it's now working. My question is do I have to install Enterprise Library on every pc that uses it? If so is there a workaround?
The issue is that your project which references the Enterprise Library assemblies is referencing where the Enterprise Library is installed - probably the Program Files directory. Instead of referencing them there, you could add the Enterprise Library references via Nuget, then check the packages into your source control as part of the project. That way you have the project and its dependencies all in one place, and it shouldn't be necessary to install the Enterprise Library everywhere.
Hi I have no idea how I fixed it. I think that my problem was that I was using the dlls and the config exe's from the enterprise library labs. I should have installed ent lib 5 on my pc. I had the same problem in my ci server so I deleted my project from the repository and added it again as my local was working.
So in a nut shell. Install entlib 5 and don't use the dlls from the labs in your project. I don't need to install ent lib in my deployment all I need is to copy the dlls.
We're building a set of several services, each service has it's own solution with associated projects. Many of these services rely on the same NuGet packages.
All the solutions have "Package Restore" enabled.
Some of the solutions refer to assemblies owned by other solutions, this is one obvious reason why we need all the solutions to refer to exactly the same versions of different NuGet Packages.
All of the services need to work together to achieve an end result. They're packaged and installed as part of a single product, which is another reason we'd like everything to be running off the same versions of the NuGet Packages
We're having trouble keeping package versions consistent between Solutions.
Currently we're manually checking and updating package versions, we're also getting occasional compilation errors because projects in one solution end up referring to different versions of the same package.
Is there a recommended way of doing this (hopefully an automatic process)?
Would we be better off without Package Restore?
Anyone have any general advice on the subject?
Thanks
Update: I created an issue for this on the NugGet project http://nuget.codeplex.com/workitem/2623
To solve this:
Create your own private NuGet server (see 1 and 2) that hosts the correct versions of the packages you use.
Configure each build system to use that server and auto update to the latest version.
Although this requires a server, it not only ensures everyone has the correct version but speeds up the downloads for build servers as well.
You could configure your TFS builds to update all NuGet packages in the solution to their latest versions using the nuget update command.
The latest versions could be from nuget.org, a local NuGet server or even a network share. Use the source parameter to define the sources you want to update from.
You can perform the build configuration via MsBuild proj files or via a TFS template.