So I have Umbraco v6 currently setup via a release download and split into a class library and a website. I need to upgrade to v7 at some point and have some question on how I should setup.
What are the pros/cons of setting up through Nuget vs Downloading source and creating project?
Devin
The pro of using nuget is that you don't have to build the project from scratch. If you have a need and/or desire to understand how umbraco is built, by all means pull down the source code, but if you just want to use umbraco, and customized it thru the hooks it provides, then the nuget packages will be easier.
I've done both (though not with the latest version), and using nuget is far easier and quicker to get going.
I have a project which works fine. This morning, I created a new TFS project and published all the code from Visual Studio 2015.
On another computer, also via VS2015, I've logged into Visual Studio Team Services to grab the same project and downloaded all the code
When I try to build, there are over 100 errors, but the cause appears to be the same. It can't find resources, and the error messages all appear to be
The type of namespace name 'some name' does not exist in '....' (are you missing an assembly reference?)
So, I expand the References and I'm missing pretty much all of them. In fact, other than the references within my own project, the rest are not there
Looking at the properties shows no path. Back on the original PC I see the path to any of the .dlls is similar too
C:\Users\Me\Documents\Visual Studio 2015\Projects\MyProj\ToT\packages\Antlr.3.5.0.2\lib\Antlr3.Runtime.dll
Is the issue that since this path doesn't match on the 'faulty' machine it can't show... Therefore what is the solution to this
I checked and noted that the files do appear to exist when I look at them in File Explorer.
All system references missing Visual Studio 2013 NuGet Async did not help
Please note, this happens with all projects in my solution, but not consitently. For example, EntityFramework is missing from all, but System is missing from my UI layer, but not from my BLL layer
Is there a way to fix this?
You need to run the update-package -reinstall command to reinstall all referenced packages.
I had the same problem, there are lots of answers by now but I will still post it here:
1.Close Visual Studio
2.Manually delete the local “packages” folder
3.Reopen the solution, and rebuild. (Nuget should restore the packages)
Source:
http://robertgreiner.com/2013/09/team-foundation-service-build-error-nuget/
Go to TOOLS -> nuget package manager -> package manager console -> and run to the console : UPDATE-PACKAGE -REINSTALL .
Clean your solution, rebuild and you are ready!
Sounds trivial but your missing references to system.xxxx could imply a problem with the .NET Framework, what version are you using and is it installed properly on your 'faulty' machine. Might be worth a re-install/repair? I'd check what versions are actually referenced too.
As for NuGet, make sure that Enable package restore is set as:
Also, I had a problem similar to this once and I had to upgrade the NuGet package manager to version 3 in Tools -> Extensions and Updates (You need to uninstall and then re-install as update won't work)
Finally if that doesn't work, check in File Explorer in the packages path and delete all packages. They should not be included in source control as this is what NuGet will download. If they are there or partially there, sometimes it will not download them.
Verify the .NET version:
Open the project properties pane and check the Target Framework:
Ensure this version of .NET is installed. OR change the target framework to a suitable version
First, go to VS--Tools--Extensions and Updates to check whether there are updates, install all updates. Then select one reference with a warning icon, check the Specific Version property, if the value is True, change it to False.
If the issue persists, check the Reference Assemblies of .Net framwork on your two computers, to see whether they are under the same location (the .Net framework is supposed to be under *C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework*).
=========================================================================
11/5: To avoid references missing, you can either check in all references to source control and reference from the source controlled ones, or use Nuget Package Manager to install packages. The previous is not recommended now, try Nuget Package Manager.
Before hitting your head against the wall with the million of Nuget 'fixes' you need to make sure you are getting ALL the DLLs that are in your Bin folder under source control. For some reason a simple "Get Latest Version" is not enough. Visual Studio will keep telling you all files are up to date but apparently this doesn't mean all the files under source control are downloaded (or it does and what happened to me is just a sassy bug). Anyways, to make sure you are truly "getting all" you need to force an update by using the "Get Specific Version" command with the "Overwrite all" option checked as VS suggests. To do this:
Go to your Bin folder in Source Control Explorer (Or w.e folder you truly want to get all)
Right Click > Advanced > Get Specific Version
Check the "Overwrite all files even if the local version matches the specified version" checkbox
Click Get
By doing this I ensured all the referenced DLLs were downloaded from TFS and for me that solved the problem. I'm using Visual Studio Enterprise 2015.
In one of our projects, I've recently converted from the (now broken) old-school MSBuild based automatic package restore to the shiny new automatic package restore in Nuget 3.0 (Visual Studio 2015 RTM default).
As the official guidance suggests, I have created a .nuget/Nuget.config file in the solution folder to stop it from uploading the binaries. No more clutter in source control. Life is good.
However, this doesn't work on other machines if the Nuget.config isn't itself included in source control, so I have done just that. Now life is bad again.
Visual Studio can't load Nuget correctly and the error log indicates that it can't open .nuget/Nuget.config read-write. Which is fair enough, since it's under TFS source control and not checked out.
So here's the question: How to have my cake and eat it, too?
Upgrade to Nuget 3.1.1, it behaves as expected and doesn't open the file read-write.
Delicious cake.
The discussion for this (closed) issue is here: https://github.com/NuGet/Home/issues/1103.
This question is about how to set up a project template to satisfy dependencies.
First, some context.
I have a MVC4/Durandal project that I'm trying to turn into a project template that distils all the goodness from a recent project, for re-use.
After creating a new project, adding all the non-standard good bits and shaking down the stub project so that it compiles and runs properly, I copied the project folder and plonked it on another computer with a freshly minted VS2013 installation, to see what broke.
The following were MIA:
Antlr.Runtime
System.Net.Http.Extensions
System.Net.Http.Primitives
System.Web.Optimization
WebActivator
WebGrease
There are a couple of issues making it less than obvious to me as to how I should proceed.
Installation of these things happened so long ago that I really couldn't say how they got onto my development workstation
In many cases package dependencies mean that installing one NuGET package will implicitly satisfy other dependencies
I don't know how set up a project template so that it causes NuGET package(s) to be installed
A bit of guidance would be appreciated, not to mention advice on best practice.
Update
It appears there is direct NuGet support for project templates, I'm still reading about it here and also here.
Since allowing NuGet to automatically resolve dependencies is a good way to ensure compatible versions are installed in the right order, the remaining question is looking at the missing assemblies, how can I determine the most dependent package(s)?
It seems that omitting the packages folder produces a slim template, and the projects produced therefrom install the missing files as soon as you start a build. That's good enough for me.
I would simply start with a blank ASP.NET 4.5 MVC project. The most basic dependencies should be satisfied then. NuGet has basic packages for Mvc and other packages you may need. NuGet packages are designed to self contain the missing assemblies they need. They'll get published in IIS when you deploy so you don't install anything on the server.
Okay, so help me understand something here. I've got a new MVC solution and want to use NuGet to keep Modernizr up to date.
The problem is, NuGet puts the Modernizr scripts under ~/Scripts. This won't work--we've decided to put our JS in ~/js.
How do I modify the configuration of this package to tell NuGet that the Modernizr package should go in ~/Scripts or ~/Scripts/global instead?
I don't think you can do this - I don't think this is functionality of NuGet, but rather the location of the scripts inside the NuGet package. This could vary from one package to another :-(
This is currently not a feature of NuGet, but it was mentioned in discussion on the a NuGet forums including members of the NuGet team. I don't see any work item that has officially been created for this yet, unfortunately. I performed a quick search of the NuGet issues list for the word "location" and didn't see one out there for this. You might want to request it as a feature.