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.
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 recently started to build manifest files for the ETL packages by navigating to the project properties and setting the Create Deployment Utility to true. I was using batch files before this to deploy the packages, but can't run them anymore because I don't have enough permissions on the server after a new system roll-out.
The problem is that in some cases, I only need to deploy a couple of ETL packages instead of all of the packages under the project. When the project is built, the manifest file lists all the packages under the project that may or may not be required for deployment.
Is there any way for me to only include a couple of ETL packages in the manifest file instead of every package under the project?
According to MSDN, the possible option seems to be adding the necessary packages that should be deployed to a different SSIS project and use the deployment utility on that project.
Redeployment of Packages
Quote from MSDN:
After you finish updating the packages, you rebuild the project, copy the deployment folder to the target computer, and then rerun the Package Installation Wizard.
If you update only a few packages in the project, you may not want to redeploy the entire project. To deploy only a few packages, you can create a new Integration Services project, add the updated packages to the new project, and then build and deploy the project. Package configurations are automatically copied with the package when you add the package to a different project.
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
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
Nuget.exe only supports managing packages at a file system/configuration level. The powershell commands command the magic that update the .proj files.
With that said, i need the ability to update a csproj file with the latest version of a NuGet package outside of visual studio (automated).
Basically, how do I use Install-Package (or any of the other methods) inside of an external powershell script of my own?
UPDATE:
I would like to ability to add project references outside of VS for the following reason.
My company has a lot of shared libraries that depend on each other in some cases. I am using TFS Nugetter to build and publish nuget packages from TFS. I want to ensure that the developers can't queue a build (package) unless the project can build and run on all the newer versions. This ensures that all the newer versions of the libraries work with all the newer versions of its dependencies. If the build fails, then you need to update your nuget reference in VS and fix the compiler errors/unit tests.
I have been looking at the NuGet source and I think I found an easy way to reuse NuGet source to modify proj files outside of VS (kinda).
System.Type t = System.Type.GetTypeFromProgID("VisualStudio.DTE.10.0", true);
var dte = (DTE)System.Activator.CreateInstance(t, true);
dte.Solution.Open(
#"C:\Users\paul.knopf\Documents\Visual Studio 2010\Projects\SLNMemory\SLNMemory.sln");
Basically, open an in-memory version of visual studio, run the nuget commands, then save.
In a build step, after GetWorkspace, I would like to run this in-memory vs to update all nuget references to the latest version.
What do you think? It would definitely be slow, but we would be on the same code base and have all the functionality we need.
Automating Visual Studio as you describe is certainly a possibility.
Another way I looked at was using SharpDevelop to install NuGet packages outside of Visual Studio. The NuGet PowerShell cmdlets were modified to accept a solution and you could automate installation, including the use of PowerShell scripts in a NuGet package, from the command line. The code has not been updated so it targets an old version of NuGet but could be updated. Again this is similar to your solution and fairly heavyweight solution.