I have an install.ps1 script in my NuGet package. This script runs both during a new install (after all the files have been copied) and during an upgrade.
I want to show a Getting Started page during a new install, but for an upgrade I want to show the Release Notes.
I found this great answer that tells how to open a URL and it works great. But I am stumped on trying to tell the difference between a new install and an upgrade.
The best solution I have come up with so far is to add a Release Notes link to the top of the Getting Started page, but that is something that could easily be missed by upgraders, and is an unwanted distraction for new installers.
I don't think it's possible to know if the current operation is install or upgrade. When NuGet upgrades a package, what NuGet does is basically uninstall the existing package and install the new package.
I suppose you could do something with install.ps1 that "dirties" the project in some way on the first install, which you will not clean up with uninstall.ps1. Maybe insert a dummy file into the project (outside of the normal NuGet handling, so the file won't get uninstalled automatically) or add some other dummy element to the project file. Then, when you see those "leftovers" from a previous install (which were purposely not cleanly uninstalled), you will know that you are installing an upgrade.
Related
I have a folder like c:\chocopkg where I put a couple of packages which I can't find on the official repo.
Creating nupkg archives was really simple and fun. Instead, the Automatic Updater (AU) is too much for me: there is no simple cinst au; one should clone a git repo and also setup a new one even for a local run.
What I need is very simple. I added a script <package>\tools\chocolateyBeforeUpgrade.ps1, with trivial Invoke-WebRequest regexps. It checks for new versions on the vendor's site and can update chocolateyInstall.ps1.
My first question is: Is there some config option to have cup all running a script like this before checking for package status?
If this is not possible, it would be also simple to wrap cup in a, say, cup2 checking and running automatic upgrades, but what file should this wrapper edit before giving control to actual cup?
cup page just says it "upgrades a package or a list of packages", but I don't understand how. I can speculate it looks at the .nuspec version. However in a local share there is no such info without unzipping the .nupkg file and for remote packages this would require a possibly large download.
AU essentially does what you'll need, even if it is a little more setup and work. I know it may feel like too much to start, but you can just start with the files that run the updates.
What I need is very simple. I added a script <package>\tools\chocolateyBeforeUpgrade.ps1, with trivial Invoke-WebRequest regexps. It checks for new versions on the vendor's site and can update chocolateyInstall.ps1.
This isn't going to help with upgrades as it is a chicken and egg scenario. You need the updated package first to be able to upgrade a package. So putting something into beforemodify or the install script is only going to help you on installation. BeforeModify only runs from the already installed package on upgrade/uninstall, so unless there
If I build my own RPMs, is there a way, to tell that before upgrade to the latest version, upgrade to a specific other version first?
So for example I often made a mistake in my postun actions, that I delete a link. So when I want to update to an newer package that fixes my postun action, the usually RPM behavior is that my new packages will be installed, then the old package will be uninstalled and trigger my mistake in the postun action. So I would need to run a reinstall then or to update again to an even later version, that on the next update, my postun action is correct.
So I would imaging something like
UpdateRequires: MyPackage >= 1.1
There is no way to force an update chain like that. You could have the user reinstall the new package. Another option is to fix the symlinks in your %verify stanza and tell the user to run rpm -V on your RPMs.
It is possible to run a step after old packages %postun with %posttrans in new package
VS 2013 fails to restore a package - the package contents are not materialized - although VS/nuget appears to think that it did restore the package successfully.
If I manually uninstall and re-install the same version of that package, it works as it should.
A bare-bones repro can be downloaded as a zip. This repro has a
single solution with a
single project with a
single file, "packages.config", specifying a
single package, "breeze.edmbuilder -version 1.0.4", containing a single file, edmbuilder.cs
single folder, "App_Start", contains nothing but
the .csproj says it should have "edmbuilder.cs" which is ok because
it WILL have "edmbuilder.cs" when the package is restored.
When I build, VS reports that "edmbuilder.cs" is missing ... and indeed it is missing.
However, the package was downloaded; I know this because the build produces a "packages" folder that contains "Breeze.EdmBuilder.1.0.4" wherein I see that "edmbuilder.cs" is present and in the right place.
When I issue the command install-package breeze.edmbuilder -version 1.0.4, nuget reports
'Breeze.EdmBuilder 1.0.4' already installed. NugetRestoreFail already has a reference to 'Breeze.EdmBuilder 1.0.4'.
There is nothing wrong with this package AFAIK. For when I uninstall-package breeze.edmbuilder and then reinstall with install-package breeze.edmbuilder -version 1.0.4, the install works and the missing edmbuilder.cs appears in the "App_Start" folder where it belongs.
The failure is repeatable in place.
close the solution
delete edmbuilder.cs from "App_Start"
delete the "packages" folder
optionally delete the .suo and bin and obj directories
re-open the solution and re-build
You'll get the same failing behavior ... and the same ability to manually uninstall and reinstall.
FWIW, removing the reference to edmbuilder.cs from the .csproj has no effect.
No matter what I do, I have to manually uninstall and re-install the package.
WTF!
p.s.: I am using VS 2013 Update 2 RC. I doubt that the "RC" matters as this problem came to my attention from a customer. You never know.
p.p.s: This is not about the build failing and I don't care that this solution would never run. What you see here is a stripped down version of a real app that would have worked. The only question is "why no restored file?"
Package Restore is NOT the same as installing a package. What you are seeing is by design. It simply downloads any missing packages in the packages folder. No more. No less.
Package Restore was added so you wouldn't need to commit the packages folder to source control.
It is expected that you would install a package then commit the changes made to your project files as well as any files that may have been added like your edmbuilder.cs, essentially anything inside your project folder. You would exclude the packages folder.
Now when you get the source from source control everything would be present except for the package files. Package Restore would download those and now your working copy is complete.
See NuGet's Restore Package insists on specific package versions
Is this stupid or what?
Thanks to #Kiliman for explaining that my horrible experience is "by design".
So how do you actually get the content you thought was being restored? Do you install each package one at a time. That's insane.
I was going to observe that there is no nuget equivalent of an npm install that would fetch all the packages you need ... when I discovered that there actually IS an almost-equivalent. It's just not obvious and I wonder how many people know it exists.
It's a two step process:
FIRST restore the missing packages ... THEN
Issue the command: Update-Package -Reinstall
This re-installs all packages in every project in your solution.
If you only want to re-install for a specific project, try:
Update-Package -ProjectName 'YourProjectName' -Reinstall
In both procedures, the -Reinstall switch strives to install the exact versions of the packages spelled out in your package.config ... and not newer "updated" packages which may or may not work for your project (but see the documentation for exceptions).
Read about update-package -reinstall in the official nuget documentation entitled, "Reinstalling Packages and its Pitfalls".
Do not miss the cautionary remarks. Clearly this technique is but an approximation of what you'd expect from other package managers.
Good luck, peoples.
I know this question is probably stoopid. But I just don't want to cause any hickups with my work system (Win7).
How do I upgrade the software? Do I just replace the existing version or do I need to remove the one I'm having and then install the new version?
I tried to find some info on the net but did not find any info on upgrading.
MsysGit uses a proper installer so you can just download and run the installer for the new version.
The code base distinguishes between "Git for Windows" which is simply the runnable application. This will install with a proper installer, or there is a portable version as well. downloads list
There is then the MsysGit which has the full source code so that you can contribute to the project, or at least try your own local fixes and recompile a local release etc. MSysGit:InstallMSysGit
I have an InstallShield 12 installscript. I want to uninstall the old version before installing the new version. I will keep the name of the package unchanged. How can I do this?
Assuming this is not an MSI project and youve kept the same Project GUID, you could simply call ComponentUninstall() in the OnMaintUIBefore function.
If the Project GUID is not the same you can look at the uninstall string in the registry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{PROJECT_GUID} and then do a LaunchApp with that.
Hope it helps.
With an MSI-based project, this would be accomplished by configuring a Major Upgrade for your project. Upgrades don't exist for InstallScript projects, but there are no Windows Installer restrictions to keep you from running multiple installations simultaneously. You should be able to simply run the uninstallation of the previous version manually in your InstallScript code (maybe in the OnFirstUIBefore function).