Hi I'm hoping this isn't too vague to get some help with!
We've searched for several days now and cannot get an answer that works. We use Advanced Installer for different projects and need a sensible way to encrypt the connection strings for sites that do NOT use windows authentication into the sql server.
We've tried encryption after installation, running custom DLL's in Advanced Installer and all sorts. Nothing works because of Microsoft's frustrating permissions fortress around Program Files folder.
Does anyone know of a decent way to do this that does not involve Windows Authentication on the database?
Any help would be very warmly appreciated. As you can imagine, this request is made as a last ditch attempt to find a good solution.
I'm rather shocked that there isn't one that is fairly standard - but if you don't use Windows Authentication on SQL server, I don't see one as far as I can tell.
Thank you in advance for any help offered!
Warmest regards
Richard
Edit: From what I understand the encrypt/decrypt can only be done on the same machine - preventing me from shipping an encrypted app.config. The key is based on a machine.config that differs by machine.
I finally found the key to solving this with Advanced Installer - it can't run DLLs that are built in managed code, so you need to use another toolset called Wix to create a DLL that Advanced Installer can use. The instructions for that can be found here: https://www.advancedinstaller.com/user-guide/qa-c-sharp-ca.html
For the encryption we're after, this is the function I created as a custom action in the Wix project (for clarity, minus the try-catch, file check and logging that our actual code has):
<CustomAction()>
Public Shared Function Encrypt(session As Session) As ActionResult
Dim config As Configuration = ConfigurationManager.OpenExeConfiguration(session.CustomActionData("ExecutablePath"))
Dim section As ConnectionStringsSection = TryCast(config.GetSection("connectionStrings"), ConnectionStringsSection)
If section.SectionInformation.IsProtected Then Return ActionResult.SkipRemainingActions
section.SectionInformation.ProtectSection("DataProtectionConfigurationProvider")
If Not section.SectionInformation.IsProtected Then Return ActionResult.Failure
config.Save()
Return ActionResult.Success
End Function
When you build the project, it generates two DLL files: a normal .dll and a .CA.dll. In the Advanced Installer project, add the .CA.dll to the included files (preferably as a temporary file since it's only needed during installation). Then go to custom actions, add a new "Call Function From Attached Native DLL" action, point it at the same .CA.dll file as you selected to add to the project, and then set up the rest of the action like this:
(attached image)
...where [#ConfigEncryptionTestProgram.exe] should be replaced with your executable!
The important bits here are the position of the action in the sequence (just before Finish Execution), the execution time (commit), and the execution option that makes it run with privileges so that it can get around Microsoft's restriction on modifying files in the Program Files folder.
I have done this and have written not a single line of real code.
I have just added to the installer a custom action for encryption:
Launch File (With Sequence)
File to launch: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe
Command line: -pe connectionStrings -app /myappname
Hide program's window
You would set "Run as administrator" (not applicable to us, because our installer completely runs as administrator)
Execution Time: Immediately
Wait for custom action to finish before proceeding
DO NOT Fail installation if custom action returns an error
and another one for decryption, same settings, but with command line -pd instead of -pe.
And then I have moved the decryption before the "Dialogs->Searches" stage, and the encryption behind the "Execution->InstallFinalize" stage:
Related
Is there a way to set a property value to the formatted install date/time?
I'm in the process of creating an MSI installer for an old VB6 application we still depend on (yes, I know, upgrade before it dies).
I'm trying to add a backup folder for the user data files in the install-folder (not my application design, nor my application). Unfortunately every user of this application has their own copy of the data file installed on their system (dedicated machines per user), and the installer has the default file. I would like to create a backup folder so that I can manually (if necessary) go back and retrieve previous versions of the file.
What I'm thinking is
c:\program files (x86)\app*.mdb => c:\program files (x86)\app\backups\201804091125
This will be rushed. Please tell me what is not clear.
Custom Action: In order to implement exactly what you describe, you generally need a custom action. This is always unfortunate since they are very error prone: Why is it a good idea to limit the use of custom actions in my WiX / MSI setups?
Alternative?: If you ask me I would install the database in a component of its own, make the file the key file and set the component to permanent and never overwrite if key path exists.
In the WiX source: for the WiX component element, set these attributes: Permanent="yes" NeverOverwrite="yes"). I am not 100% sure what will happen if you do something stupid such as setting REINSTALLMODE="amus" during installation (force overwrite all files regardless of version). It has been a while since I tested the NeverOverwrite flag. But for normal deployment done the regular way the database file should be left alone and not overwritten.
Custom Action Overview: There are properties called Time and Date that are automatically set in the installer, but the Date property will generally contain characters that are illegal in path names. It is possible to just get the properties and replace the illegal characters. However, the date separation characters are probably different based on regional settings and hence hard to predict. Your code could get messy quickly and testing would be challenging (potentially many locales to test depending on distribution scope - a truly globally capable package is challenging).
I would rather get the date and time some other way - via some programming API call where I can determine what format the data comes back in. You also need to run this custom action elevated in deferred mode to ensure it doesn't fall over with access denied (insufficient user rights for operation). This is always quite a bit of clunk to set up and get working. Maybe try the alternative approach first?
I have long considered adding a custom action to abort the install if REINSTALLMODE="amus" has been specified. I would prefer that and the alternative approach described with "never overwrite" to a custom action doing all this copying.
I am trying to do a custom action at the time of msi installation. But the dll required for my custom action is depends on other dlls. At the time of installtion it is giving the error like "a dll required for this install to complete could not run".How can I load the dependent dll files for this custom action to run properly.
The code that I am using is
<CustomAction Id='CheckingPID' BinaryKey='CheckPID' DllEntry='ValidateKey' />
<Binary Id ='CheckPID' SourceFile='$(sys.CURRENTDIR)\LicenseKeyClient_32d.dll'/>
<Binary Id ='CheckPID2' SourceFile='$(sys.CURRENTDIR)\curllib.dll'/>
<Binary Id ='CheckPID3' SourceFile='$(sys.CURRENTDIR)\libsasl.dll'/>
<Binary Id ='CheckPID4' SourceFile='$(sys.CURRENTDIR)\openldap.dll'/>
The files that you add in binary table usually get extracted with temporary names during the installation, so your DLL will not be able to locate the other DLLs you add next to it.
A workaround is to add those DLLs as normal files in the Temp system folder and delete them when the installation ends. This has the limitation that you need to set your custom action as deferred, so it executes after the files are installed, thus your DLLs get copied to Temp folder.
I don't know if wix has a support for temporary files, similar with the one present in Advanced Installer, but if not you could try to write a custom action to simulate it. Basically what Advanced Installer does is to extract those files in the Temp folder the moment the MSI is launched, and also deletes them when the installation is complete. This has the advantage that you can use the temporary files and in immediate custom actions, i.e. well before the files from your package are installed.
Despite Bogdan's excellent answer, allow me to add my 2 cents:
It looks like you are dealing with some form of license key validation? The best way is generally to deal with your license keys in the application itself, unless you want it written to HKLM instead of HKCU - in which case you might need the temporary admin rights generally acquired during installation.
You can also open a HKLM key for writing during setup, and write it from the application though this is generally frowned upon security-wise. This allows you to write a single license key for all users directly from the application.
The application features more flexibility and control of the process of registering your license key, and crucially an easy way to run the process again. From my perspective this is almost always needed for a serious application - often due to trial versions with the eventual need to register the license key at the end of the trial period from within the application itself - instead of uninstalling the application and reinstalling, or running the setup in repair / maintenance mode - which seems extremely clunky.
I have described this issue previously in some more detail: Reasons to deal with licensing in the application rather than the setup.
I'll also add that WiX DTF .NET custom actions really simplify this problem by allowing you to embed content into the self extracting custom action package and make them available in the current directory at runtime. Very easy.
But yes, Glytzhkof is correct. Any licensing / DRM done inside of an MSI is easily defeated. It's best to do this in the app or both. For example I've worked at companies where it's a share responsibility. You can enter one now or later. I've also worked at companies where the license key had bits embedded in it that drove feature selection. It gets complicated fast so try not to have to go down that road.
To give you a background - I have a 4 MSI's which comes from our vendor and this has to go to our company servers (we are looking at around 3500 servers). As of now, my counterparts are managing this using vbs, ps1 scripts. But the problem with the script is that everytime an update comes we have to worry about uninstalling the existing package before running the new one and a ton of hardcoding.
I want to automate the whole process (with very less hardcoding) by setting up a WIX script to package all the 4 MSI's together. I read about the WIX bundle and used that to create a single MSI. But now there are lot of a variables to be passed to the 4 MSI's, so I thought of using custom actions to set these variables based on the environment/machine where the MSI is running. But I cant make custom action to work? Am i missing something?
A little bit of googling and I saw something like there are no CustomActions in Bundle? can someone confirm?
Also if there are no CA's what are my options? how can I manipulate the variables to be passed on to the 4 MSI's? Most of them needs to be set based on the machine its being run (like install path, user id's, app pool id's etc).
There is a fourth option, a useful lightweight hack, identified by Vijay Kotecha (see http://vijayskotecha.blogspot.com/2013/07/wix-bootstrapper-custom-action.html),...
Essentially, build an <ExePackage> around a pass-through .bat or .cmd batch file. The batch/command file contains the single line '%*' which re-executes all of the command line arguments as a first class command.
Thus:
<ExePackage ... SourceFile="SourcePath\WixCustomAction.cmd"
InstallCommand="my_custom_action.exe my_custom_parameters" />
<ExePackage ... SourceFile="SourcePath\WixCustomAction.cmd"
InstallCommand="my_next_action.exe my_next_parameters" />
Where WixCustomAction.cmd is a file containing only '%*'.
These <ExePackages> can be placed into the <Bundle><Chain> successively as needed using different InstallCommands as needed.
As I see it, you have three options:
Depending on what information you need, you can use the WixUtilExtension to perform simple tasks such as reading registry keys and performing file searches, which you can then pass the results to your installation packages as properties.
Implement custom actions in the individual installation packages themselves (not in the bundle).
Write your own custom bootstrapper application to determine all the properties you need to set, and then pass them to your installation packages. This is more complex than the #1 and #2, but if your interested the following links should get you started:
introducing managed bootstrapper applications and
write a wpf wix installer
I have a small VB .Net application that, among other things, attempts to substitute system wide typed text by the user(hotstrings concept). To achieve that, I have deployed 'ahk2exe' and 'AutoHotkeySC.bin' with my application and did the following:
When a user assignes a new 'hotstring':
Kill 'hotstring' exe script file if running
Append new hotstring to the script file (if non exist then create a new one)
Convert edited/new script file to exe (using ahk2exe)
Run the newly converted script exe
(somewhere there I also check if the hotstring has been already assigned)
However, I am not totally satisfied with this method for the following two main reasons:
The extra resources deployed with the application.
Lag: The time it takes for the system to kill the process and then restart it takes a minimum of 5 seconds on my fast computer and more on other computers. That amount of time is much more than the time it takes the user to assign the hotstring, minimize/close the window and then test his/her new hotstring. When the user does so initially with no success they will think the process failed. So this method is not very good for user experience.
So, I am looking for a different method or implementation. May be using keyboard hooks? Or maybe adding a .dll library that achieves the same. Are there any resources you know about that might help (free or commercial)? What is the best way to achieve my desired goal?
Many thanks for your help.
Implementing what Autohotkey does would be a pretty non trivial task.
But I'm pretty sure that AHK supports an "autoreload" option for scripts
googling "autohotkey auto reload" turned up several pages discussing that very concept. IF that worked, all you'd have to do is update the script file and that's it, AHK should automatically reload the script.
The installer I'm writing using WiX 3.0 uses a RegistryValue element to modify an existing registry value (originally written by our main product). I'm trying to figure out a way to restore the registry value when the user uninstalls my utility. I'd like to avoid using a custom action, but that might be the only recourse? TIA.
I did this. The registry value in question was the application associated to a file extension, but it could be any registry value.
My first idea was to use a "custom action" for install and uninstall to preserve
and restore, respectively, the associated regy state. This
seemed simple enough.
I created a setup project in VS2008 and built the CA's as javascript files. The "on install" script grabbed the existing regy value and stashed it into a well-known place. The "on uninstall" script would look in the well-known place, and then put the value found there, back in the original location.
Easy, right?
There were two problems:
the script that ran during install, to preserve the pre-existing registry value,
runs AFTER the registry has already been updated
with the values for the newly installed thing. So it preserved the new setting instead of the setting that was there before the MSI ran. Not useful.
The script that runs during uninstall, runs AFTER the registry values, and in fact the entire directory subtree,
have been deleted. Including the stashed value. So it had lost its state.
To solve that I wrote another script that
re-orders the custom actions so they run at the proper times.
There's actually one more twist. Obviously, the "Restore" script (on
uninstall) won't work if it is run after the registry entries for the app have been deleted. I can't remember now, why... but I also determined that this script could not run before that. Somehow that wasn't working either.
So, I modified the MSI to run the restore script
twice. In phase 1, it transfers the stashed value to a "parking lot" in the registry.
Then the application's Keys and Values in the registry get deleted, but the parking lot remains. In
phase 2, outside the transactional protection, the restore script retrieves the state from the parking lot, restores
the file association, and then deletes the parking lot.
I can't remember exactly why I needed to do this in 2 steps, but I remember fighting with it for a while before coming up with that solution.
The way it works in development:
set the on install and on uninstall CA's in the VS project
build the VS Setup project
run the post-processing script that modifies the MSI.
When using the MSI, it's a little more complicated than I originally thought but it works.
If you are using WiX, you may have more control over the time and ordering of the steps, so may not need that post-processing step.
Finally, you said you wanted to avoid a CA. To me, CA's are avoided because they are painful to produce in C++, and producing them in .NET is often inappropriate. But, it's pretty simple to use Javascript for CA's. Some people think script is the wrong tool for the CA job. I think that's wrongheaded. I think script is a very good tool for this purpose. And once you can accept script as a good tool, then you don't need to hold your nose about creating a custom CA.
The registry table is incapable of writing a registry value during an uninstall so it is correct that this must be done via custom action. I am of the opinion that using script is bad. Whether you choose to listen is up to you. I can tell you that just the other day I was called into to trouble shoot a situation where some wrote a vbscript CA that was failing because the file system object had been unregistered as part of a security lockdown process.
I suggest C++ or C#/DTF depending on your needs.
Faced with similar issue, need to update the registry value on install and restore to previous value on uninstall.
Is the only solution possible is creating a custom action for this purpose?
I found a extension for wix that has fucntions for this purpose
link to wix extensions