I have inherited a C# software application which has an auto-update component. This component works pretty well, it stops the application, updates any files which have changed, then restarts the application. The software is initially installed using an MSI file.
However what this auto-updater doesn't do is update the windows installer database with the new application version number, nor does it register any new files which didn't exist in the original installation.
Looking at the installer API (https://msdn.microsoft.com/en-us/library/aa369426(v=vs.85).aspx) there doesn't appear to be any way to modify the configuration in this way.
And from what I have read (http://blogs.msdn.com/b/windows_installer_team/archive/2006/05/12/595950.aspx) modifying the registry entries directly isn't recommended.
Somehow many applications manage to accomplish this e.g. Google Chrome.
Is there a way to accomplish this without directly modifying the registry?
If not, can someone tell me (or point me to) the exact registry entries that would need to be changed. Including how to find the guid of the product entry in the installer registry section.
Windows Installer updates can be installed with upgrade .msi packages or patches. There's no other supported way of updating MSI's internal registration.
Google doesn't use MSI to install Chrome, so they had to invent their own patching system.
Related
Sometimes AutoCAD 2009 spoils own menu files and some settings. At this case I recover the application state through the deleting its registry key in HKCU and its folders in the current user profile. Now I am to install necessary components (they recreate the registry key in HKCU and folders). For this purpose I programmatically launch the application. But I want to kill the process when the necessary components will be installed complettely during the application starting (because AutoCAD launching takes many time).
If I kill the acad.exe process, then the components installing will be killed too. I dont need such behaviour.
Is it possible to define (programmatically, I use C#) the moment when the installing of these components was finished? Or maybe it is possible to define that some components of the application are not installed on the current user profile still and then to force the launching of these components installing without the application launching (I don't know how to do it).
If you delete files or registry entries from the installed product, it's a feature of Windows Installer that it repairs the install at certain trigger points, one of which is using an advertised shortcut. If you don't want that application to actually run and want only the repair, then an alternative is to go to Programs and Features, select the product and Repair it. Or right click the MSI file and choose repair.
MSI Installer can be installed PerUser or PerMachine.
I'd like to detect before the new version installation: was previous version installed PerUser or PerMachine?
If PerMachine do nothing because Installer will remove the previous version and install the new one, ok.
If PerUser then check: was it installed user which is the current user?
If current user==user who installed then suggest to user switch installation to PerUser and continue.
Else give message "User 'other_user' need to uninstall manually etc".
The question is: how I can check in c# the user name who installed the current version of product?
Oleg,
Based on other questions you've asked I understand the jam that you are in. It's unfortunate but there isn't much you can do. You could wrap the MSI in a bootstrapper (EXE) to remove any existing Per-User installation for the person logged in ( assuming it wasn't pushed to the machine using the SYSTEM account ) but that wouldn't handle a situation where some other user profile had installed the app.
Here is about the best thing I can think of for your situation. Create your new installer to install to a new directory and new registry keys ( completely different foot print then your old application ). Give this new MSI a fresh UpgradeCode property. Author an active setup registry key to run a cleanup utility the next time a user logs on and then reboot the machine. Put the old UpgradeCode in the Upgrade table just in case you can get lucky for an old per-machine install.
When someone logs in for the first time your EXE will be run. It can then perform MSI API queries to look for old versions of your product and perform an uninstall. In time your old application will be removed.
I recall getting myself into this situations many years ago before I understood the ALLUSERS property. Per-User installations are a pain and only useful for non-privlidged "viral" (as in socially spread) application. It's not a good story for commercial / enterprise applications.
What you want doesn't make sense.
Per-user installations are visible to a single user, you won't be able to retrieve information about the per-user installed apps for user A if you are running as user B. Only per-machine installations are visible for all user.
Take a look here:
http://msdn.microsoft.com/en-us/library/aa369786(v=vs.85).aspx
Note If an application is installed in the per-user installation
context, any major upgrade to the application must also be performed
using the per-user context. If an application is installed in the
per-machine installation context, any major upgrade to the application
must also be performed using the per-machine context. The Windows
Installer will not install major upgrades across installation context.
Now to answer your question... If you are executing an installer per-user and the upgrade installer detects the previous version, that means that the current user installed it.
I have written a application in C# using visual studio, I have made a project set up file which as created to files for me in my debug.
The Windows Installer and the setup application are both needed, but i would like to merge them into one, like when you download an app the installer its just one file.
Could some one please show me how to do this, or just point me towards a good source.
Thanks in advance.
If you're using Visual Studio's built-in setup project template to generate your installer, then you don't need the setup.exe file at all.
The only thing you need to distribute is the .msi file. That contains everything that a user would need to install your application. The setup.exe file is simply a stub that launches the setup routines from information in the .msi file, which is a database that the Windows Installer uses to install your application. And since these files can be launched by double-clicking on them if the Windows Installer service is installed, you really don't need to distribute the setup.exe bootstrapper if you don't want to.
Some special reasons that you might want to distribute a setup.exe file are:
You expect for some reason that your users might not have the required version of the Windows Installer installed on their computer. This is getting to be pretty rare nowadays, especially considering how widespread broadband Internet connections are and how pushy OS vendors are getting with pushing automatic updates. But if your users are "disconnected" (in many senses of the word), you might want to use a setup executable to verify the presence of the necessary version of the Windows Installer, install it if it isn't there, and then launch your .msi file to perform the install. (You cannot run a .msi file if you do not have Windows Installer installed.)
You need to support multiple languages. In this case, the setup.exe file can perform a language transformation on the .msi file before launching the installer.
You want to manage the installation of several .msi files in sequence. The way that Windows Installer is designed, it's difficult to chain installations of .msi files, which makes it difficult to install dependencies before or after you install your own application's files. A setup.exe file is not subject to the limitations of the Windows Installer, so it can be used to chain these and precisely manage the order of installation.
In general, creating your own setup.exe file (or using one of the many third-party installer software packages to create it for you) gives you significantly greater flexibility. You essentially have complete control over the installation process, rather than having to follow the rules of Windows Installer.
But 83.44% of the time, this isn't necessary and you should follow the much simpler route of using an .msi file. This also allows system administrators to automate installs across machines that they manage (for example, throughout a corporate network), something that is not supported for raw executable files.
We have developed an ASP.Net/C#/SQL Server application and use SetupBuilder (from LinderSoft) and MSI for software installation purposes.
We are having all sorts trouble with the MSI component - in that installations regularly fail and we appear to have limited control over the MSI interface/process.
Are there any installation tools that give us more control over the MSI install process and can anyone recommend a better set of tools for software deployment purposes?
WIX provides a lot of control in creating MSI's.
Takes a bit of learning but we have used it for creating MSI's in our projects and it has worked for all of our needs.
From their site:
The Windows Installer XML (WiX) is a toolset that builds Windows
installation
packages from XML source code. The toolset supports a command line
environment that developers may integrate into their build processes
to build MSI and MSM setup packages
Sorry for the generic answer, but if you could provide more details regarding the errors that you are facing or exactly what areas you want to be able to control, then might be able to throw some light on it.
Most asp.net applications i've ever used have had a partly manual installation process, eg they ask you to create a sql server database and user, then copy the application in and update the web.config to reflect the sql user, then create the IIS application manually, and any further installation (eg creating the db schema) is handled automatically by the app the first time you use it.
It's always seemed acceptable to me, so long as everything is documented well i've been happy to accept it, worth considering?
I guess it depends upon the expected technical skills of your target user base...
My App will be initially deployed with Windows Installer.
The key characteristics of the solution I am looking for include:
Support silent update while app is
running (or automatically restart
client)
Easy to maintain and manage packing
process
Avoid complex customizations or
installation scripts
Do you have any ideas on how can I achieve this? Even if it means to modify the app code to support any idea.
Application is .net 2.0
Have you considered using ClickOnce for deployment? It has a facility to programatically check for updates and optionally force them to be installed - see http://msdn.microsoft.com/en-us/library/ms404263.aspx
You can silently update your application by using the Restart Manager (available in Vista and Win7).
Don't forget that a user is not alway the administrator. Since Vista if you sign your Windows Installer package you can update the application without needing administrator rights from the current user.
For all this to work you need to install your application using the Windows Installer technology. You can use Wix to create an xml file and compile it to an .msi package. Wix integrates nicely with VS.
The Proxy Design Pattern will help you achieve this while this is the pattern used for plugins.
Another short explanation is with the Gang of Four - Proxy Design Pattern.
Having an eye out the Shadow Copying of assemblies is definitely useful for the trick, as you shadow copy your updated assembly to your application assemblies folder, then you can make your application aware of changes, then unload the old assembly and load the new one for the changes to take effect, that is, without even having to restart your application, and this will be absolutely transparent for the end-user.
A more simple approach might be the ClickOnce Deployment which you might be interested to read about following the sugested link.