For a while I have been looking for a blog client that I can use to quickly create and post blogs. I have worked with BlogDesk, BlogJet, and Live Writer but none of them gave me the functionality I needed. Then I decided to give Microsoft Word 2007 a chance, and so far the results have been positive. This blog entry is being made with Word 2007.

Features that I like:

• Quickly synchronizes with blog engine
• Allows dragging and dropping of web content without losing formatting
• It provides good formatting capabilities and well as spell checking

- I this part 1 of this series on interoperability, we begin by discussing some of the basic concepts, and the steps for calling unmanaged code from managed assemblies. -

    When the .NET Framework was introduced Microsoft did not expect all applications would be migrated to managed code, the cost of doing this would be prohibitive. Microsoft had to provide a mechanism for existing unmanaged code to interact with new applications and libraries created in the new framework. This need forced the product developers at Microsoft to create an interop framework that would allow to  manage method calls and marshal data across code boundaries. Interoperation is also needed for managed code to access Window methods through calls to the windows API.  This blog entry provides information  about how to make managed to unmanaged code interoperation.

COM to Managed Code interop

    Making calls to existing COM libraries from managed code is fairly easy.  There are several methods that you can use to make such calls.  Here are some of the steps you need to take to call COM libraries from .NET 3.5 code. (These steps will also allow you to call COM code from previous version of the .NET framework)

Registering the COM Library:

Because COM libraries need to be available in the registry, you must first register the library:
    1. Open a new command prompt window
    2. Run "Regsvr32 Libraryname.dll"

Importing the library into VS2008 project

Once the library is registered, in your Visual Studio 2008 project, you must import the library accordingly:
    1. In Solution Explorer, right click on the project where you would like to use the COM library
    2. Click on "Add Reference", select the COM tab.



    3. Find the library, and click OK.

Another Option: Using the Type Library Importer

Instead of perform the previous two steps where the library is registered and then imported as a COM library, you can use the Type Library Importer or "tlbimp" executable to create a wrapper around the COM library and produce a fully functional .NET managed assembly.  Follows these steps to do so...
    1. Open the VS2008 command prompt
    2. Type tlbimp COMLibrary.dll /out:OutputLibraryName.dll  (The outputlibraryname is the name of the .NET library that will be produced. skip using /out if you want the output library called the same.)
    3. Import the newly created .NEt library from step 2.  When step 2 is executed, the library will be registered in the GAC, so it will be listed in the .NET tab in the "Add Reference" window.

Using the COM imported code in .NET

    Once the COM library has been imported, using the code in .NET is very straightforward.  With a few exceptions regarding exception handling, using the COM objects is very straightforward. The following code is an example of using the Office Interop assembly to create a new excel file programmatically:

            using Excel = Microsoft.Office.Interop.Excel;

            Excel.Application excelApp;
            Excel.Workbooks excelBooks;
            Excel.Workbook excelBook;

            // Instantiate the excel application
            excelApp = new Excel.Application();
            // Create the excel workbook
            excelBooks = excelApp.Workbooks;
            excelBook = excelBooks.Add( Missing.Value );

    COM objects are being instantiated and used just like any other .NET object.

- Part 2 of the series will present issues with COM interop, including handling exceptions thrown by unmanaged code. Also, we will be talking about Managed Code to COM interop.  How to call managed code assemblies and libraries from existing COM code.  This type of interoperation is also very straightforward and easy to achieve. Until then, happy .NET coding... -

    If you have ever developed an application that depends on the local user’s configuration you have probably asked yourself this question: How do I make sure that I provide compatibility to multiple platforms?  This is the question that our development team has been confronting.  We need to make sure we provide the most robust, reliable application, while guaranteeing our customers full interoperability with their existing Office Suite of applications.  These days this is not as easy as it seems… How many versions of Microsoft Office are still around? Unfortunately for us, many!

    The reason for why we are so concerned with interoperability is because we are doing a drastic shift to our core application: We are finally moving it to the .NET framework. I guess this is good for us, or at least for me… I was hired specifically to do the job! So either by pure design or destiny, we are going .NET, no questions about it.  As you all know, if you have to continue to support calls to the Microsoft Office Object Model, you must implement COM interoperability. Our core business application provides our users with quite handy integration with MS Word, for reporting, automatic billing, etc., and with MS Outlook for calendar synchronization, and task management. 

    So I decided to put on my private investigator hat and do some research on the internet.  It turns out that the days of creating nasty COM wrappers and having to marshal all sorts of data types across the COM boundary are over. Microsoft presents us with the Office Primary Interop Assemblies.  This is probably old news for those skills developers out there, but for us, they will help us a great deal. The Primary Interop Assemblies are “Component Object Model” assemblies that allow unmanaged code to be called from the .NET framework. So for sake of clarification and to sweeten the geek tooth of those developers out there, here is the definition of a PIA:
 
     “…the PIA is a collection of types that are deployed, versioned, and configured as a single unit. However, unlike other managed assemblies, an interop assembly contains type definitions (not implementation) of types that have already been defined in COM.” (Microsoft’s Website)

    So the PIA will do the nasty translating for us, and we simple create the Interop objects.

    Now, going back to our task at hand; we need to make sure that our application is compatible with all potential versions of MS Office Suite installed at our client’s machines. This also turns out to be not that difficult.  General consensus among developers is that you would want to use the Microsoft Office Object Libraries for the oldest version of Office that you would like to support. So for our case, this is what we did:

1. Agreed on only supporting Office 2003 and beyond
2. Downloaded the Office 2003 PIA, including the Microsoft Office 11.0 Object Libraries (here is the link http://go.microsoft.com/fwlink/?LinkId=50479).
3. Referenced this library in our application, as well as, individual component libraries. I.E. Word Objects and Outlook Objects.
4. Assumed upwards compatibility with Office 2007

    Following these steps, we were successful at maintaining Office 2003 and Office 2007 interop compatibility. But better yet, it required no late binding of the PIA libraries.  You might ask how this is possible; it is possible via a neat feature called “Assembly Binding Redirection” or ABR for short. The ABR makes sure that the correct interop libraries are loaded at run time, effectively automatically binding the right Interop assembly. So if you develop an application referencing the Office 2000 PIA, but you run it in a system with 2007, the ABR will re-reference the app to the latest PIA version. Problem solved…

    In conclusion, we have had success with the binding redirection feature, and our application has successfully run in Office 2007 environment.  This will save us and our technical support team lots of time working interop issues.  It seems like the guys at Microsoft are doing their homework right!

Thanks for your time!

    Over time I have developed a theory that what makes a Software Engineer excel is not his or her abilities to develop complex algorithms, or their capacity to create flawless and elegant solutions to complex problems (although this is always nice...), but instead, his or her ability to stay connected to the knowledge network.  I have seen many excellent developers succeed and others fail. I have met Development Architects that can recite the .NET Framework's namespaces almost perfectly from memory, or have memorized ASP.NET's entire page lifecycle.  Some of whom have grown professionally by leaps and bounds, others have not. But the common thread that has tied the success stories together, is the thread of knowledge sharing. The idea that knowledge does not belong to one person alone, and that actively belonging to the "knowledge network" or the community of knowledge is critical in today's success in the Software consulting business.

    Along with this idea of participating in the knowledge network is the principle of creation of knowledge.   If anyone is to participate in the knowledge network he/she must also create and share knowledge. For any network to function, there must be an equal amount of incoming and outgoing flow in and out of every node; otherwise, the network is self consuming.  When Software Engineers deny themselves the opportunity to learn, share, and experiment with new concepts and ideas, they are denying their own professional future.  I have seen it happen, some of the most brilliant developers have lost their ability to lead and manage teams because their refusal to adapt to new concepts and ideas.  They have refused to be part of the community of knowledge.

    With this in mind, I have decided to create this Blog.  In this space, I intend to tackle and share some of the most daunting and complex issues that I have and continue to come across and a Software Engineer and Software Consultant.  My hope is to create a dashboard of interesting ideas, and elegant solutions to some of the problem that come across my computer desk on a daily basis.  I will mostly be writing about Microsoft's .NET Framework technologies, concentrating mostly on the latest capabilities that have hit the market.  Be aware that I am not a professional writer. What you will get here are actual, real life issues that I've had to resolve over the years.  So if you are interested on learning and sharing your ideas with me please read on....

Welcome to my new Blog: "Unobsfuscating .NET Technologies"