Nuget puts the package in my root folder(in my case my trunk folder). I am wondering is there a way to let VS 2010 know about this folder? I am using ankh svn to do my commuting so it would be really nice to have it in my solution so when I add a reference I can commit it from VS 2010 and not have to go to my trunk and manually do it.
Can this be done?
You may be interested in reading this NuGet doc:
Using NuGet without committing packages to source control
The easiest way to do this currently is by using the Working Copy Explorer (View -> Working Copy Explorer). From here you can browse your solution folder, and add the reference.
I added the idea to enhance this to the AnkhSVN feedback forum, please go vote :-)
You should consider 'don't commit packages workflow'. It is much more mature solution:
http://blog.davidebbo.com/2011/08/easy-way-to-set-up-nuget-to-restore.html
You can add the packages directory as a web project. I use TFS so the only issue is after adding a package I need to include these files to the source control but at least there visible...
Related
Nuget seems to stubbornly ignore the flag inside .nuget/nuget.config file. It's important to note that no actual packages are being added to the source control, just the annoying repositories.config.
I can confirm that our settings are correct, and if I remove the flag from the .nuget folder, then also packages start being added.
The only reference to my problem I could find here - https://github.com/Haacked/NuGet/pull/2. But it seems that this pull request is made in a clone repository.
For reference we are using VS 2013 with TFS 2013 with latest updates. We use server workspaces and I couldn't make .tfignore file work probably due to that.
Has anyone experienced that problem and if so, how did you overcome with it?
we use a .tfignore file for this. Here's a blog on how to do it:
http://blog.appliedis.com/2014/11/06/excluding-files-from-team-foundation-version-control-using-tfignore-files/
I am trying to use NuGet Package Restore with VS2010 + Visual Sourcesafe. It is working partially for me.
Where this is coming from: NuGet not getting missing packages
My Solution2 has asp.net website[Project1 in above image] that has another nuget package installed. Now another developer opens the Solution2 via VS2010, the automatic restore works for Library projects in Solution1. It gets all missing packages for Library projects that is referenced in this Solution2 and I see them in Solution1/packages folder.
But for Website it says external dlls i.e. pacakages missing. The issue I think is because website doesn't have a .csproj file and so it doesn't know things needs to be restored.(http://nuget.codeplex.com/workitem/1663)
Making it work partially:
Added packages/repositories.config to website solution (What is a solution folder in visual studio)
Another developer goes to VSS and get that packages folder manually. Now when he builds the solution, the Package Manager Console prompts for restore i.e. has "Restore" button. On clicking it will bring the AjaxControlToolkit.
Questions:
- Is the above approach the only and best available for Websites?
When the developer clicks "Restore" button it brings packages for Library as well to Solution1/packages along with packages for nuget. Any reason why would it do that?
Any ideas on above issues?
Per you link, nuget doesn't support websites. If you really need to use Nuget, and let's face it, everyone does, then in my opinion the best approach is to switch your website over to a web application, at which point visual studio will create a csproj file for you, detailing the nuget packages that are contained in the project.
HTH
For adding Solution level "packages" folder with repositories.config to VS Solution Explorer, I created a Solution folder and added repositories.config.
That created packages folder in the SourceSafe when I checked-in the solution.
I also found someone pointing the same thing here.
Update: I think the newer nuget is restoring the packages. But one other trick for nuget to add the dll to the bin folder it to check-in the .refresh files for AjaxControlToolkit and its dependent packages.
How can I make a solution in visual studio so that the .dll dependencies that reside in some other directory totally different from where the solution itself is affected by "get latest".
What I've tried is creating a Dependencies solution folder within the solution itself and added the dlls to it, that way they belong to the solution even though they don't belong to the directory structure of the solution.
So for example the .sln file is in:
D:\tfs\repository\main\SolutionA\solution.sln
and the dlls are in:
d:\tfs\repository\main\SolutionX\Dependencies\Binaries
What I really want to achieve is to have a foolproof way to build the solution, including the following scenario:
1- Have a brand new installation of windows, visual studio, etc.
2- open visual studio
3- find solution.sln on TFS, double click on it so that visual studio gets every project and files in the solution, and opens the solution
4- successfully build
What happens when I try the Dependencies solution folder approach and repeat the scenario above, it will get all the projects within the solution, opens it, but the dependencies solution contents won't be pulled from TFS (although Visual Studio shows them on Solution explorer), which I think is flawed.
Some suggestions that don't involve creating pre/post build scripts are appreciated.
When you attempt to open a solution for the first time using the TFS Source Control Explorer, you may find that not all of your dependencies will be retrieved - the squiggly line may be highlighting some of your missing References.
One work around is to...
SOLUTION SETUP
Checkout all of your source code from TFS (i.e. Main and all of the sub-directories)
Open your solution in Visual Studio (i.e. MyApplication.sln)
In the solution explorer, create a New Solution Folder called ThirdPartyDll, and then add the appropriate assembly references (i.e. Assembly1.dll, Assembly2.dll,...)
Check-in your solution to TFS
SAMPLE FILE STRUCTURE
Main
MyApplication.sln
Source
MyProjectA
MyProjectA.csproj
MyProjectB
MyProjectB.csproj
Dependencies
Assembly1.dll
Assembly2.dll
You've run into a limitation of the "Open from Source Control" functionality. If you added the solution to source control from Visual Studio you should have seen the following message:
"The project that you are attempting to add to source control may cause other source control users to have difficulty opening this solution or getting newer versions of it. To avoid this problem, add the project from a location below the binding root of the other source controlled projects in the solution."
Open from Source Control will create a workspace mapping for the solutions root directory (D:\tfs\repository\main\SolutionA) but not a separate one for the SolutionX folder which is a peer to SolutionA. On the "new" machine you will need to manually create a workspace mapping to d:\tfs\repository\main in order to get both the SolutionA and SolutionX folder.
Create a solution folder and add the dependencies to it, that way when VS gets latest for the solution it will download these files. A bit brittle as people will need to maintain that folder but it works.
Alternatively create a nuget package and use restore packages on build. It will require a couple of extra steps when you create a new developer box (your nuget package repo will need to be added) but it will work for all projects going forward and is less brittle than the solution folder method.
With newer versions of NuGet it is possible to configure a project to automatically restore NuGet packages so that the packages folder doesn't need to be included in the source code repository. Good.
However, this command adds a new .nuget folder and there is a binary there, NuGet.exe. This can also be re-created automatically by Visual Studio and so it doesn't feel correct to add that to version control. However, without this folder Visual Studio won't even load the solution properly.
How do you people deal with this? Add .nuget to source control? Run some command line script before opening the solution?
This post is old, you should not be using solution level NuGet package restore anymore. As of version 2.7+ there is an option in the NuGet setup to automatically restore packages on build.
So the .nuget folder can be deleted and the option removed from your projects.
http://docs.nuget.org/docs/reference/package-restore
UPDATE: With the release of NuGet 4.x and .NET Standard 2.0, when you use the new csproj format you can now use package references, ironically reintroducing the dependency on msbuild to restore packages, but now packages are a first class citizen of msbuild. The link above also makes mention of the PackageReference, but the following announcement details it better:
https://blog.nuget.org/20170316/NuGet-now-fully-integrated-into-MSBuild.html
And the NuGet 4.x RTM announcement, which ironically isn't as useful:
https://blog.nuget.org/20170308/Announcing-NuGet-4.0-RTM.html
UPDATE 2: Apparently with VS2017 you can even use package references with classic csproj projects, but they aren't backwards compatible anymore, and there have been some problems with restoring package sub-dependencies. I'm sure that will all be resolved.
#Richard Szalay's answer is right - you don't need to commit nuget.exe. If for some reasons Visual Studio does not automatically download the nuget.exe, make sure you have the following set to true in the nuget.targets file:
<!-- Download NuGet.exe if it does not already exist -->
<DownloadNuGetExe Condition=" '$(DownloadNuGetExe)' == '' ">true</DownloadNuGetExe>
Close the VS solution, reopen it and build it. Visual Studio should download nuget.exe automatically now.
According to this thread, the .nuget folder should be version controlled.
You need to commit .nuget\nuget.targets, but not nuget.exe. The targets will download the exe if it doesn't exist, as long as you change DownloadNuGetExe to true in nuget.targets
Although I usually don't like the idea of adding exe's to source control, I would suggest that source control should contain anything that is required in order to open, build and execute the project.
In this case it sounds like the .nuget folder is a required dependency. Therefore it ought to be under source control.
The only question left, that you need to research, is how NuGet is going to react if that folder is marked read-only, which TFS will do once it has been checked in.
Update:
I did a little more research on this as I've never used NuGet before. http://blog.davidebbo.com/2011/03/using-nuget-without-committing-packages.html
I would suggest that probably what you want to do is make NuGet a requirement that has to be installed on every developers workstation.
Further, you should place in source control the batch file required to get a workstation ready to start editing the project. The batch file is going to run the commands necessary to get and install the dependency packages.
Beyond that I'd say you might want to contact NuGet directly to ask them how, exactly, this is supposed to work.
Now that nuget supports package restoration we're looking at it more closely.
We use Subversion for source control, and my initial thoughts are that .nuget should be added to our repository, but added using svn:externals so that it points to a single location.
That way we can automatically push out new versions to all developers and projects. For projects on release branches, rather than HEAD, we can specify the revision of svn:externals reference if we want to leave nuget alone.
We have a lot of projects, so it also means not duplicating nuget.exe multiple times in the repo.
We have the nuget.config file in the folder, as it has the references to our internal Nuget server, using the Package Sources area:
https://docs.nuget.org/consume/nuget-config-settings
Apart from this reason, you should let Visual Studio handle the downloading of packages.
I have a visual studio 2010 project under mercurial. I use mercurial either via command line or TortoiseHG. I want to work on a new feature, so I clone the repo. But now I am confused, am I supposed to import an entire new project into VS2010 just to work on this feature? I tried importing the VS Solution that was cloned, but got lots of build errors from dependencies cannot be found errors, which I assume is because I am trying to load this cloned Solution just like the original Solution and some paths are wrong (no idea where though).
How are you supposed to use mercurial and VS2010?
Cloning produces an exact copy of the original repository.
The clone should work exactly the same way as the original repository, so you open your cloned solution exactly the same way as the original one.
If you get build errors in the cloned solution but not in the original one, there are probably some dependencies (=3rd party assemblies that your application needs to work properly) which exist in the original solution, but weren't committed to the repository.
So, when you clone the repository, the referenced files are missing in the clone...so the clone won't work.
Source control works the best way if you check in the complete solution, including all dependencies:
Make a "Libs" folder somewhere in your solution, put all your dependencies inside, reference those files from your solution and commit the whole "Libs" folder to the repository.
If you do it this way, you can clone the repository from a different machine and open the solution, without worrying about any dependencies...it just works.
It sounds like your root problem is that you're adding references using full paths rather than relative paths. You'll need to rectify that before branching is going to be easy for you. I usually make a "References" folder that is on the same folder level as the .sln file, but one level up from the individual projects, then branch the whole thing.
Example Folder Structure
MySolution
MySolution.sln
References
MyProject1
MyProject2
As for VS integration, I use TortoiseHG combined with VisualHG, it works great.
There is also Mercurial Toolbar
Other tools
This may or may not be related, but I've had to load hotfix KB2286556 in order to get rid of the "Unable to update project dependencies" error from VS2010 when building a fresh checkout of our code. It seems this only happens to setup and deployment projects when compilation is invoked from the command line (such as in our build system), but when it happens it's a very frustrating issue to find the solution for.
Also, VisualHg is a good way to track and invoke versioning from within Visual Studio.
While VisualHG still proves to be a wonderful tool after so many years, I would also suggest HgSccPackage as a very viable alternative for all Visual Studio versions (up to VS2015).
PROS: Stand-alone package (TortoiseHg is not required).
CONS: Doesn't have all the handy features of TortoiseHg such as Git support (which I find incredibly handy to handle GitHub-hosted projects) and Mercurial Keyring.
Both of them are freeware and can be installed through the Visual Studio GUI (Tools > Extensions and Updates...).
For a more extensive comparison between them you can also read this post on my blog.