I made a checkout of my project from a different location, now I noticed that I didn't commit the dll files from /packages, can I get nuget to download them?
The only way to do this right now is to is to remove the reference from packages.config and reinstall those packages. We're planning to support this scenario in the future (more info here http://nuget.codeplex.com/workitem/165).
Related
Im trying to use an ASP.NET web application downloaded from the internet. Im looking for a way restore all the dependencies/packages in a quick way (clean and building the project did not solve it), rather than installing them via nuget one by one. Is there anyway to download and install/resolve (version issues) all the necessary packages at once?
I tried below package manager console commands, but they did not resolve the package conflicts.
Update-Package -Reinstall,
nuget install packages.config and other solutions here - How do I get NuGet to install/update all the packages in the packages.config?
[resolve/install packages]
Can someone help? Maybe Im using wrong commands or doing something wrong.
If you go into Tools > Nuget Package Manager > Manage Nuget Packages for Solution, it will show a yellow bar at the top asking you if you want to restore missing packages. That's a manual way, but there are also some important VS options you want to look at as well, one being an option to restore packages on build.
There is a generic restore option as well from the package manager console, and that should have worked if it was simply a matter of reimporting the missing packages...
Update-Package -reinstall
You can try to delete the folders, than reinstall using these options. However, is there a possibility there is a .NET framework version mismatch with the version of the DLL's? Maybe some of the DLL's need updated?
Remove package folders from Package folder - don't remove package.config. Next, build you application - nuget should automatically restore all packages.
I was wondering why is Nuget restoring needed? I mean nugets are just files that are downloaded to your solution. So if they are downloaded once why do they need to be restored sometimes?
When you install a NuGet package to your solution/project, it does not add the files from that package to your solution/project. Rather it makes an entry to the csproj/project.json/packages.config (depending on the project type and VS version) on the required package dependency. And downloads the packages to the NuGet cache (not the solution).
When you build the solution, these packages are restored to the solution. Restoring means the packages (.nupkg) are expanded to individual assemblies and the exact dependency to these assemblies are written down in the assets file (project.assets.json) created in the obj directory. Again, here the files are not copied to the solution but instead are referenced from the cache. The build output will contains these files as required. Remember caching plays a big role into when the packages are actually downloaded vs. referenced from the cache.
I just went through a dll hell. Turns out that TFS has been synchronizing packages, and I ended up with two versions of Microsoft.Web.Optimization and its dependencies at once. NuGet was convinced that I have the newest versions installed, and even reinstallation changed nothing. But at the same time, my projects wouldn't build or, if they'd build, they wouldn't start, complaining that they can't find the library version given in the manifest.
I managed to solve it by uninstalling the packages from NuGet console, physically removing their folders from the hard disc, and then doing a fresh build (which re-installed the missing latest versions). But the package folders I deleted manually are still sitting around in the Source Control Explorer. And I can't delete them, the Delete button is greyed out when I select one of them. I am afraid that they will come again when I get newest version next time.
How do I prevent it? I would like to remove them from the solution completely. In the worst case, it would be OK to ignore them, but as they are on a level above the projects, I can't enter them into a project's .tfignore file, and Visual Studio didn't let me add a .tfignore file to the solution itself.
Would it be an option to not checking in the Packages folder to TFS? NuGet now supports automatic package restore, which automatically restores packages on build.
Here is doc for migrating to this new model: http://docs.nuget.org/docs/workflows/migrating-to-automatic-package-restore.
And this may save you a lot of hassle with checked-in packages folder.
Arguably best answered in this post:
https://stackoverflow.com/a/40409464/1690217
The NuGet documentation provides instructions on how to accomplish this and I just followed them successfully for Visual Studio 2015 against VSTS (Azure-hosted TFS). Everything is fully updated as of Nov 2016. This also still works for Visual Studio 2017 RTM (March 2017).
I added the following files as explained above:
.tfignore
\packages
!\packages\repositories.config
.nuget\nugget.config
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<solution>
<add key="disableSourceControlIntegration" value="true" />
</solution>
</configuration>
I had to delete the packages folder and checkin the delete, then package restore will kickin and rebuild the folder but VS will no longer automatically add it to source control.
I am using NuGet to add packages to my solution. NuGet added a Packages folder to my visual studio’s solution root folder. The concerning part is that the “packages” folder is not part of source control. That means the source code comes from TFS, but the project references come from a folder that is fed by external source. People can put malicious code in the packages folder and build the application.
I like to understand how my other colleagues that get the source code from the TFS source control can build the project with packages folder not being part of the source control?
We did have a similar problem where our build server wasn't allowed to have internet connection, so couldn't download packages. We started with creating our own NuGet Source, which was simply a shared folder with all packages copied to it. The visual studio projects would of course use these packages rather than packages hosted on www.nuget.org
I must say that we scrapped this idea because of the overhead of doing it as our package usage increased.
My advise is that if you are worried about packages downloaded at build time, store the packages folder on source control.
NuGet supports automatic package restoration so your colleagues who use this feature will automatically download required packages. There is a policy at nuget.org that prevents user to delete or update exact version of package once it is published so it can support package restore without any interruptions - see this answer for more detail. If you are using other package sources than nuget.org than you should check their package deletion/update policy because it may be different.
Does anyone know how to update dUnit which comes with Delphi 2010 to the latest svn source code?
Steps
Goto http://sourceforge.net/projects/dunit/
Download the zip file (currently version 9.3.0)
Unpack to a folder of your choice
Use Components|Install packages to remove the current DUnit package bpl.
Compile and install (optional) the new version. Compilation is needed only if you want to install the design time wizards or if you do not build your projects using the source. Installation is only needed if you want to use the design time wizards. Read the various doc and readme files for further instructions.
Update your environment's library path and the search paths of projects using DUnit:
take out any references to $(BDS)\source\DUnit*
put in a reference to the src subfolder of where you installed the new version
Update
The latest version on sourceforge is 9.3.0, but that is not the latest DUnit version. To get the latest DUnit version, you can go to its SVN repository: https://dunit.svn.sourceforge.net/svnroot/dunit/trunk/
The are at 9.4.0 (revision 41 according to the top of the page, version found in readme-9.4.txt and release.ini).
The sources found there do not contain any packages for Delphi versions past D7, but as mentioned in my response to Serg, these packages are for the DUnitWizards which were contributed from outside the main DUnit project. To use DUnit, you don't need these wizards. In fact, DUnit itself does not have any packages!
I think you can still use the wizards (or should I say project/unit templates) that come standard with Delphi and just make sure that your library and search paths point to the new version... In fact, I know you can, because that is what I did a couple of days ago: use the File|New|Other|Unit test| project and unit templates that come standard with the IDE, but compile against the newest sources downloaded from SVN.
You can either unregister current DUnit package by removing its key from Registry:
HKCU\Software\CodeGear\BDS\7.0\Known IDE Packages\$(BDS)\Bin\unittestide140.bpl
Then download and install the new version from any folder you want, into the IDE as you install any other IDE package.
Or you build the new version, copy the generated BPL file to $(BDS)\bin\ folder, and its .DCU files to $(BDS)\Lib\ folder, and replace $(BDS)\Source\DUnit folder with the source folder you downloaded from SVN.