For example if I create new ASP MVC 5 project with Identity authentication and Internet template.
Is it possible to somehow extract installed nuget packages from it so I can install them in another project so I don't have to check one by one?
Why I need this.
I want to create empty project and I want to add dll references same like in internet template.
The assemblies are in the packages folder at solution root and the packages.config lists the installed NuGet packages.
But I'd rather use NuGet and let the tool try to determine the necessary dependencies. It may also automatically add necessary settings to your web.config.
Related
I am wondering if anyone is aware of how to properly include an Nuget package in my application. Installing it - adds the references automatically in Solution Explorer. In addition it create/display a file called package.config - and it looks like it wants to be added in my project. It is shown in Solution Explorer but appears in my root folder with a little + sign next to it - and allows me to Check In Pending Changes / add it. Am I supposed to add it to my project?
I basically don't want to screw up anything.
Yes the packages.config file is required. This file holds the packages you reference and the versions youre using. NuGet uses this file to restore your packages in a TFS build of on the machine of another developer.
Here is some more information on NuGet dependency resolution
Note that you should not checkin the packages folder in your solution folder. NuGet will restore packages to this folder using the packages.config file
UPDATE: the <PackageReference> format was introduced a while back. It can be used with both the old and new .csproj formats. One of the benifits is that the paths to the packages are no longer in your project file so you will get a lot less updates/merge conflicts when updating NuGet packages. See this page for more information: https://learn.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files
Yes, it's usually checked in as part of your solution. Source control and all that.
I recently upgraded an old ASP.Net MVC3 project that was storing all our COTS (commercial off-the-shelf) .DLL files in source control to use NuGet Restore Packages instead.
Now whenever someone gets the source afresh from TFS (Team Foundation Server), the references I updated to NuGet Packages all have the warning icon on them. Neither building nor cleaning and rebuilding fix the references.
If I click any NuGet reference in a project, the references all appear to update. The warning icons disappear and the references seem to be fine. The project builds without sissue.
This has to be done for each project in the solution, though once done once it is fine and doesn't reoccur. But this is slowing down new employees and is cumbersome.
Does anyone know of something I might have missed?
The .ddl files are for packages like MVC, StructureMap, Log4Net ect
I have searched (via Google) and the only related question is one showing NuGet packages having a different icon.
You can use the Restore Nuget Packages option from the Solution Explorer by right clicking on the solution:
You can also configure Nuget Restore to run on build from the Nuget Manager Settings windows:
I am hoping for a little advice.
I am checking in my project (asp.net mvc 5) to source control (TFS) and when a fellow colleague tries to pull it down, most of the references are not being added to his project.
How can I insure that all the references to get added?
Generally, best practice is to use NuGet.
At least for packages that are not internal you must use NuGet. Let's say for EF, BundleTransformer & so on.
For that you must enable NuGet package restore and fetch all you need from NuGet Feed. More here: http://docs.nuget.org/consume/package-restore/msbuild-integrated
For internal dll's you can create an internal NuGet feed: https://docs.nuget.org/create/hosting-your-own-nuget-feeds and get packages from there or copy them in your project.
Don't forget to include the files into project if you copy them "by hand" and i think this is a good start.
There are other best practices like not referencing anything from GAC anymore and move all the dll's/dependencies/referencing to NuGet or to create a raw "Library/Vendor" folder in your project and copy all the necessary DLLs there (problem here is that you check in all the dll's to source control), but you will be sure that everyone will get exact the same version/reference & so on because the files are stored there (physically).
What are the references to?
There are a few different things to bear in mind:
References to other projects within the solution should just work, if they don't make sure that the referred to projects are building
References to things like nunit are best managed through nuget so you add them using it and then when your colleague checks out he only has to restore the nuget packages and it all works
References to things that aren't in nuget, you can either put them into nuget or I prefer to create a lib folder and put them into there. To get them actually checked in as dll's are normally excluded, add the folder and dll's and then use the source control explorer to find the folder, right click and choose "Add items to folder" and use that to add the dll's and files that you need. If you then reference the dll's in the lib folder they will be checked out and should resolve correctly for the other user.
Just installed the latest Umbraco (7.2.1) package via NuGet. My development environment is as follows:
Umbraco is installed installed on IIS8 as shown below and is all up and running.
My Visual studio project is set up as shown below (For the sake of clarity, any folder/file excluded from project is not in included in my source control.
The content folder houses all scripts, images & css
On build - bin, config, content, masterpages, usercontrols, Views, xslt, default.aspx, Global.asax & the transformed Web.config are copied to the IIS instance (I don't like running Umbraco in the same place as my project, it just seems messy.)
Is this an appropriate way of developing for Umbraco? Am I missing anything, my biggest concern is whether or not I should include the umbraco & umbraco_client folders in version control and in the post build action. Any suggestions would be great.
There is some debate over what should and shouldn't be in your repository and ultimately it comes down to personal preference. I used to only add custom files and files that I changed from the Umbraco install such as the config files however since the introduction of the Nuget package I do put all but the binaries into source control because when I upgrade via Nuget later on I can easily see changes and merge customisations back in.
It saves a lot of hassle running Umbraco directly (IMO) especially if you make any changes via the UI and if you're not running it directly then there is little point really in using the Nuget package because you will end up with a bunch of unused files in your project. In your situation you might as well keep your project clean and do a manual install into the location IIS is using for the site and only keep files in your project that you have created.
This is only my opinion so take from it what you wish but hopefully it is of some help.
Simon
Our projects in TFS are organized like this:
$\DefaultCollection\ProjectName\Source <-- source code goes here
$\DefaultCollection\ProjectName\SharedAssemblies <-- 3rd party binaries go here
Now that NuGet is on the scene, is there any reason to change our approach and use NuGet's packages folder for dlls that come from NuGet-aware projects? I'm leaning against this because
1) it creates two places one must look for dependencies
2) it leaves us open to one developer updating a package and breaking some dependency
That said, if anyone can report a good reason to start using NuGet in a TFS environment, I will happily present your ideas to my team as if they were my own (joke).
Nuget 1.6 now allows for packages not present to be downloaded dynamically upon build. So you can now check in to source control without the .dlls, but the build itself will pull the correct package.
http://docs.nuget.org/docs/workflows/using-nuget-without-committing-packages