How to require x86 up the .NET dependency chain when building

Question

We have several projects that use p4.net, a managed DLL, which in turn is dependent on p4dn.dll, a 32-bit unmanaged DLL. This has problems on x64 systems, so I have had to go to each project that uses p4.net and set its processor type to x86.

If I understand the problem right, it's that when .NET loads an exe, it checks for a manifest and if none it does whatever is best for the processor type. Then when it runs into the 32 bit dll, it barfs.

I can go to each project that uses p4.net and mark it as 32-bit. But we have quite a few of these. Also, people are going to continue to make new ones and forget to set 32-bit and then in the future we'll have this problem again when someone else tries to use it on x64.

My question is this: is there a way to have .NET automatically load any app that uses p4dn.dll as 32-bit? Failing that, is there a way for the IDE to detect this and fail to build?

Or is it possible to make a .manifest file that I can put next to p4api or p4dn.dll so that any apps using them will auto run in 32 bit?

Answer 1

CLR checks platform type only if it loads an assembly from GAC. I guess p4dn.dll is contained under the application root folder, so I think you're wrong into your logic.

It seems that p4dn.dll cannot be used when it's running in WoW64 mode and your application is running in x64 mode natively. I think the best way is to compile all your project targeted to x86 (32) platform. Or break it into the parts, so p4dn.dll caller would always be running in WoW64 mode.

Also, you should contact p4net developers to add full x64 platform support.

Answer 2

I don't know of any way to do this automatically. I would recommend you to do the following:

• Train your developers,
• Add this topic to your internal knowledge base and
• Add x64 platforms to your test environments

Additionally, you might think of writing a VS add-in which checks for the correct target platform. But then there might be dynamic creation of COM components, too...

Answer 3

If you have absolutely no other choice you can use corflags as part of an automated build script to mark all of the .NET dlls as x86 - corflags /32bit+ file.dll. Although I think that proper education of developers is more adequate solution.