I just applied the Nuget patch for ASP.NET MVC4 DisplayModes and with it came a bunch of web dll dependency updates from 2.0.20505.0 to 2.0.20710.0, which have been updated just fine in my packages folder which is in my solution tree, the packages.config file and the .csproj file.
Trouble is though, the build and deploy don't pick up the new versions and just copy the old 20505 versions out of the GAC. Is there something I'm missing about how the packages are referenced? This is VS2010 SP1 and MVC4.
Thanks
Martyn
The NuGet packages themselves probably have little to do with the behavior you're seeing. The package.config file does have a version number for each package, and if that information is up-to-date, then NuGet is going to restore those versions of the packages when it's asked.
The problem is more likely to be with the deployment settings you're using, of which I know little. Of course, I should point out that build 20505 -- the build you have in your GAC -- is a release candidate version of MVC 4, and that it's probably in your interest to go ahead and upgrade to the final build, which has since been released.
HTH,
Clay
Related
In the project I've been using some custom NuGet sources. Apparently some of them are no longer available but I do have the newer (and only newer) versions of the packages on the other (still working) server. Is there a way to restore the packages directly to the newest versions without manually replacing all the references in the .csproj and packages.config files?
I've tried running Updade-Package -Reinstall but I only get the following error message:
Some NuGet packages are missing from the solution. The packages need to be restored in order to build the dependency graph. Restore the packages before performing any operations.
If some packages you use (and still want to use) are no longer available, I suggest you to make a backup of them.
Find the Nuget cache on your server. On Windows this is located at
%userprofile%.nuget\packages
Spot the packages (and version) you want to backup and copy the .nupkg files in their respective folders.
Then you have two choices:
Create a private Nuget feed
Create a local Nuget feed on your development machine
The 1st option has the advantage to be a single source that can be used on any machine you want (development machine, build server...etc) but you will have more set-up, especially for the authentication/authorization (because it's a private feed)
For the 2nd option: Simply create a C:/Nuget folder and put any .nupkg you want.
Then in Visual Studio go to:
Tools -> Nuget Package Manager -> Package Manager Settings -> Package Sources
Click on the green + button to add a new source, simply give it the name Local and browse to your C:/Nuget to set the source.
From now on when you want to restore your Nuget packages, Visual Studio will first look into the nuget.org feed and if it doesn't find the referenced packages, will then look into your Local feed and cache the installed package to the %userprofile%.nuget\packages of your machine.
I hope that answer to your question, I was not quite sure about what you asked and your knowledge about Nuget.
UPDATE:
I think I understand your question better now.
First of all, I think your misunderstand the Update-Package -Reinstall command. It will reinstall the packages with the SAME version as already referenced but simply reinstalling them. It's a useful command for example when you change the target framework of your project. Then you can reinstall the same versions of the packages and they will retarget this .NET Framework version.
So if a nuget restore isn't working then Update-Package -Reinstall will obviously fail too.
With Nuget, when something isn't working, you shouldn't insist but instead, find the tweak that will make it working again. I can't count how many times I went to the different caches to delete some cached packages.
I think you should try to use nuget restore and see what packages are causing issues, then uninstall these packages (this will just remove the reference from the .csproj and packages.config if they aren't installed in the project yet), then you can finally install the newest version of these packages.
I have an application written in Visual Studio 2013, and I'm using a Setup and Deployment Project to distribute it. All of the bullet points in Akash Kava's answer to this question are set:
Installing a new version of a deployment project over old version
i.e "DetectNewerInstall" is set to true, "RemovePreviousVersion" is set to true, etc. I'm also changing the ProductCode and allowing Visual Studio to create a new GUID, but the UpgradeCode is the same. I am also incrementing the version numbers of the C# projects that are added to the Setup Project as Primary Output.
So when a user runs the setup on a machine that already has my software installed, it performs an upgrade. When this happens, all of the content that I wrote upgrades just fine. However, there are some NuGet references (SignalR, Owin, Netwonsoft, etc.) that do not upgrade. Even though the packages were updated in the project and manifest, the installer won't replace the old versions of the NuGet .dlls with the new ones. When I do a new install and examine the .dlls in the Program Files, I can see that the NuGet .dlls are the new version, so I know that the correct versions are being bundled with the Setup Project properly. It just appears that they are not being overwritten if they already exist. And this only happens with the NuGet references; the .dlls and .exes that I wrote upgrade properly.
Is there any way to force the Setup Project to always replace the NuGet .dlls?
However, there are some NuGet references (SignalR, Owin, Netwonsoft,
etc.) that do not upgrade. Even though the packages were updated in
the project and manifest, the installer won't replace the old versions
of the NuGet .dlls
NuGet has nothing to do with deployment and it is supposed to download packages only when you build your project OR you download from console.
Setup/Installer should automatically detect the dependencies based on PrimaryOutput but if some of dlls are not referenced in project and are required for deployment then you should add them to installer project manually.
On creating new installer make sure to build all projects so that installer project can update the dlls to new version if you have changed it in application project therefore no action required to deploy new version of assemblies considering you have already configured installer to remove previous version on installing new version.
I recently migrated all my Visual Studio 2013 projects to Visual Studio 2015 and followed the steps documented in this article by Nuget to make sure that automatic package restore is still working, in short
I deleted the Nuget.exe and Nuget.target files from source control and disk
I updated all project files and deleted the sections related to Nuget
I'm experiencing a problem when I'm updating Nuget packages, it is not updating the project references to point to the newest dll versions. I can see that the newest packages was installed though. This problem is also not related to specific packages.
Has anyone else experienced a problem like this?
NuGet package restore does not modify the project files. It just downloads and extracts the NuGet packages to the packages directory.
If you are trying to edit the packages.config file and then have the project's updated you would have to use the Package Manager Console and run:
Update-Package -reinstall
Which will uninstall and install the packages again and update the project's references.
We realized that some of our junior developers only installed the required Nuget packages for ONE project in the solution, they then added references to the required dll's for all other projects by browsing to the physical location of the dll's on disk. This obviously caused the problem because only ONE of the projects in the solution contained entries for Nuget packages in it's packages.config file while the remaining projects in the solution contained none.
When all packages were updated using the Update-Package command only the ONE project containing entries in it's packages.config file were updated with the correct project references.
Even though this is not a Nuget bug and rather a problem caused by inexperience, I logged an issue with Nuget to see if they can improve the software to prevent these types of problems.
So I recently had a very similar issue as well, unfortunately uninstalling and reinstalling did not work. Hopefully this helps anyone else as it was very frustrating.
Steps:
go to or launch the quick launch feature.
type package manager
select "tools->Nuget PackageManager-> Package Manager Settings"
In the options window that pops up. click "Clear All Nuget Cache(s)"
Right click solution and select Restore Nuget Packages.
Hope this helps.
I was facing an issue with NuGet package of Newtonsoft.Json as shown below:
I tried all possible solutions but none of the below mentioned ones worked:
Cleaning solution
Rebuilding solution
Clearing NuGet package cache
Finally I realized it had something to do with .NET Framework version targeted by my C# project. There was some mismatch it seems. The moment I upgraded the .NET Framework version of my project to latest, the Newtonsoft.Json package dependency and its reference came alive instantly.
Something I just noticed, and I'm not sure if this will help you or anyone else reading this, but this issue literally wracked my brain. The problem was that I was installing packages that I had created myself using NuGet Package Explorer on Windows.
It turned out that, I believe after updating NuGet Package Explorer, it was no longer putting DLLs that I included into the lib folder. Once I started manually adding the lib folder back into the package within Package Explorer, and then uploading to NuGet and reinstalling in the consuming project, that the reference would once again start to appear.
I'm not sure what caused this behavior - it could have been my own fault, but I literally just now figured this out - and consequently have to go back and re-do a whole bunch of NuGet package goodness that I've done over the past month. OUCH.
Hope this saves someone at least an ounce of pain.
None of the above worked for me.
What did work, was to edit the project file directly and delete the existing reference. When I reloaded the project, the package then showed up in references as a Nuget package.
I happened to come across the same problem. i tried all the possible solution but found the solution - just open the .proj file in an text editor and check the package Version and the HintPath in the Reference tag. Sometime there is an mismatch correct it then Visual studio will recognize. I hope everyone can save lot of time. Here is an sample to refer
<Reference Include="nunit.framework, Version=3.4.1.0, Culture=neutral, PublicKeyToken=2638cd05610744eb">
<HintPath>..\packages\NUnit.3.4.1\lib\net45\nunit.framework.dll</HintPath>
</Reference>
Migrating to PackageReferences worked for me for the projects that allowed it. My Asp.Net project could not be migrated, so I resorted to manually adding the references to the .csproj file
I have a solution with about 5 projects including a Silverlight client.
Through NuGet, I add the Async Targeting Pack for VS 11 at the solution level and select all projects.
It adds a reference in all the non-Silverlight projects, but not the SL one. The workaround is to add the reference by hand.
Is this a failure of NuGet? A failure of the NuGet package? Or am I doing something wrong?
Same thing occurs with Caliburn.Micro and the SL package.
Yet if I start from a fresh clean project, it all works as expected.
I tried deleting the .nuget and package folders, and manually removing the project reference, and that seemed to clear everything out, but I still had the above issues when adding the packages back in.
Greg
Which version of Silverlight are you using? I noticed the NuGet package only targets NET40, NET45 and SL5, so if you're using Silverlight 4, the reference won't be added to your SL4 projects.
I have been using NuGet to manage my internally created assemblies for a few months, and it's working very well. I recently 'discovered' portable class libraries, which has also been great - until it's time to install the packages.
Say I have a PCL that targets .NET 4.5, SL5 and .NET for Windows Store Apps. I run nuget spec to create the .nuspec file, edit the values, package it up, and add the .nupkg to our internal feed. If I open the .nupkg file in the Package Explorer, I see one content folder under lib called portable-win+net45+sl50.
When I try to install the package from any compatible project in another solution, I get the following message:
"'Project.PCL' could not be installed because it is not compatible with any project in the solution. The package doesn't target any framework."
If I manually create the .nupkg in the Package Explorer, updating the version number, adding a lib folder for each targeted framework (not a portable folder) and added the Project.PCL.dll to each folder, I can add the package to the compatible projects in the solution. But to do this process every time I want to update a PCl is somewhat tedious (I had been creating a little .cmd file in the project root folder to quickly package and deploy).
Do other people have this problem? How can I package PCL's in the same way as other types of projects?
Note - I'm using VS 2012 Ultimate and NuGet 2.2
It sounds like maybe nuget spec doesn't work for Portable Class Libraries - that's worth starting a thread or filing an issue on the NuGet site.
However, you can also create a .nuspec file from NuGet Package Explorer. Just create the package as you already did, but then choose "Save Metadata As..." to save it as a .nuspec. Afterwards you may need to edit the source paths in the nuspec file manually, but you should be able to automate the creation of the package.
For me nuget spec and nuget pack worked fine with a portable project while creating the package and installing it on a compatible project.
Do you want to check if you have the latest nuget.exe (2.2), it can be downloaded from http://nuget.org/nuget.exe or can be updated by running nuget update -self