The Visual Studio team is designing the runtime components for Office 2010 so that your Visual Studio Tools for Office 2005 and Visual Studio 2008 .NET addins, document solutions and spreadsheet solutions will run on 64-bit Office 2010. These runtime components will ship with Office 2010, so your end-users won’t even have to download a new runtime! How easy is that? There are a few rare exceptions that I’ll discuss in this blog entry.
The miracle of managed code allows you to write C# or Visual Basic .NET code that compiles to “Any CPU” using the Compile setting in your Visual Studio project. Your code compiles to MSIL with Visual Studio, and then at runtime it gets JIT compiled to the correct chip set, either AMD, Intel, 32-bit or 64-bit. The first exception to this wondrous technology is the oldest versions of .NET Framework 1.0 and 1.1 will not enable this 64-bit transformation.
The other thing to lookout for is calls to process invoke (p/invoke) in your code. If you try to call native API methods using p/invoke you could have issues with your VSTO solution running properly on 64-bit Office 2010.
You will have problems if your code makes deliberate calls to p/invoke a Win32 API that does not have exactly the same signature (method name, parameter list, and DLL name) of an equivalent Win64 API. This is true for any solution you write regardless of targeting Office as the platform. You can find a ton of information in MSDN and blogs by such luminaries as Scott Hanselman about writing Windows API calls so that they will run on either 32-bit or 64-bit Windows. Here is a generalized code snippet for handling cases where the method name or the DLL name is different:
Here are more resources to help you author your solutions today so that they will run without needing a recompile when your users install 64-bit Office 2010.
MSDN Library Visual Studio 2005 article on developing 64-bit Applications
MSDN Library Visual Studio 2008 article on developing 64-bit Applications
For migrating your really old apps with lots of native calls to .NET, try checking if your native calls have an equivalent .NET call:
Finally I should mention that this is my last post (for a while at least) on this blog because I am leaving Microsoft. I’m going to work on a charity project teaching robotics programming to high school kids in my “inner city” neighborhood for at least the next 6 months. The project is called Team Xbot! Keep an eye on these kids as they go on to good colleges and great jobs in the next few years!
Sincerely, Christin Boyd, Program Manager