The MSI installation would call my (native/C++) custom action functions. Since the DLL is freshly loaded, and the MSIEXEC.EXE process is launched separately for each function (the callable actions, as specified in MSI/WiX script), I cannot use any global data in C/C++ program.
How (or Where) can I store some information about the installation going on?
I cannot use named objects (like shared-memory) as the "process" that launches the DLL to call the "action" function would exit, and OS will not keep the named-object.
I may use an external file to store, but then how would I know (in the DLL's function):
When to delete the external file.
When to find that this function call is the first call (Action/function call Before="LaunchConditions" may help, not very sure).
If I cannot delete the file, I cannot know if "information" is current or stale (i.e. belonging to earlier failed/succeeded MSI run).
"Temporary MSI tables" I have heard of, but not sure how to utilize it.
Preserve Settings: I am a little confused what your custom actions do, to be honest. However, it sounds like they preserve settings from an older application and setup version and put them back in place if the MSI fails to install properly?
Migration Suggestion (please seriously consider this option): Could you install your new MSI package and delete all shortcuts and access to the old application whilst leaving it
installed instead? Your new application version installs to a new path
and a new registry hive, and then you migrate all settings on first
launch of the new application and then kick off the uninstall of the
old application - somehow - or just leave it installed if that is
acceptable? Are there COM servers in your old install? Other things that have global registration?
Custom Action Abstinence: The above is just a suggestion to avoid custom actions. There are many reasons to avoid custom actions (propaganda piece against custom actions). If you migrate settings on application launch you avoid all sequencing, conditioning, impersonation issues along with the technical issues you have already faced (there are many more) associated with custom action use. And crucially you are in a familiar debugging context (application launch code) as opposed to the unfamiliar world of setups and their poor debugability.
Preserving Settings & Data: With regards to saving data and settings in a running MSI instance, the built in mechanism is basically to set properties using Session.Property (COM / VBScript) or MsiSetProperty (Win32) calls. This allows you to preserve strings inside the MSI's Session object. Sort of global data.
Note that properties can only be set in immediate mode (custom actions that don't change the system), and sending the data to deferred mode custom actions (that can make system changes) is quite involved centering around the CustomActionData concept (more on deferred mode & CustomActionData).
Essentially you send a string to the deferred mode custom action by means of a SetProperty custom action in immediate mode. Typically a "home grown" delimited string that you construct in immediate mode and chew up into information pieces when receiving it in deferred mode. You could try to use JSON-strings and similar to make transfer easier and more reliable by serializing and de-serializing objects via JSON strings.
Alternatives?: This set property approach is involved. Some people write to and from the registry during installation, or to a temp file (in the temp folder) and then they clean up during the commit phase of MSI, but I don't like this approach for several reasons. For one thing commit custom actions might not run based on policies on target systems (when rollback is disabled, no commit script is created - see "Commit Execution" section), and it isn't best practice. Adding temporary rows is an interesting option that I have never spent much time on. I doubt you would be able to easily use this to achieve what you need, although I don't really know what you need in detail. I haven't used it properly. Quick sample. This RemoveFile example from WiX might be better.
Related
I'm trying to develop C++ application for a client. So far, i have added the basic functionalities and it works as expected but i will likely to gradually grow the application in future (i.e. adding more feature to it) and the client will likely to update those feature in their app. Now my questions are the following:
For adding feature, i have decided to add features to a dll and the client will likely replace the old dll with the new one (in order to use latest features). Is there a better approach for updating C++ app?
Why some developer use ordinal values instead of function names while exporting symbols, whats the benefit of using ordinal values other than less binary file size ?
I don't want my client to recompile/link the app, i just want to keep the updating process as smooth as possible. Need advice.
P.S:
Environment = Windows + Visual Studio
#Vasilij way is the way to go. If you update only de DLL, how you application will know that there are new functions to call? You have to dynamically adapt your menus and so on.
Just create an exe stub that runs the real application (may be in a subprocess it can kill) and update the whole app (not the stub) and DLLs when necessary. That stub can check for updates also and suggest the restart after downloading.
I have a .msi file created by Wix toolset, used to install 5 drivers. And I have a setup application to launch the .msi by CreateProcess with msiexec.exe command, and provide an UI. Currently, my requirement is get the detailed result of the installation – which drivers installed successfully, which failed. Since I can just get the result of CreateProcess, how can I retrieve the detailed result from the installation? Very appreciate if you can provide some information on this issue.
I created the .msi file with the difx:Driver flag like below:
<difx:Driver AddRemovePrograms="no" DeleteFiles="no" ForceInstall="no" Legacy="no" PlugAndPlayPrompt="no" />
An MSI-based setup is transactional. It either all works or all fails and rolls back the system to its previous state. It seems that you have made a choice to defeat this paradigm and have it partially succeed leaving some drivers installed and others not.
It also appears that you have suppressed the installer's UI so that error information cannot be found.
I have two recommendations:
Don't use CreateProcess() and the "fire and forget" model. Use MsiSetExternalUIRecord with this model:
https://msdn.microsoft.com/en-us/library/windows/desktop/bb309215(v=vs.85).aspx
There are C# p/invoke equivalents out there too. If you don't want to show all the UI then just collect the error messages and show them to the user if that's the goal. That's the only reliable way to get the actual error messages. This is the supported way for you to own the UI and collect only the messages that you think are important.
Allow a failed driver install to fail the entire install and roll it all back. It might actually be like this already. If the install partially succeeds and four drivers are not installed, what's the plan? You can't run the MSI again because it will go into repair/maintenance mode. If the user needs to fix something and do the install again then the product needs to be uninstalled anyway.
You can retrieve the verbose installation log using the /L*V parameter:
msiexec /i "C:\MyPackage\Example.msi" /L*V "C:\log\example.log"
You can read more here.
The general structure is:
msiexec.exe [/i][/x] <path_to_package> [/L{i|w|e|a|r|u|c|m|o|p|v|x+|!|*}][/log]
/L - enable logging
i - include status messages
w - include non-fatal warnings
e - include all error messages
a - mention when an action is started
r - include action-specific records
u - include user requests
c - include the initial UI parameters
m - include out-of-memory or fatal exit information
o - include out-of-disk-space messages
p - include terminal properties
v - verbose output
x - include extra debugging information
+ - append to an existing log file
! - flush each line to the log
* - log all information, except for v and x options
Another simpler method, instead of parsing the log, would be to write a small C# custom action to check if the drivers are installed on the machine.
You need to schedule that custom action close the end of the installation process, as deferred (not immediate).
You can generate a log (as suggested by Harsh) or you can create a custom action (either deferred as suggested by Bogdan if you are using the method he suggests) or sequenced after InstallFinalize (if you have some other method that doesn't require elevation), but that custom action would probably need to use some sort of IPC to communicate what it finds back to your program.
One possibility for IPC might be the MsiProcessMessage function in your custom action with the INSTALLMESSAGE_INFO message type (what you send will also show up in the log) that you can receive in your application, but that will require using the MsiSetExternalUIRecord function which will require replacing your CreateProcess calling msiexec with something from the Installation and Configuration Functions section of that page.
Or if writing custom actions isn't where you need to go it may be easier for you to call MsiGetFeatureState or MsiGetComponentState with MsiOpenProduct, assuming that gives you the granularity of detail you're after.
I'm trying to make one of my QML apps "offline capable" - that means I want users to be able to use the application when not connected to the internet.
The main problem I'm seeing is the fact that I'm pretty much pulling a QML file with the UI from one of my HTTP servers, allowing me to keep the bulk of the code within reach and easily updatable.
My "main QML file" obviously has external dependencies, such as fonts (using FontLoader), images (using Image) and other QML components (using Loader).
AFAIK all those resources are loaded through the Qt networking stack, so I'm wondering what I'll have to do to make all resources available when offline without having to download them all manually to the device.
Is it possible to do this by tweaking existing/implementing my own cache at Qt/C++ level or am I totally on the wrong track?
Thanks!
A simple solution is to invert the approach: include baseline files within your application's executable/bundle. Upon first startup, copy them to the application's data directory. Then, whenever you have access to your server, you can update the data directory.
All modifications of the data directory should be atomic - they must either completely succeed, or completely fail, without leaving the data directory in an unusable state.
Typically, you'd create a new, temporary data folder, and copy/hardlink the files there, and download what's needed, and only once everything checks out you'd swap the old data directory with the new one.
Letting your application access QML and similar resources directly online is pretty much impossible to get right, unless you insist on explicitly versioning all the resources and having the version numbers in the url.
Suppose your application was started, and has loaded some resources. There are no guarantees that the user has went to all the QML screens - thus only some resources will be loaded. QML also makes no guarantees as to how often and when will the resources be reloaded: it maintains its own caches, after all. Sometime then you update the contents on the server. The user proceeds to explore more of the application after you've done the changes, but now the application he experiences is a frankenstein of older and newer pieces, with no guarantees that these pieces are still meant to work together. It's a bad idea.
I am writing an application on Linux which requires me to catch system events like:
System reboot
User 'xyz' logs in
'xyz' application crashes etc.
and need to execute some functionality based on that. For e.g.:
Run backup script
Run recovery program etc.
Can anyone please tell me how to catch system events in C/Linux ?
P.S: I am not talking about 'file system' events here :P
There is no concept of "system event". You need to specify which events you need to handle and implement appropriate mechanism for handling each:
System startup: The init process calls scripts from /etc/init.d during startup. The exact infrastructure differs slightly between distributions, but Linux Standards Base System Initialization should generally work on all.
User login/logout: The LSB also defines interface to the Pluggable Authentication Modules library. You can implement a shared library that will be called during login (and also other actions that require authentication and authorization). Depending on what you want to do there may already be a module that will work for you, so try looking for it first. In either case I don't think there is distribution-independent way of installing it and even on given distribution you have to consider that administrator might have made custom modification, so the installation will need manual intervention by the administrator.
Application crashes: You would have to instrument it.
I think you should consider reading systems logs - everything you ask about is logged to the syslog (for standard configuration). If your system uses syslog-ng, then you could even configure it to write directly to your program, see http://www.syslog.org/syslog-ng/v2/#id2536904 for details. But even with any other syslog daemon, you can always read file (or files) from /var/log just like tail -f does, end react on particular messages.
I'm not sure about catching application crashes - there's a kernel option to log every SIGSEGV in user processes, but AFAIK it is available only on ARM architecture - last resort would be to instrument your application (as Jan Hudec pointed out) to log something to syslog.
I use IShellLink to get the target path of a shortcut. Most of the time it is good, but I am missing some of the files once in a while. I read somewhere that the Integrity Priority could be an issue. See Integrity Priority here - http://msdn.microsoft.com/en-us/library/bb625960.aspx
My question is - if I change the integrity priority of all the dll on my development machine, then build an install build with these dll's, and then move the install-build to another machine and install the program there; will the medium integrity priority I set persist on the new machine. Or I have to write a script to change the integrity priority after I install the program.
I am hoping I dont need to do anything after the install.
I don't know the IShellLink functionality very well so I'll try to address this from the Windows Installer point of view. ( Assuming that by referencing the installshield tag that you are using MSI. )
MSI uses the Shortcut table and if on Win7/Server2008R2 the ShortcutProperty Table. This article Application User Model IDs (AppUserModelIDs) has a section that says:
In the System.AppUserModel.ID property of the application's shortcut
file. A shortcut (as an IShellLink, CLSID_ShellLink, or a .lnk file)
supports properties through IPropertyStore and other property-setting
mechanisms used throughout the Shell. This allows the taskbar to
identify the proper shortcut to pin and ensures that windows belonging
to the process are appropriately associated with that taskbar button.
Note The System.AppUserModel.ID property should be applied to a
shortcut when that shortcut is created. When using the Microsoft
Windows Installer (MSI) to install the application, the
MsiShortcutProperty table allows the AppUserModelID to be applied to
the shortcut when it is created during installation.
The MsiShortCutProperty table is pretty new and I haven't really had any developers come to me wanting to leverage it yet so I haven't dug into the details of what all the various properties that can be set are. However, I suspect this is the road you need to go down.