Just had 2 questions.
1) I am writing a simple program in C# just to test out how to set up updating, However the program automatically updates ( I am using ClickOnce) and I was wondering is there any way to prompt the user to update?
2) I am publishing my project to a localhost, and I have published it about five times (v 1_0_0_1 - 1_0_0_5) and the folders are stored as such, however, when I publish, it changes ALL of the different versions, not just the latest one. I am trying to allow version control where I can allow a user to go back to a previous version.
Thanks in advance!!!
After the user installs your app for the first time, every time after that when the application is started it will check for an update. If there is an update it will ask the user if they want to update to that version.
This happens by default and you can even prevent them from opening the application if they select not to update. (Preventing the program from opening if the user does not update is not the default configuration but can be set in the publishing wizard or properties of the application)
Also you should know that publishing the application will not cause you to lose or overwrite all of your previous deployed versions. They are all still there under root/Application Files. You will see the latest version though because the app will look at the manafest file and that will tell the app which version to run. If you wanted to push out a later version you would change the manifest to point to that version.
However, a single user will not be able to choose which version they want. Once they choose to update they will be on that version until you push out a different one. This is for security and compatibility so that your users are on the same version once they choose to update and you don't have a bunch of different people running different versions whenever they feel like it!
Related
I wrote a C# program in Visual Studio that uses the Setup & Deployment Project to create an .msi installer. The "InstallAllUsers" value is set to "True", so it'll install "Everyone" by default, but the users can change it to "Just Me" during setup.
It's just a basic installer - nothing fancy.
My question is this: after they install the program, is there a way to tell which option they chose? Is there a registry key that I can dig for that will tell me whether they chose "Everyone" or "Just Me" during install? I'm not programmatically adding any registry keys, and I can find the "Uninstall" key for my program, but I don't know if there's a value in there that will tell me.
* EDIT *
For a clearer picture:
As I make changes to my program, I increment the version numbers and give the updated .msi to the users, and they just rerun the installer. There was originally only supposed to be a couple of users, so I didn't make a complicated updater. Now there are many users, and the updater is in-the-works. For now, the current users are happy with the process - I give them a new .msi and they run it again - except for one thing: the installer doesn't "remember" their settings from the last time they ran the installer (their words, not mine). I can get the directory of their last install from the "Uninstall" regisrty value and set it with TARGETDIR, so I've got the installation path covered. But I'm trying to figure out if the user changed "Everyone" to "Just Me" the last time around.
One way could be check for current logged in user in registry and see if it has the software listed in in installed software list under HKEY_CURRENT_USER\SOFTWARE\*
There's an example here of enumerating products to find out which context they were installed in. If you know the ProductCode you can just do the MsiGetProductInfo part.
https://msdn.microsoft.com/en-us/library/windows/desktop/aa368279(v=vs.85).aspx
There are APIs for this, so it is more advisable than guessing based on what might be in the registry.
The installation folder properties window in Visual Studio setup projects has an InstallAllUsersVisible property you should set to False. Otherwise it's going to be a nightmare when you do an upgrade with RemoveExistingProducts=True because that requires the upgrade to be in the same context as the original install. You'll find people trying to do an upgrade with All users of an installed Just me product and it will not work.
I don't like per-user installs due to all the problems relating to upgrades, patching, etc... Accordingly I managed to migrate per-user installs to a per-machine during a major update install using Installshield and their built-in ISSetAllUsers custom action plus some re-sequencing of various standard actions. The description can be found here: windows Installer - uninstalling previous version when the versions differ in installation policy (per-user, per-machine)
If you want to migrate all installs to a per-machine install, you could replicate this approach using Phils suggestion to read the current installation context via your own custom action and then run this custom action in place of the ISSetAllUsers custom action that Installshield provides. Then you can follow the rest of the procedure from the link above.
I have WPF application who is possible to update when is have new version. For create installer I will use Visual Studio Installer. I understand how to auto update my app, but this is not exactly what I want.
I want when user check is want to "Automatically check for updates" only then is check do is have new updates. Like in the picture
My question is: Is it possible with Visual Studio Installer to manage update for application. When user is checked then if is possible to update to new version. If user not checked then the application is not check for new version.
Im sorry for my bad English. Thanks in advice.
It's not very clear whether you want that checkbox in the installer itself or in the app. All the instances I've seen are in the app. There's no point in putting the check in the installer because the user does that just once, and updates may be generated after the product has been installed. You cannot run the same install again! So this check is added to the app, and the implementations I've built do a web service call to the company web site (passing in the installed product's version, ProductCode, UpgradeCode) and if there is an update the app downloads it. The user may or may not be able to install the upgrade if it requires elevated privilege and the user has limited privileges.
The supported upgrade mechanism with VS setups is to increment the setup project's version property, accept the requested changes, rebuild the entire MSI with incremented file versions for the files you need updating, and set RemovePreviousVersions to true to upgrade the entire product.
I think that I have somehow screwed up my install project because my application fails during the installation project. So I would like to revert to an earlier version. My solution consists of 47 different projects and it actually works fine after installation, so I would like to keep the changes that was made after I screwed up the installation process. How do I go back to an earlier version in Team Foundation Server for a single project only?
All I know is that I have a working version from 03.03.2011 at 13:00 and a non working version at 03.03.2011 at 16:00. Please help me isolate the affected files.
Firstly you get get a specific version to overwrite your workspace with earlier versions of everything (by change set number, date/time or label). This would be a good place to start: verify that the earlier version works first (even if you recall it works it is always worth verifying). In Team Explorer right click for the Get Specific Version... command. From the command line the tf.exe syntax allows specifying change set etc. (see the documentation for details).
Once you know you want to roll back one or more change sets you need to use the rollback command from the TFS PowerToys (download link) command line tool tftp.exe (in TFS2010 this is part of tf.exe).
I have a .NET 3.5 Setup Package Project which installs my application successfully.
The setup package deploys a number (around 70) custom files for use from within the application.
From time to time I have the requirement of deleting some of these files, however upon restarting the executable, it automatically runs a portion of the Setup MSI again, and re-installs these files.
The only way I can achieve my desired result at the moment is to delete the files after starting the executable.
I have looked through the attributes on the files in the setup package such as Vital and PackageAs, however cannot seem to identify the required setting to achieve this.
Does anybody have any idea what is needed to acheive this ?
Much thanks
From http://msdn.microsoft.com/en-us/library/kz0ke5xt%28v=VS.100%29.aspx
"
How do I turn off repair for a file that users are expected to modify or delete?
Visual Studio creates advertised shortcuts so that when the program is started it verifies that all its files exist. To change this behavior and cause it not to repair the file, select the files in the setup project and change the Condition property to NOT REINSTALL so that the file will not get reinstalled on a repair and its Transitive property to TRUE so that the condition is re-evaluated. This will cause the Installer to flash on the screen the first time after the file is deleted, as it verifies that the file should not be reinstalled, but you will not see the installer after that.
"
This has annoyed me too, and I don't know the specific setting you have to change to prevent this, but I can tell you a work-around that I've used. I found that it only happens when I run the application from the shortcut that was installed as part of the installation. So, if you create a new shortcut to the application and run it via that shortcut, then the files you've deleted won't be automatically restored.
Windows Installer supports three types of product upgrades: major upgrades, minor upgrades, and small updates. A synopsis of which upgrade to use under what circumstances can be found here: http://helpnet.flexerasoftware.com/robo/projects/installshield12helplib/MajorMinorSmall.htm
What you want to do is set you installer up in such a way that the new version of your software sees the file deletions as upgrades to a prior version. If you fail to do this and then you delete files, the program installation thinks it is damaged, and tries to restore the files you deleted when the program is executed again.
In InstallShield (the installer product with which I am familiar), there is a Product GUID and an Upgrade GUID. The Upgrade GUID always stays the same within your product family of different versions. The Product GUID changes with each new MAJOR or MINOR release. In general, if you follow this pattern, and then specify file deletions in your new version, the installer should interpret the file deletions as upgrades, and you should not get any errors on subsequent execution of the newly-installed version.
I have a Windows service written in C# using VS2005.
The installation is via a wizard that calls msiexec to install the msi file also created using VS2005.
I am having trouble generating an msi file that will upgrade from one version of the service to another. The wizard program handles detection of the currently installed version, stopping the service, coming up with an appropriate command-line for msiexec and then re-starting the service.
The existing msi has a version property of 1.1.02, the new one is 1.1.03. The product and upgrade codes are identical.
Uninstalling 1.1.02 manually via add/remove programs works fine, as does installing 1.1.03 onto a "clean" system.
Upgrading 1.1.02 to 1.1.03 goes through the motions but the end result is 1.1.02 installed.
The command line that the wizard uses for upgrading is:
msiexec /qb /i "MyProduct.msi" REINSTALL="ALL" REINSTALLMODE="vos"
Where am I going wrong? I'm assuming I must have missed something fairly fundamental...
The fall-back position is to inform customers that they need to manually uninstall 1.1.02 before running the wizard to install 1.1.03 but I'd rather not have to do that.
Edited to add:
Changing the product code (as VS2005 also prompts you to) actually removes the ability to upgrade at all, as it the installer won't let you do a reinstall if that product code hasn't previously been installed.
All it will then let you do is install (and then you get the usual "service already exists" -type message).
There are several things that need to be done to get "upgrades" to work with MSI's if you want to automatically remove the previous version.
First some background information about the mysterious "codes". There are 3 codes (GUID's) associated with an MSI:
Package Code - This identifies a particular version of the MSI installer and should never be reused across builds. It must always be updated.
Product Code - This identifier is used to ID a particular version of the application. It is up to the installer author to decide when to assign a new product code.
Upgrade Code - This identifies the application and should not change through it's lifetime
The Upgrade Code should never change. For you upgrade scenerio, the Product Code must be changed for each version. Additionally, as you mentioned, you must bump the version number. The Product Code and Upgrade Code can be found by selecting your setup project and going to the Properties Window. The Package Code is hidden in Studio and will always be updated.
The item you are probably missing, is that you also need to set the RemovePreviousVersions setting in the Properties Window to true.
One more thing in addition to mohlsen's answer (For Visual Studio 2008):
In order for your Primary Output (your EXE!) to upgrade properly, you must increment the FILE VERSION
This setting can be found in the Project Properties: Application Tab -> Assembly Information
An easier way to manage this is to REMOVE the AssemblyFileVersion from all assemblies, including the main executable and all the managed DLLs.
In each of your AssemblyInfo.cs files, I recommend doing something like this if you don't care about the version numbers, but want to have some traceability.
[assembly: AssemblyVersion("1.1.*")]
// don't need this [assembly: AssemblyFileVersion("1.0.0.0")]
Everything still compiles fine, and if you don't have the AssemblyFileVersion defined, then the installer assumes that everything is different every time (which is probably fine if you are installing all of the DLLs next to the main EXE).
I spent a long time figuring this out, especially if I don't want to have to increment anything manually!