The good news up front:
You can use the NetOffice AnyCPU assemblies in all scenarios.

This is true regardless wether you develop for a 32Bit Office application or a 64Bit Office application, even independent on which platform these are installed. If your assembly is a standalone application (.exe) or is being loaded by one, you can compile your assembly as AnyCPU without worries. If your assembly is a COMAddin that  is being loaded by a 32Bit Office application, you can still compile it as AnyCPU. If you develop a COMAddin that is being used by a 64Bit Office application, you have to compile your assembly as x64. If you wart to support 32Bit and 64Bit Office applications, you may need to provide a second x64-compiled COMAddin. This behaviour is the same in all scenarios(interop,vsto or netoffice). A 64Bit application can only load 64Bit Dll's.

If you use a 64Bit Office for testing on your development system and you want to register your COMAddin while compiling (Register for COM Interop), you need to keep in mind that some older versions of Visual Studio call the 32Bit registration in that case. In this case, you get the following error:

"File <path to assembly> is not a valid assembly".

You can read a workarround by Microsoft here:

Last edited Jul 8, 2011 at 9:21 PM by SebastianDotNet, version 5


jeromeTou Feb 20, 2012 at 9:18 AM 
This is a very wonderfull project, thank you.

I have to load a plugin in 32 bits and 64 bits environnent and in my experience, the addin seems to works perfectly with only one compilated target, the AnyCPU.

I'm using RegAsm.exe to load addin in Office. The only difference on client is :
I load the addin.dll with the 64 bits version of RegAsm.exe.

Hope this will help.