IgorShare Thoughts and Ideas

Consulting and Training

Archive for the ‘VSTO’ Category

Office Applications via Prism of Unity

Posted by Igor Moochnick on 03/19/2011

This article was submitted to the MSDN magazine for publication 2 years ago. It wasn’t published due to budget cuts in the magazine and my small disagreement with Glen Block on the way I’ve used the bootstrappers. Glen was busy this time with MEF and we didn’t have time to resolve our differences.

So, for what it worth, it’s a great article and helped me and my teams in a lot of ways.

Now you’ll be the judge of that if you’ll keep on reading.

This article discusses:

  • VSTO – Visual Studio Tools for Office system
  • Prism v2 – December 19 drop 8 – Composite Application Guidance for WPF and Silverlight
  • Unity Application Block 1.2 – October 2008 drop
  • WPF
  • Visual Studio 2008 Sp1
  • Introduction

    Adding integration with Office suite was always a sweet fruit that only the daring people were willing to touch. This is mostly due to a different development model that the Office suite demands – you have to specifically target your functionality to work with Office applications and develop it separately from your main application. Office integration is based on COM knowledge. At the beginning, it was hard to wrap your head around the Office COM object model, but, with the release of the VSTO (Microsoft Visual Studio Tools for Office System), it became much easier to develop the integration for the .NET applications. The use of VSTO PIA (Primary Interpol Assemblies) makes it easier but does not change the paradigm very much: it is still necessary to develop separate application components that integrate into the Office suite. Until today, it has been hard to reuse and integrate parts of a primary product with the Office suite. We need a way to create GUI applications that can be easily decomposed into separate parts and components, and re-hosted in different ways and configurations. In other words: we need a way to create composite GUI blocks that can be hosted by Office applications and Windows applications equally.

    Note that the biggest benefits of creating composite applications in general, and for Office suite in particular, are maintainability and testability. Your components can be developed separately from each other by distributed teams and tested outside of the Office applications while maintaining high quality levels of the code. This greatly reduces the complexity of the development process.

    The Office Suite applications are, by nature, composite ones. They consist of a lot of different parts and services that have to intercommunicate and coexist in a common environment. Let us take Outlook as an outstanding example. It consists from many different parts, like folder trees, explorers (folder views), inspectors (item views), ribbons, form regions, configuration tabs, etc. All of those components have to be loaded, initialized and composed in a certain way. And do not forget that, after they are loaded, they have to communicate with each other and change their views and representations in reaction to the changes in the state of their peers.

    Let us see a simplified workflow of what happens when we change an active folder in Outlook to another one:

  • A new folder is selected in a folder tree
  • Toolbar is updated to enable or disable actions that are allowed in the selected folder
  • An active Explorer clears its current items list and populates it with the list of items from the new selected folder
  • A first item in the list is automatically selected, which causes the explorer to:
  • Update the toolbar to reflect actions that can be applied to the selected item
  • Locate an appropriate inspector that knows how to render the selected item and render it in an adjoined pane (to the explorer)
  • Locate the appropriate form regions that are associated with the selected item, create appropriate custom task panes and render them
  • Note how complex the described workflow is, and adding your own functionality into it brings certain challenges.

    Outlook is not alone in this case – all the other applications from the Microsoft Office Suite, in their own different contexts, have similarly complex workflows. All of them have menu bars, ribbons tool bars, panes, regions, etc. This leads us to the question: is there a way to solve these different complexities in a common way? The answer is Yes!

    Recently released Prism (i.e. the Composite Application Guidelines for WPF) is a perfect candidate to untangle such a tight logic knot and help us create simple composite applications that can play nicely with the applications from the Office suite. It describes how we can create composite applications from modular blocks and assemble then however we need. Furthermore, this broadens the horizons of the hosting solutions. This article will take you step by step through the implementation of an application that can be executed equally as a standalone or as a hosted one. We will see how it can be hosted within an Office application as well.

    Read the rest of this entry »

    Posted in Composite Applications, Office API, Prism, Tutorials, Unity, VSTO, WPF | 2 Comments »

    Prism (V2) RegionManager fails to recognize non-WPF applications

    Posted by Igor Moochnick on 01/05/2009

    In the recent change of Prism (V2), the way how the Region Manager detects that it’s running in a Design Mode or not, has been changed. This has ultimately broke all my Prism plug-ins that were hosted by non-WPF applications. One of the examples of hosts for such a plug-in, is an Office AddIn.

    It took me about 6 hours to track down this problem and, to my amazement, I’ve found the place where it broke:

    private static bool RegionManager::IsInDesignMode(DependencyObject element)
        // Due to a known issue in Cider, GetIsInDesignMode attached property value is not enough to know if it's in design mode.
        return DesignerProperties.GetIsInDesignMode(element) || Application.Current == null
            || Application.Current.GetType() == typeof(Application);

    The reason is that for the non-WPF application the Application.Current is NULL !!!

    The solution

    1. 1. Create an empty class that will inherit from System.Windows.Applicatoin. (Name doesn’t matter):
      public class MyApp : System.Windows.Application 	{ 	}


    2. At the point of entry to a plug-in execute the following code:
      if (System.Windows.Application.Current == null)
          // create the Application object
          new MyApp();

    This is it – now you have an Application.Current that is not null and it’s not equal to typeof(Application).

    If, by any chance, you’d like to merge your application resources – do the following:

     // merge in your application resources 
            new Uri("MyLibrary;component/Resources/MyResourceDictionary.xaml",
            UriKind.Relative)) as ResourceDictionary);  

    For more information check DR.WPF’s article (http://www.drwpf.com/blog/Home/tabid/36/EntryID/10/Default.aspx) that beautifully explains the reasons and workarounds for the problem, described above.

    Posted in Office API, Prism, VSTO, WPF | 6 Comments »

    %d bloggers like this: