I mentioned on my blog yesterday that SDN Magazine made an article I wrote back in May available online -- and since it’s all about using WPF & data in a VSTO solution I thought I’d post the link up here too :-)
Using Windows Presentation Foundation and Line-of-Business Data in Microsoft Office Clients
In this article I talk about how to expose Line-of-Business data via ADO.NET Data Services to an Excel client using WPF. Office solutions you build with Visual Studio are designed to work with Windows Forms controls but you can also use WPF controls in your solutions as well. Any UI element that can host Windows Forms controls in an Office solution (VSTO) can also host WPF controls using the Winforms ElementHost as a container.
Using WPF controls in Office allows you to think out of the box and provide world-class data visualizations that are not possible with Windows Forms controls. And you can do it easily in an instantly familiar end-user application like those in the Office family. But what if you don’t have any fancy data visualizations? Even the simplest controls that display data are often better off as WPF controls in Office applications because they better match the UI styles used in the latest versions of Office. Using WPF can make your add-ins look built into the Office applications themselves, providing a better user experience.
This article describes one piece of the Northwind Office Business Application (OBA) sample we created in the beginning of the year so if you’re just getting started in OBA development with Outlook, Word, Excel and Sharepoint I’d suggest reading these as well:
The full sample application, built with Visual Studio 2008, is here: http://code.msdn.microsoft.com/OBANorthwind
Hmm… I’m thinking a part 6 on deployment of this baby would be a good follow up….
Enjoy, -Beth Massi, Visual Studio Community
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:
//YourFunction has the same name, parameters, and DLL name in 32bit and 64bitYourFunction();Import("LIBRARY", EntryPoint = "YOURFUNCTION", CharSet = CharSet.Unicode)]private static extern bool YouFunction();//In some cases, the method name is different in Win32 API and Win64 API, //so use the following code block in stead of the above 3 lines of code.if (Marshal.SizeOf(typeof(IntPtr)) == 4){ YourFunction32();}else if (Marshal.SizeOf(typeof(IntPtr)) == 8){ YourFunction64();}Import("LIBRARY32", EntryPoint = "YOURFUNCTION32", CharSet = CharSet.Unicode)]private static extern bool YourFunction32();Import("LIBRARY64", EntryPoint = " YOURFUNCTION64", CharSet = CharSet.Unicode)]private static extern bool YourFunction64();
//YourFunction has the same name, parameters, and DLL name in 32bit and 64bitYourFunction();Import("LIBRARY", EntryPoint = "YOURFUNCTION", CharSet = CharSet.Unicode)]private static extern bool YouFunction();
//In some cases, the method name is different in Win32 API and Win64 API, //so use the following code block in stead of the above 3 lines of code.if (Marshal.SizeOf(typeof(IntPtr)) == 4){ YourFunction32();}else if (Marshal.SizeOf(typeof(IntPtr)) == 8){ YourFunction64();}
Import("LIBRARY32", EntryPoint = "YOURFUNCTION32", CharSet = CharSet.Unicode)]private static extern bool YourFunction32();Import("LIBRARY64", EntryPoint = " YOURFUNCTION64", CharSet = CharSet.Unicode)]private static extern bool YourFunction64();
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
How to access the “real” x64 registry from a Win32 .NET Application – Part I
The Myth of .NET Purity, Reloaded
For migrating your really old apps with lots of native calls to .NET, try checking if your native calls have an equivalent .NET call:
Microsoft Win32 to Microsoft .NET Framework API Map
Interoperating with Unmanaged Code
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
Every once in a while, we learn of neat apps that have been created with the Office development tools in Visual Studio. In an Outlook 2007 add-in, Jake Ginnivan combined WPF and the Facebook API to respond to Facebook events from a Ribbon. In addition, this add-in works in Outlook 2010 and has been deployed with ClickOnce. He’s written about this in two parts:
Writing a Facebook event synchroniser for Outlook 2007+ Part 1
Writing a Facebook event synchroniser for Outlook 2007+ Part 2
If you have come across other VSTO apps, feel free to leave a link in a comment here.
Mary Lee, Programming Writer.
If you’ve missed them, Kathleen has been interviewing writers on various documentation teams on some of the new features going into Visual Studio 2010. Our own Mary Lee now has a couple video interviews posted on new VSTO features that you should check out:
If you like reading better than watching videos, here are the walkthroughs in the MSDN library:
For more resources and information on how to download the VS2010 Beta, visit the Visual Studio Developer Center.