Now for Windows, too.

http://www.oracle.com/technology/products/database/oracle11g/index.html

Now, Rob Mensching doesn't like Windows Installer Custom Actions.

And I'm starting to feel why.

Apart from MSI custom actions with their immediate/deferred idiosyncrasy being not only a pit-of-despair but rather an abyss, there is something much more fundamentally but subtly wrong about them.

Rob and others are pointing out that it's JScript or VBScript as well as managed code that you probably can't ever get run  successfully in a custom action.

But actually, it is every dependency on some kind of framework or runtime library that can and will cause your custom action to fail.

What I'm saying is, if you're using Visual Studio 2005 to write a custom action dll, better not use the C-runtime or link to it statically. The same is true for MFC, ATL and whatever else you might think you need that does not come with the operating system. MSVCRT8 is not a Windows component.

Even with "/lvx*" does MSIEXEC not log loader failures, so you might be debugging for a while before you find out why it works on your machine but not at your customer's.

Sure, you can install MSVCRT8 as a pre-requisite.

Just make sure it fits the target operating system. And it's successor. Plays nice with SxS. And doesn't conflict with hotfixes, patches, updates, service packs, language packs and the next version of Windows, Office, Visual Studio and whatnot, including but not limited to every other software package from anybody else who too think merging in some version of the C-library into the installation was a clever idea.

Good luck with that.

http://robmensching.com/blog/archive/2007/04/19/Managed-Code-CustomActions-no-support-on-the-way-and-heres.aspx

As you might know, you can't xcopy-deploy a distributed application, unless you make your customers use the same computer and domain names, and possibly user names.

Now, if you can arrange for that - alright, type ESC-q and exit in your command prompt now.

So, we know setup is more than xcopy. And the .NET framework configuration environment is made up of several layers of XML-based config files.

Now I need to tweak some of them when installing an application or, worse, a plug-in for an existing application, say a Data Processing Extension for Microsoft SQL Server 2005 Reporting Services.

And how much support do I find in the platform for making modifications to these files?

See? That's what I don't like.

But hey, it's just XML! And I can use the installutil tweak that comes with the Visual Studio deployment projects!

Let's just say, installers created this way are not among the most beautiful nor the most resilient.

The best you can do with them is run them thru dark to get a WiX based installer out of it.

It is always a relief to see someone has already fought your struggles for you:

Things that seem to be impossible (or very difficult, or really bad ideas) to do with MSI

Can’t specify an order for LaunchConditions or AppSearches.

After hours of hopeless trying, I can confirm this. And: There is no workaround.

So, why would I need this?

To lookup the configuration files for Reporting Services.

Those have to be modified to add extensions, the rsreportserver.config to add the extension assembly, the rssrvpolicy.config to grant FullTrust.

I thought it was easy with WiX, using the XMLFile standard custom action.

It isn't.

1. Find the internal instance name for Reporting Services. This is in HKLM\SOFTWARE\Microsoft\Microsoft SQL Server\Instance Names\RS. The key name is the "official" instance name and has to be specified by the Administrator, because we only know the most common ones: MSSQLSERVER (default instance) and SQLEXPRESS. A RegistrySearch will return something like MSSQL.2 or MSSQL.3 in the parent property (named maybe SSRSINSTANCE).
2. Retrieve the actual program folder by doing a RegistrySearch for HKLM\SOFTWARE\Microsoft\Microsoft SQL Server\[SSRSINSTANCE]\Setup. Now this has an order dependency on RegistrySearch #1. And therein, as the Bard would tell us, lies the rub.

But even if this would work reliably, we would then have to do the two file searches which depend on the result of #2. Can't do that too. MSI would claim the freedom to do these searches before #1 and #2.

Re-ordering them manually in the MSI database using Orca is pointless.

What's more, the XMLFile standard custom action is so utterly unusable for the purpose of adding an element with a name that already exists in the file to be modified, that developing a specific custom action is almost inevitable.

But remember: VBScript (and Jscript) MSI CustomActions suck.

Yesterday I was working on a friend's computer when clicking a link in Yahoo's search results produced popup warnings, strange alert boxes and opened obviously rogue web sites in Internet Explorer 7.

I blamed Yahoo, but the same problem affected Google.

I thought the web site for the link was having a cross-site scripting issue or had been hacked, but adding it to "Restricted Sites" and checking with Fiddler2 cleared it from my allegations.

I checked the extensions running in Internet Explorer and verified the manufacturers' signatures (Google Toolbar is not signed - what are they thinking?)

Again, nothing suspicious there.

OK, we need to call in the troops.

Rootkit Revealer, Autoruns, Process Explorer, all from SysInternals, ahem, Microsoft Technet.

Rootkit Revealer check: Negative.

Autoruns: Some binaries not signed/verifiable, including "wmfhotfix.dll" in AppInit.

Process Explorer: Verifying the signatures of the modules loaded into the Internet Explorer process showed it: wmfhotfix.dll is the culprit. It is a virus in the disguise of an unofficial patch for the WMF vulnerability back from the days.

Now, wmfhotfix.dll is loaded into almost every process and can't easily be removed.

Autoruns to the rescue:

Close all applications, stop as much services as possible, start Autoruns and disable and delete the AppInit entry for wmfhotfix.dll. Close Autoruns. Count to ten (i.e. wait for the registry cache to flush to disk), power-cycle the machine.

Delete the wmfhotfix.dll from the system32 directory. Scan your system for other occurrences of this file and delete those, too.

Lessons learned:

1. Unofficial patches are just viruses waiting to be installed. You can't trust any binary unless it's signed or comes with some other means of verification.
2. Rootkit detection and automatic binary verification should be at the core of any virus scanning software. At least one (free) product I checked failed to detect the badware and didn't even warn about wmfhotfix.dll being loaded into their processes, too.
3. It can happen to you. Maybe it already has.