I am making an installer where I have defined my own installer property. I want to store this property in the registry. As this property is only needed by the installer, I thought that the best location to store it would be:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{PRODUCT CODE}.
I use Installshield 2010 to make the installer.
What I want to know is: Is this possible and how can I do this?
Yes, this is possible. The registry values are formatted, so you can use something like this:
[MY_PROPERTY]
The location you chose is not very good. That key is used by Windows and Windows Installer internally. You can try creating your own key under SOFTWARE, for example:
HKEY_LOCAL_MACHINE\SOFTWARE\My Company\My Application
Related
I want to create a context menu something like the menu in 7-Zip using C#. How can I register the dll using WiX?
Step one is to learn how to do it by hand. This involves creating a Shell Extension, and registering it. Per MSDN, you do this by implementing IContextMenu and listing its CLSID in a subkey of the registry key HKEY_CLASSES_ROOT\ProgID\ShellEx\ContextMenuHandlers. Additionally, after writing that registry key, you have to call SHChangeNotify with SHCNE_ASSOCCHANGED, or reboot.
If your needs are simpler than the 7-zip case, you can likely just register a Verb or File Association instead.
Once you've done this, and tested it on your development machine, you're ready for step 2: make it part of your installer. If you're creating a verb or file association, that's possible with native Windows Installer tables, as exposed through the ProgId, Extension, and Verb elements. If you're registering a shell extension, I believe you have to create the registry keys directly through the RegistryKey and RegistryValue elements.
For more concrete examples of the WiX authoring, see the answers to How to register file types/extensions with a WiX installer? and How to associate application with existing file types using WiX installer?
We have a couple of dlls we like to install using an msi.
In our test environment, we are using regasm -codebase to register the dlls.
As I understand from googling, this is accompliched in an msi project by setting the register property to vsdraCOM.
The problem is that when we run the installer and checks the registry, the codebase path is set to the path the file were in when building the msi.
I'm going to expand on Hans' answer and that link info, and it may be more than a comment can hold.
That reg file will contain the path to the file and the link article recommends using [TARGETDIR], which is basically wrong if the file is not being installed to the application folder. The path to your file should be written as [#file-key] in the reg file that you import. In a VS setup project the file-key will be (just an example) something like _B049230C37DE4B6787C578DCEE30252A. Open your MSI file with Orca, go to the File Table and use the file key in the File column that corresponds to your file name.
That comes from here:
http://msdn.microsoft.com/en-us/library/aa368609%28v=vs.85%29.aspx
the 7th bullet point. It resolves to the file path wherever it is installed to.
The other thing that can be done is to let Visual Studio do its incorrect thing, then go to the Registry table with Orca, find the path and put that [#file key] in it such as [#_B049230C37DE4B6787C578DCEE30252A] and people sometimes do those kinds of updates with a post build script to update the MSI.
None of these are great, but they should work and get you out of using the GAC. VS setup projects really should be using that [#file key] syntax, and it's just a silly bug I assume.
Speaking as someone who's made a full time living writing installs for 18 years, my first suggestion would be to switch to Windows Installer XML. If you insist on using .VDPROJ, I would suggest reading: Redemption of Visual Studio Deployment Projects.
The concept is you use Windows Installer XML to create a merge module and then consume that merge module with .VDPROJ. In Wix, you use Heat to harvest the DLL. It will extract the COM / Regasm metadata and author it as Registry table entries. This provides a nice clean encapsulation using authoring best practices and avoids the need to do any post build hacking of the built MSI database.
During install I would like to create an encrypted string containing the install date and write that to a Registry key.
I know how to create the encrypted string in code, so I don't need help with the encryption part, I just don't know how to get the installer to:
get today's date as a string
call my encryption method on it (from a dll)
write the result to a registry key if the value does not already exists (no overwrite)
How could I do this please?
Dave
If you were using a tool that exposed more of the underlying Windows Installer such as WiX or InstallShield, you'd write a simple custom action that got the time, encrypted it and set a property. Then you would use that property in the Registry table to let the installer write it out during install, remove it during rollback and remove it during uninstall.
However, the project type you are using (and removed from VS2012 FWIW) doesn't support authoring custom actions in an immeadiate execution context and therefore the custom action can't set a property for use by the Registry table.
This means you'll have to write RollBack, Install and Uninstall custom actions yourself and write to the registry value yourself.
I'd also mention that InstallUtil custom actions have a variety of shortcomings. I'd do this either in C++ or I'd use WiX DTF to write a C# custom action that appears as a C++ DLL to the installer.
Using Installshield 2010 and Basic MSI project.
I have an exe that was previously installed by my installer. That exe needs to be running during an installer upgrade. Is there a way to guarantee that the installer won't try shutdown the process? Basically, I would like the behavior to be : If file doesn't exist, lay it down, otherwise ignore it.
I have made the exe a key file in a component and set it 'Never Overwrite' to true. Should this give me my desired behavior ?
Never Overwrite will be used by future installers to determine if the file will be overwritten or not by other MSI packages. Basically, this attribute should have been set for the installed EXE.
A good approach is to use a file search to determine if the EXE exists. The search property can then be used to condition the new component.
Windows Installer doesn't automatically close applications, but it does show a FilesInUse dialog which offers this option to the user.
I have created a deployment project using VS 2005. By default, files are installed in AppDataFolder. There are also 2 string values added to the registry during the installation. These registry values represent the path to some dll files found in the install dir.
When the user chooses the default installation directory everything works fine. But if the user choose another directory, instead of having the registry values with the user selected directory, I still get the default values.
How can I change that? Is it possible to do it during the deployment project creation?
Thanks,
Olivier.
Use reg.exe from command line.
You could call that exe from your program and provide the correct parameters.
reg.exe is included since Windows XP.
So instead of using the [AppDataFolder] property, I should have used [TARGETDIR]