Error 1402. Could not open key: UNKNOWN\Components\…

Recently, I was developing a setup package whose uninstall actions were broken. During testing, I could install the package but wasn’t able to uninstall it. To remove the package and go on with development, I used the Windows Installer Cleanup Utility. So far, so good – I thought.

Next time I tried to install the package, I got the error “Error 1402. Could not open key: UNKNOWN\Components\[Big number]\[Big number]”. What happened? Continue reading

Windows Installer Cleanup Utility (MSICUU2) Discontinued

When you develope installer packages, you might face the situation where you install you product for testing purposes but cannot uninstall it because the uninstall mode is not ready, yet. Mircorosft used to offer a tool called Windows Installer Cleanup Utility than removed all file sytsme and registry items added during setup process without needing the actual installer.

Unfortunately, Mirosoft has disconstinued  this utility. Fortunately, others still offer the tool for download. For example:

Warning: this tool might get your registry messed up. Be prepared to get into trouble when using it.

Windows Installer Custom Actions: Moving Properties from Immediate to Deferred Execution.

The Windows Installer works in two phases: the acquisition (or immediate) phase and the execution (or deferred) phase. The user enters required data (e.g. the installation target path) in the acquisition phase and then the data is used to actually perform the installation in the execution phase. So simple this sounds, actually doing this with custom actions is not that straight forward as you might think.

Custom Actions in the immediate phase can access (read and write) session properties. The following example is a custom action that sets the session property USERDATA to the value “I am data”.

Continue reading

Debugging Custom Actions in Windows Installer

In Visual Studio, you can add Setup Projects and WiX projects. Especially WiX projects are very powerful. Unfortunately, you cannot run the generated Msi-Package in debug mode to be able to step into your own custom actions. Well, the solution is simple: just add a call to the Debugger.Launch method wherever you want to step into your code. Example:

public static ActionResult MyCustomAction(Session session)
    // Start debugging here:

    session.Log("Begin CustomAction");

    // Actual action here...

    session.Log("End CustomAction");

    return ActionResult.Success;

Now, when the Msi-package is executed normally, the debugger will launch as soon as the custom action is called. At hat point, the Visual Studio Just-In-Time Debugger will pop up.

netsh http add sslcert "the parameter is incorrect"

In the last post, I referenced a blog post by Dominick Baier about how to set up WCF over SSL. Following his instructions and copying his samples, I got an error when I tried to map the SSL certificate to the WCF service port using netsh http add sslcert. The error stated that “the parameter is incorrect”. I searched for that error on the internet and found lots of people having the same issue. I searched hours and hours and hours… until Thomas Stensitzki came along and noticed that I had one parameter followed by a colon instead of an equality sign!

This is what I originally used:

 netsh http add sslcert ipport: certhash=a1540c1ddecc36f9c30e9eb1bad655b63b5cbc03 appid={74B2A5EB-5FD8-4B89-A69F-E5D038D5E287} 

Notice the colon behind ipport. THAT was my error. Of course, the above line has to look like this:

 netsh http add sslcert ipport= certhash=a1540c1ddecc36f9c30e9eb1bad655b63b5cbc03 appid={74B2A5EB-5FD8-4B89-A69F-E5D038D5E287} 

By the way: I used Windows Sever 2008 R2

SSL Needs Certificates

There are many blogs out there describing how to configure a WCF service to use SSL (for example this one by Dominick Baier or this one at Microsoft’s that also shows how to do it in code). In short, here’s an example for such a configuration: Continue reading

Dynamically Configuring WCF Services

Usually, WCF services are configured either programmatically or within the applications configuration file. Sometimes there are scenarios where the WCF service must be configured dynamically, i.e. at runtime. Of course, this can be done in code. The wider the range of possible configurations gets, the harder it gets to configure the service in code because every single possible configuration item must be coded. I guess that the reader (you) landed on this blog page because of this issue so I won’t spend much time explaining the pain with that.

So, it would be great to have the option for XML configuration snippets to be loaded into a service. By doing so, these snippets can be saved in a database or created at runtime. Also, these snippets are more compact than code configuration, which makes them easier to read and to write. But how can we do that? Continue reading