0

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 will 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

codyzu
  • 541
  • 3
  • 18
  • I'm not sure it will work, since a 32-bit msi installer is launched as a 32-bit process. Which should cause the AnyCPU dll to run as 32 bit (AnyCPU dll running inside a 32-bit process). Hence the need to have a 64 and 32 bit MSI installer. – Chris Chilvers Aug 05 '11 at 12:30
  • I want to have the 32-bit msi installer start a _new_ process that executes an AnyCPU console application (exe), but only if we are on a 64-bit OS. In theory this new process should run as a 64-bit (and have access to the 64-bit machine.config). – codyzu Aug 05 '11 at 12:38
  • MSI is heavily bitness dependent. Maybe they'll improve that some day, probably around the time that nobody is installing 32-bit operating systems anymore. Just running two installs is a very low pain solution. To you anyway. – Hans Passant Aug 05 '11 at 13:02

1 Answers1

1

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.

codyzu
  • 541
  • 3
  • 18