I have created a windows install deployment for my C++ application using VS2010. However my problem is that I don't know how can I squeeze in some of my own code to the installation wizard (and is it possible at all?). The problem is that during installation I want:
ask the user to provide his installation key,
grab the hardware fingerprint (I already have an algorithm for that with WMI),
sent both keys using my own c++ communication libraries (so NOT the browser),
continue the installation after receiving a confirmation from the server.
Moreover, this would require adding custom items to the installation wizard like the input field for installation key, or pop up boxes witch error warring like:
Couldn't connect to the server. Please check your internet connection before continuing with the installation.
So it's in fact a 2 level question:
How to run my C++ source files during the installation wizard?
How to add custom element to the installation wizard GUI?
So far it has been hard to find anything helpful in Google. :/
Check Windows Installer, more specifically Custom Actions:
The developer of an installer package may write code to serve their own purpose, delivered in a DLL. This can be executed during the installation sequences, including when the user clicks a button in the user interface, or during the InstallExecuteSequence. Custom Actions typically validate product license keys, or initialise more complex services. Developers should normally provide inverse custom actions for use during uninstallation.
Msiexec provides a way to break after loading a specified custom action DLL but before invoking the action.
Related
I have a package whose previously installed versions contain a series of poorly designed custom actions: they do stuff that can be done out of the box. Thus I'm removing those for the future versions.
A series of bugs is casued by a condition for those custom actions - they all run the second time during an uninstall step during an upgrade. In order to circumvent the undesirable behavior I'd like to supply a Custom Action which modifies the database of a previously installed application if one was detected.
Given an application name, version and custom action name, how can I disable it for an uninstall step during a custom action on upgrade?
My attempt to ammend the Custom Action condition failed when I run my code within a C++ custom action during an upgrade installation: MsiOpenDatabaseW throws access violation when executed within an msi custom action
Basically I am using MsiOpenDatabaseW to modify the cached msi database. It works when running within a standalone executable, but causes access violation within a Custom Action.
You need to amend the 'Condition' of the InstallExecuteSequence/InstallUISequence for the Custom Action of the cached (installed) MSI. An example can be found here, which searches for the cached MSI based on the ProductCode and amends the Condition of a Custom Action in the InstallExecuteSequence:
https://www.alkanesolutions.co.uk/2012/12/08/editing-msi-files-in-the-windows-installer-cache/
EDIT: Some colleagues wrote a free guide on installation testing. Maybe it will be useful in the future, to avoid such costly mistakes.
A simpler solution I recommend is to manually fix the condition on your machine and rebuild the MSI.
Then take this MSI and include it in the next version of your application, and run a custom action to re-cache it, before the RemoveExistingProduct standard action.
msiexec /fv <path of the fixed msi>
This way, the installer with the wrong condition is re-cached before the upgrade is triggered and you don't need to write code that actually modifies the cached MSI dirrectly
I maintain a large Windows C++ Application that installs with nullsoft nsis. Installation is quick and simple (less than 1 minute).
Some users in large companies do not have administration privileges and they have to order costly 3rd party services to update their installation. Therefore some of them only update once a year, while we ship every month and sometimes fix important bugs etc.
So we are thinking about automatic updates that do not require elevated administration rights. Mozilla and Adobe do this as well as others. As far as i can see an the Mozilla XULRunner site they install a service which then in turn can run a update without forcing the user to enter a administration password. I also found Googles Omaha but it is not clear about the administrator privileges ("Support for restricted user environments; for example, users without administrator privileges "..."This requires the user has administrator privileges.").
So far i have not found exact answers to these questions:
What steps do we have to take in order to establish such a mechanism?
Can we keep on with nsis?
What server infrastructure is requested?
Your application should check for updates on your server/website and get the download link.
This should be pretty easy if you maintain a text file/page with fixed hyperlink.
This hyperlink can be hard-coded in your application.
If it detects a version newer than the current version then download the files.
Along with these files there should be instructions for which files to replace and Which files are to be added at what location, etc.
Now whether or not you need admin privileges depends on where you need to place the updated files. If the target folder has some restrictions then it would be difficult to update in the same session. So you may have to launch a dummy exe which asks the user for admin privileges during startup. Now you can copy the updated files to your desired location without much pain.
I have a Visual Studio setup with a custom action written in C++. I need to launch a process from a custom action but both Install and Commit actions are run elevated and thus my process runs elevated too. I want the new process to run as a regular user.
I have seen Start exe after msi install but using current user privileges but it seems overly complicated and shows no code. I haven't got the time to experiment with an unknown API.
Are there any easy ways? Can I use VS Setup to define a non-elevated custom action or do something from the elevated custom action?
If you just want to test your code, it wouldn't be hard to update your built msi file with Orca. It'll let you add the dll with your code to the binary table, add a corresponding row to the customaction table, and add the action to a sequence.
If you need this to happen as part of your build process, you could accomplish the same thing with vbscript. The SDK comes with good sample vbscript code for interacting with an msi database, as described here:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa372865%28v=vs.85%29.aspx
Visual Studio setup projects do not support immediate custom actions. They are all deferred by default.
So either you use custom code to impersonate the current user or you switch to another setup authoring tool which supports immediate actions.
I have created a windows service which checks for the status of the printer.
The user can download this service from a website. I need to query for the status of printers used by this user. So when the user clicks on the download button I want to store the user information in a file which my service can use. The service will use this information to fetch the printers from the database. I want to include this file in my installer. So I have to create the installer at runtime(i.e. when the user click the download button on my website).
How can I create the installer for the win service dynamically using C#?
NOTE: my win service is written in C++. I know about WIX.
quite a few years ago, when I did some work with InstallShield, it was possible to specify in the installer project which file(s) you don't want to be compressed and packed into the .cab files (or whatever they are called nowadays) when generating the installation package. Such a file would be left as-is and separate in the package, and you could later replace it with another file with the same name (I think I actually did something of the sort). So you can have a dummy file when building the install package, and then replace it on the fly with the right one.
I am not familiar with modern tools, but am quite sure this functionality is preserved as it is quite useful.
In WiX you can create custom actions which are arbitrary code you write (You provide the .dll which can be built using C++). In the custom action you can generate your user/location customization file.
I have a Win32 application that includes an EXE, an ActiveX control (DLL) and a COM server (EXE) and I am using Inno Setup 5 to build my installer. Many of our customers use limited user accounts where the user has no admin rights and because the COM components require to be registered (which writes to HKEY_CLASSES_ROOT), my setup file must run with elevated (admin) privileges. I think this in unavoidable (sadly, I can't use registration-free COM because of the EXE COM server I have). However, I would like to create an update installer that can be ran as a limited user and am looking for some advice.
What I am thinking is the following:
The initial setup (first time installation) installs the application into %ALLUSERSPROFILE%\Application Data\CompanyName\AppName instead of %PROGRAMFILES%. The COM components are registered as normal (as they won't already exist).
Subsequent updates (using a different Inno Setup script) will simply copy the new files into %ALLUSERSPROFILE%\Application Data\CompanyName\AppName. Hopefully even a limited user will have write access to this folder and as the COM components have already been registered, admin access won't be required.
This would mean that my customers could upgrade to the latest and greatest version without the hassle of using an Administrator account. Is this acceptable or is this likely to bite me on the backside? I'm pretty sure Google Chrome does something similar but as it has no COM components (as far as I can tell) even the initial setup can be as a limited user.
Any advice from others who have faced this issue would be very welcome indeed.
OK, I found a way to create a limited-user installation script with both my COM server and COM objects being registered per-user.
I am using the latest version of ATL (v9) that ships with MSVC 2008 to create my COM server and COM objects. Turns out that you can register the COM server per-user via the new /RegServerPerUser switch. I tested this with limited user accounts on XP, Vista and Windows 7 and it works perfectly.
Next, the COM controls. Again, ATL9 to the rescue. You can register a control per-user by ensuring that RegSvr32 calls your control's DllInstall function, passing it a command-line parameter of user. So, to register a control in this way you simply do:
regsvr32.exe /i:user /n MyControl.DLL
Again, I tested this on XP, Vista and Windows 7 and it works fine.
I then made the following changes to my Inno Setup script:
The default installation folder will be {pf} (i.e. C:\Program Files) if the user has Admin rights. If not, then it defaults to {commonappdata} (i.e. C:\Documents and Settings\All Users).
Register my COM server using the new /RegServerPerUser switch.
I removed the regserver flags from my COM objects and instead added support to call regsvr32 using the new 'user' switch.
All of these changes are easy to do using the Inno Setup {code} feature.
Thanks to Kim for setting me down the per-user COM install path.
I don't know for sure, but I seem to recall COM servers support per-user installation, and maybe that goes for EXE servers as well.
If so, change your registration code to write information to HKEY_CURRENT_USER\Software\Classes instead of HKEY_CLASSES_ROOT.
The COM infrastructure should do the lookup first per-user and then per-machine.
It's worth an experiment anyway.
If you dumped inno-setup and used MSIs - MSI files support the idea of limited user installation of patches. An administrator must authorize the initial install, thereafter, digital signatures in patch msi files are processed by the elevated msi service without requiring user elevation.
You can duplicate this basic idea yourself - during an initial administrative install, install a service component that has the necessary access. When processing patches, ask the service process to process the EXE COM server registrations.
You need to rethink your approache ... write access to a folder than can also allow for program execution by the same user is the cause for 99% of all virus/malware functionality. Please learn a little about Software Restriction Policy and the new App Locker behavior built into Windows 7 so that the computing infrastructure can move forward not backward.