Start 64bit process during 32bit installer to modify 32bit and 64bit .NET machine.config

I have created an ADO.NET data provider that is built using AnyCPU. When referenced directly it works fine on both 64 and 32 bit Windows OS. However, in my installer, I register my DbProviderFactory with the .NET machine.config and place my assemblies in the GAC so users can access the data provider through System.Windows.DbProviderFactories. This works great as long as the application is running as 32-bit. It does not work for applications built for x64.

This is what I have found. My installer is targeted for 32 bit. Therefore, my DbProviderFactory only gets added to the 32-bit .NET machine.config. In order for x64 applications to use my data provider through the DbProviderFactories, it needs to be registered with the 64-bit .NET machine.config.

Do I have to have two installers? One targeting 32 and the other 64? All of my assemblies are AnyCPU (because I don't know or care what platform the user's application is).

My somewhat complex solution was this. During the installer, I have custom action that checks if the OS is 64-bit (here). If it is, I want to start a process that runs a 64 bit console app that will add my DbProviderFactory to the machine.config (64-bit). And my installer itself w开发者_JAVA百科ill register with the 32-bit machine.config. I tried and it failed since I cannot have a 64-bit assembly in a setup project that targets 32-bit. However, I am going to try to build the console app using AnyCPU assuming it will run as a 64-bit process on 64-bit OS's.

This is rather messy, but I think it will work. Why is this a bad idea? And why does microsoft say "To distribute a .NET Framework application both to 32- and 64-bit platforms, build two MSI packages, one targeted at a 32-bit and the other a 64-bit computer" (msdn). Will it work since technically all of my assemblies are AnyCPU?

Also, I'm using .NET 3.5

To answer my own questions:

1) I do not need 32 and 64 bit installers. However, this is only the case because all of my assemblies are AnyCPU.

2) It's not a bad idea, rather, it is a good idea because I only have to distribute one installer to clients, and it magically preforms extra install actions for 64-bit machines.

3) I think M$ says to have both installers if the assemblies or included references are explicitly built for 32 or 64 bit.

The final solution: In my 32-bit installer, I register the assembly in the machine.config. Then I check if the OS is 64-bit (using the link provided my question). If it is, I launch a command line utility (included in my installer) that is built for AnyCPU as a separate process. The utility registers my assemblies in the 64-bit machine.config. This works because the AnyCPU utility only gets started as new process on a 64-bit OS, with the assumption it will default to a 64-bit process. Done.