无法在MSI安装程序的自定义操作中编写注册表

Question

I have an MSI installer that installs my Windows Service and in my custom actions I need to write some values into the Registry in the HKEY_LOCAL_MACHINE/SOFTWARE/MYSoftware key.

I am trying to do this and it's not working, but from my Windows Service it's working fine. Can anybody tell me where I am going wrong?

string registryLocaltion = AgentProperties.TMAGENT_REGISTRY_LOCATION
                           + @"\" +AgentProperties.TMAgentVersion;

tmKeyMain = Registry.LocalMachine.OpenSubKey(registryLocaltion, true);
if (tmKeyMain == null)
{
    log.Error("Unable to open registry key " + registryLocaltion);
}

tmKeyMain.SetValue("UseProxySettings", settings.UseProxySettings);
if (settings.UseProxySettings)
{
    tmKeyMain.SetValue("ProxyHost", settings.ProxyHost);
    tmKeyMain.SetValue("ProxyPort", settings.ProxyPort);
    tmKeyMain.SetValue("ProxyUsername",
              GenericHelper.ConvertToBase64Encoding(settings.ProxyUsername));
    tmKeyMain.SetValue("ProxyPassword",
              GenericHelper.ConvertToBase64Encoding(settings.ProxyPassword));
    tmKeyMain.SetValue("ProxyExclusion", settings.ProxyExclusion);
    tmKeyMain.SetValue("BypassProxy", settings.BypassProxy);
}

This code is working fine in my Windows Service, but if I do some thing very similar in my custom action in the MSI installer it doesn't work.

Can anybody tell me where I am going wrong?

Answer 1

You are up against a couple problems. The most obvious problem is that Visual Studio Deployment projects incorrectly schedule custom actions to impersonate the client context. This means in a UAC scenario you won't have permissions. The quick work around is to run the MSI from an already elevated command prompt context.

The second problem is that Visual Studio Deployment Projects abstract / hide the underlying MSI too much. For Custom Actions, it only gives you the options of "install, uninstall, rollback, commit" without exposing any additional settings. It hides the ServiceInstall and ServiceControl tables. This causes you to write a custom action that reinvents the wheel.

See, all your custom action should be doing is performing the business logic and setting properties. Then you should be using the Registry table to set the data based on the properties. This way you leverage as much of Windows Installer as possible and all of it's free transactional / rollback capabilities.

This problem repeats over and over and is why Microsoft killed of the setup project types in VS2012.

If it was my install, I'd be refactoring the design to use AppSearch/Reglocator to read in the data, have a minimalist custom action to do the processing and then use the Registry table to apply the data.

That will require you at a minimum to look at Windows Installer XML to create a merge module that has all of this logic and gets merged into your existing setup project. That takes awhile to learn though.