Whichever connection string you are using, the place to put it is in the settings page of your Role. Give it a name, any name (in this case StorageCxnString), and set the type to ConnectionString.

Then in code, it is simple to retreive it, and pass it to, CloudStorageAccount.Parse, to do the magic. 

private const string StorageCxnString = "StorageCxnString";  

internal static CloudStorageAccount GetStorageAccount()
{
    string storageConnection = RoleEnvironment.GetConfigurationSettingValue(StorageCxnString);
   
    CloudStorageAccount _storageAccount = CloudStorageAccount.Parse(storageConnection);

    return _storageAccount;
}

Now, when you want to move from Development Storage to real Azure Storage, you just change the connection string in the Role Settings property page, and the code still works. Hopefully, this will save someone out there a headache.

Previously, the subject of this blog had been Addins and Customization. I am still interested in those things. However, in the three dark years here, things have changed. In these years, my career has grown a bit. I am now a "Principal Software Architect Lead" which means I lead a small team of architects (and we're hiring, BTW). Our architectural oversight still includes the Office facing tools like VBA, VSTO and VSTA. It also includes developer tools for SharePoint. And most recently -- very recently in fact -- we have gained what we call the "Cloud Tools": the tools for the Windows Azure Platform. And I'm sure you've noticed that Office and SharePoint are moving to the cloud as well. So, now I've got my head in the clouds...

This is a new and fun area, and one about which I am very excited and enthusiastic. I have a few blog posts in this area queued up. I won't promise it won't be three years between posts again, but we'll see how it goes.

\http://blogs.msdn.com/vsto2/archive/2008/01/16/the-reports-of-vba-s-demise-have-been-greatly-exaggerated.aspx

The only thing that is different is that his code does the Custom Task Pane the "easy" way, the standard way. In other words, he doesn't override RequestService and implement ICustomTaskPaneConsumer. But this was a small part of the demo and used, really, to demonstrate how VSTO works under the covers. In real life very few of you should ever have a need to override this functionality. However, if you do, feel free to ping me here.

Since my last post I have been busy. I've spoken at two TechEds -- in the US in Orlando and in Europe in Barcelona. I totally recommend Barcelona for anyone who hasn't been there, what a great city!

But I digress. I've been asked by several people to make available the demo code that I showed at the TechEds. I had a talk on VSTO Architecture at both, and had a "done from scratch" demo showing how to do some advanced things with VSTO. I also did this the other day on an MSDN WebCast, and didn't have time to get through the whole demo (what a lame-o, again!) and said I would post it here. Just want everyone to know that I am cleaning it up for general consumption, and it should be posted here within the next day or so.

 My other demo at Barcelona was integration of VSTA into a WPF application. I could post that demo, too, but it would do you little good at the moment, because VSTA v2 has not yet been released. So, once we have a public release of VSTA (currently planned for early next year) I will post that demo too. I have plans to expand that demo as well -- add fun features over time.

 If you are interested now, and can't wait for VSTA, well we have an answer. We will be having a limited CTP (Customer Technical Preview) of VSTA v2 in the next week. In order to get access to the CTP you need to contact our VSTA partner Summit Software at www.summsoft.com. If you do get the CTP from Summit and want early access to my VSTA WPF Demo, just contact me through the blog and I will get you an early copy. 

I've been dark for a while now, time to come out and let you know what's been going on. I've been heads down writing code for VSTO v3 and VSTA v2 due to release -- hopefully, no promises -- later this year. The new version of VSTO is built upon the new version of VSTA which is built upon the new version of System.Addin. And the new version of System.AddIn is shipping in the .NET Framework 3.5 as promised.

 It has been a ton of work, but we are close to being done now. Those of you who attended TechEd last week got a preview of VSTO v3 in the keynote, and hopefully attended our sessions during the week.

I did a session on VSTO architecture where I gave an overview of the v3 architecture and how we've changed and evolved it from previous versions. I know I promised some of you who were there that I would post my demo sample here -- and I will. It occurred to me, though, that it is of no use to you until you get a more recent drop of Visual Studio that includes all of the bits we showed. As soon as one is available publically I will make sure the sample works with that drop and post it.

I also have some more, in depth, discussion around MAF, VSTA and VSTO planned, stay tuned.

So the good news is that the infrastructure supports, to a certain extent, generics. And there is always the flexibility of using custom contracts to support anything you want. I'm going to leave custom contracts to a future post; this post is all about doing the smallest amount of work necessary to minimally support generics in a couple common cases. I'm interested in hearing whether this meets your needs, or if there are more common cases that are not done so easily.

The bad news is that proxygen doesn't support generics at all. It just skips over them when it sees them. But that's one reason why proxygen emits source code. In my mind, anyway (not sure if everyone on the team would agree with this) proxygen was never intended to generate code that gets shipped as is. The code is there to be tweaked. In some cases it may be as simple as renaming some classes. I would expect that many, if not most, hosts will want to use targeted custom contracts for performance – and other – reasons; stay tuned for my next post. And if your OM contains generics, you'll have to write a little code to augment what we put out.

So I took the ShapeApp sample and started changing it. The first case I tried was events. The .NET Framework guidelines tell you to use EventHandler<T> to declare events. ShapeApp didn't use these of course, and, well, that's not too helpful to you, if you followed the guidelines. So I removed all of the custom delegates and changed all of the events to use either System.EventHandler or System.EventHandler<T> when they had custom event args. I also changed the EventArgs class to derive from System.EventArgs, also according to the guidelines. Seems like a bug to me that it wasn't this way in the first place. I did this on both sides, in the ShapeApp app itself and in the proxy assembly that the addins consume.

This worked very well. All I had to do was change the code that populates the TypeInfrastructureManager: I just changed the typeof declarations to use the qualified generic types, and events were done.

The next common case is collections. Again, the guidelines tell us to use the generic collection types when we define collections – and it is ton easier if you've done it this way. ShapeApp has two collections, the DrawingCollection and the ShapeCollection. The first thing I did was change the application's implementation of these collections. As you'll see, I removed a bunch of code from these by using the built-in Framework classes. I derived them both from System.Collections.ObjectModel.Collection<T>. In the DrawingCollection the only thing additional thing I had to do was to override the InsertItem method to set up the drawingNumber field correctly. Notice I made the DrawingCollection type itself internal, and everywhere it was exposed I changed it to System.Collections.Generic.IList<Drawing> just to make sure we were really making things generic.

I had to do a little more work in the ShapeCollection. First off, it supported indexing by string as well as integer. Built-in collections don't support this, of course. So I defined a new interface IShapeList that derives from IList<IShape>. My ShapeCollection class derives from System.Collections.ObjectModel.Collection<IShape> and also implements IShapeList. The old ShapeCollection also fired a couple internal events: ShapeAdded and ShapeRemoved. In order to fire these at the right time (the new generic version of ShapeAdded and the new System.EventHandler version of ShapeRemoved) I had to override InsertItem and RemoveItem. Again, ShapeCollection was changed to an internal type. In this case, in the places where ShapeCollection had been exposed before, I changed it to my new interface: IShapeList. But System.Collections.Generic.IList<IShape> will show up again.

I turned out that just updating the TypeInfrastructureManager population code didn't complete the story – you do need to update it, and in fact we'll take advantage of some additional functionality it supports, but it wasn't as simple as the events. The problem turned out to be that the type returned by GetEnumerator was IEnumerator<T> and not just IEnumerator.

I decided to create a custom adapter for these collections. I created a new generic class (hey, I'm all about generics, now) called CollectionAdapter<T>. I decided to derive CollectionAdapter<T> from RemoteObjectAdapter (rather than ContractAdapterBase). This means that addins would have the ability to late-bind to it in addition to the work we're doing here. I don't actually use this late-binding capability in this sample, but all of the other objects that use the built-in adapters support late-binding, so I wanted to be consistent. And I do plan on taking advantage of this in a future post.

Here is the code from CollectionAdapter<T> is at the bottom. As you can see, there are really two classes here. The EnumeratorAdapter<T> is necessary to support GetEnumerator, of course. The EnumeratorAdapter *does* derive from ContractAdapterBase, because it is only used as an enumerator and never late-bound. The CollectionAdapter wraps an IList<T> and implements IRemoteArgumentArrayListContract which is in System.AddIn.Contract.Collections. The implementation of the contract (and its base contracts) defers to the wrapped list, and where necessary unwraps the RemoteArguments to local instances of T, or wraps them up. The where T : class constraint on the Adapter classes is there so we can use the typeof(T).

OK, so we have an Adapter, how does it get created? Go back to the code in extension.cs and notice we handle the AdapterResolve event. The TypeInfrastructureManager (I'm just going to call it TIM from now on, tired of typing it out) has this hook just for this purpose; for the host to provide custom adapters. The implementation is simple enough, if the TIM asks for an adapter for an IList<Drawing> or an IList<IShape> we instantiate a CollectionAdapter<T> and return it.

But what about the other side? The generated ShapeCollection and DrawingCollection didn't work correctly, so I implemented some new ones. Unfortunately, on the proxy side, I couldn't use System.Collections.ObjectModel.Collection<T> as the base class. This is because I had to have custom enumerators (to call into the IRemoteArgumentEnumeratorContract) and System.Collections.ObjectModel.Collection<T> doesn't expose out the ability to override it. In fact, its Enumerator implementation is internal. So the proxies were a little more work but not much. I had them implement ICollection<T>. They also implement IProxy to identify them to the infrastructure as proxies. Here the implementation just defers to the contract, and when necessary uses the helpers to wrap and unwrap RemoteArguments. The DrawingCollection is implemented as ReadOnly. The ShapeCollection supports Adding and Removing. It also implements a string based indexer like the application's OM class. However, as you can see, this implementation just loops through the elements until it finds the right one. I doesn't use the IShapeList. Why? Because IShapeList is not a contract, and in order to call into it we'd need a custom contract. And I'm not covering custom contract's here. Of course, it would be *far* more efficient to do the looping locally, instead of retrieving each object, pulling across the AppDomain boundary and checking it there. An ideal place for a custom contract – guess I have more work to do ;).

On the proxy side, we handle the ProxyResolve event rather than the AdapterResolve event off of TIM. Makes sense. The code there is equally simple. I also changed the name of IShapeClass to Shape, just 'cause it makes more sense.

If you have macro or addin code written against another version of ShapeApp, it should still compile, but you *will* have to recompile since the types have changed.

Please let me know if this sample is helpful – or not, especially not.

//Collection Adapter

using System;

using System.Collections.Generic;

using System.Text;

using System.AddIn.Contract;

using Microsoft.VisualStudio.Tools.Applications;

using System.AddIn.Contract.Collections;

using System.Runtime.Remoting;

namespace Microsoft.VisualStudio.Tools.Applications.Samples.ShapeApp

{

internal class EnumeratorAdapter<T> : ContractAdapterBase, IRemoteArgumentEnumeratorContract

where T : class

{

internal EnumeratorAdapter(IEnumerator<T> wrappedEnumerator, TypeInfrastructureManager tim) :

base(tim)

{

this.wrappedEnumerator = wrappedEnumerator;

this.tim = tim;

}

private IEnumerator<T> wrappedEnumerator;

private TypeInfrastructureManager tim;

#region Base Class Overrides

protected override IContract QueryContract(string contractIdentifier)

{

if (String.Compare(contractIdentifier, typeof(IRemoteArgumentEnumeratorContract).AssemblyQualifiedName) == 0)

return (IRemoteArgumentEnumeratorContract)this;

return base.QueryContract(contractIdentifier);

}

protected override int GetRemoteHashCode()

{

return wrappedEnumerator.GetHashCode();

}

protected override bool RemoteEquals(IContract contract)

{

if (contract == null)

return false;

if (!RemotingServices.IsObjectOutOfAppDomain(contract))

{

EnumeratorAdapter<T> contractAdapter = contract as EnumeratorAdapter<T>;

if (contractAdapter == null)

return false;

return this.wrappedEnumerator.Equals(contractAdapter.wrappedEnumerator);

}

return false;

}

protected override string RemoteToString()

{

return this.wrappedEnumerator.ToString();

}

#endregion

#region IRemoteArgumentEnumeratorContract Members

RemoteArgument IRemoteArgumentEnumeratorContract.GetCurrent()

{

return new RemoteArgument( new RemoteObjectAdapter(typeof(T), wrappedEnumerator.Current, tim));

}

bool IRemoteArgumentEnumeratorContract.MoveNext()

{

return wrappedEnumerator.MoveNext();

}

void IRemoteArgumentEnumeratorContract.Reset()

{

wrappedEnumerator.Reset();

}

#endregion

}

internal class CollectionAdapter<T> : RemoteObjectAdapter, IRemoteArgumentArrayListContract

where T : class

{

internal CollectionAdapter(IList<T> wrappedList, TypeInfrastructureManager tim)

{

this.wrappedList = wrappedList;

this.tim = tim;

}

#region Base Class Overrides

protected override IContract QueryContract(string contractIdentifier)

{

if (String.Compare(contractIdentifier, typeof(IRemoteArgumentArrayListContract).AssemblyQualifiedName, StringComparison.Ordinal) == 0)

return (IRemoteArgumentArrayListContract)this;

if (String.Compare(contractIdentifier, typeof(IRemoteArgumentArrayContract).AssemblyQualifiedName, StringComparison.Ordinal) == 0)

return (IRemoteArgumentArrayContract)this;

if (String.Compare(contractIdentifier, typeof(IRemoteArgumentCollectionContract).AssemblyQualifiedName, StringComparison.Ordinal) == 0)

return (IRemoteArgumentCollectionContract)this;

if (String.Compare(contractIdentifier, typeof(IRemoteArgumentEnumerableContract).AssemblyQualifiedName, StringComparison.Ordinal) == 0)

return (IRemoteArgumentEnumerableContract)this;

return base.QueryContract(contractIdentifier);

}

#endregion

private IList<T> wrappedList;

private TypeInfrastructureManager tim;

#region IRemoteArgumentArrayListContract Members

void IRemoteArgumentArrayListContract.Add(System.AddIn.Contract.RemoteArgument newItem)

{

T localItem = TypeServices.ObjectFromRemoteArgument(newItem, typeof(T), tim) as T;

if (localItem == null)

throw new ArgumentException();

wrappedList.Add(localItem);

}

void IRemoteArgumentArrayListContract.Clear()

{

wrappedList.Clear();

}

void IRemoteArgumentArrayListContract.Insert(int index, System.AddIn.Contract.RemoteArgument item)

{

T localItem = TypeServices.ObjectFromRemoteArgument(item, typeof(T), tim) as T;

if (localItem == null)

throw new ArgumentException();

wrappedList.Insert(index, localItem);

}

void IRemoteArgumentArrayListContract.Remove(System.AddIn.Contract.RemoteArgument item)

{

T localItem = TypeServices.ObjectFromRemoteArgument(item, typeof(T), tim) as T;

if (localItem == null)

throw new ArgumentException();

wrappedList.Remove(localItem);

}

void IRemoteArgumentArrayListContract.RemoveAt(int index)

{

wrappedList.RemoveAt(index);

}

bool IRemoteArgumentArrayListContract.Contains(System.AddIn.Contract.RemoteArgument item)

{

T localItem = TypeServices.ObjectFromRemoteArgument(item, typeof(T), tim) as T;

if (localItem == null)

return false;

return wrappedList.Contains(localItem);

}

int IRemoteArgumentArrayListContract.IndexOf(System.AddIn.Contract.RemoteArgument item)

{

T localItem = TypeServices.ObjectFromRemoteArgument(item, typeof(T), tim) as T;

if (localItem == null)

throw new ArgumentException();

return wrappedList.IndexOf(localItem);

}

#endregion

#region IRemoteArgumentArrayContract Members

System.AddIn.Contract.RemoteArgument IRemoteArgumentArrayContract.GetItem(int index)

{

T localVal = wrappedList[index];

return new RemoteArgument(new RemoteObjectAdapter(typeof(T), localVal, tim));

}

void IRemoteArgumentArrayContract.SetItem(int index, System.AddIn.Contract.RemoteArgument value)

{

T localVal = TypeServices.ObjectFromRemoteArgument(value, typeof(T), tim) as T;

if (localVal == null)

throw new ArgumentException();

wrappedList[index] = localVal;

}

#endregion

#region IRemoteArgumentCollectionContract Members

int IRemoteArgumentCollectionContract.GetCount()

{

return wrappedList.Count;

}

#endregion

#region IRemoteArgumentEnumerableContract Members

IRemoteArgumentEnumeratorContract IRemoteArgumentEnumerableContract.GetEnumeratorContract()

{

return new EnumeratorAdapter<T>(this.wrappedList.GetEnumerator(), this.tim);

}

#endregion

}

}

ShapeAppAdvancedCSharpGenerics.zip

public interface _FormRegionStartup
{
    void BeforeFormRegionShow(FormRegion FormRegion);
    object GetFormRegionStorage(string FormRegionName, object Item, int LCID, OlFormRegionMode FormRegionMode, OlFormRegionSize FormRegionSize);
    object GetFormRegionIcon(string FormRegionName, int LCID, OlFormRegionIcon Icon); |
    object GetFormRegionManifest(string FormRegionName, int LCID);
}

The first two methods we've seen before, but the next two make it nice. Let's look at GetFormRegionManifest first. This means that the form region manifest that had to be installed on disk and the path registered in the form region section of the registry, can now be stored as a resource in the dll. This means a change in the registration, of course, which I'll cover below. The implementation of this method is quite trivial. We use the name we register it with to identify the actual manifest. It gets returned as a string.

public object GetFormRegionManifest(string FormRegionName, int LCID)
{
    if (FormRegionName == "TQForms.RssFormRegion")
    {
        return RSSMessages.Properties.Resources.RSSFormRegion;
    }
    else if (FormRegionName == "TQForms.PreviewRssFormRegion")
    {
        return RSSMessages.Properties.Resources.PreviewRSSFormRegion;
    }

    return null;
}

The next method – GetFormRegionIcon – solves one problem from before, but introduces another issue. We now no longer have to store icons as Win32Resources, so we can remove the workarounds we had before to make that happen. But instead, we have to convert the icon from a managed object to a COM compatible object that Outlook can use. The implementation from the sample looks like this:

public object GetFormRegionIcon(string FormRegionName, int LCID, OlFormRegionIcon Icon)
{
    if (FormRegionName == "TQForms.RssFormRegion" && Icon == OlFormRegionIcon.olFormRegionIconPage)
    {
        return Converter.PictureUtils.ToIPictureDisp(RSSMessages.Properties.Resources.FeedIcon); 
    }
   
    return null;
}

As you can see, we call a Converter class to turn the resource into an IPictureDisp. Unfortunately, there is no built in .NET way to do this conversion, the Converter class is included in the sample. I'll leave it up to you to check out how it works.

So the xml in the manifest changes a little. Rather than putting in a resource ID, you just put the work addin to tell Outlook to load the particular addin from via the interface. You must do them all the same way – part of getting this work done at that late stage in the cycle was simplifying the assumptions: if one icon is loaded via the addin, they all must be. The xml is here:

<FormRegion xmlns="http://schemas.microsoft.com/office/outlook/12/formregion.xsd">
<name>TQForms.RssFormRegion</name>
<title>View In Browser</title>
<formRegionType>separate</formRegionType>
<showInspectorCompose>false</showInspectorCompose>
<showInspectorRead>true</showInspectorRead>
<showReadingPane>false</showReadingPane>
<hidden>true</hidden>
<addin>RSSMessages</addin>
<version>1.0</version>
<icons>
    <page>addin</page>
</icons>
</FormRegion>

In fact, if you register the form region as coming from the addin, you must load your icons this way. The change in registration makes it much simpler, but it is subtle. Rather than putting a path in the registry, you put the name of the addin – the same name that goes under the Addins key. But you first prefix it with an equals sign (=). This is the clue to Outlook that the manifest and icons are loaded via these new methods. If the addin is registered this way, the new methods *must* be implemented. If it is not registered this way, the new methods will not be called. This is the the registry script:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Office\Outlook\FormRegions\IPM.Post.RSS]
"TQForms.RssFormRegion"="=RSSMessages"
"TQForms.PreviewRssFormRegion"="=RSSMessages"

Hopefully, you be as happy about these new methods as I am. It makes form regions much easier.

RSSMessages.zip

I've created a FormRegion that hosts the Windows WebBrowser Control, and automatically shows the link. For the purposes of the sample I decided to put it two places and do it two different ways. I show it as an "adjoining" reason in the Preview pane, and as a "separate" region in the Inspector "Reading" view. I'll leave it up to you to experiment with mixing and matching these views. I'll go into where these are specified when I talk about the FomrRegion manifest below.

Implementation

First, let's go through the implementation. We'll start with the ThisAddin class. If you created and Outlook addin in VSTO 2005, you'll notice that this is different. We called it ThisApplication in VSTO 2005 and it derived directly from Outlook.Application. In VSTO 2005 SE, we have restructured this so the ThisAddin class is separate from the Application. It still gives you strongly typed access to Outlook.Application, it just doesn't derive from it anymore. In my Channel9 interview, I discussed why we made this change. If you have any feedback on this change – good, bad or neutral – please send it along.

The important piece of code in the ThisAddin class is this:

//Override the RequestService call to handle

//requests for the FormRegion service

protected override object RequestService(Guid serviceGuid)

{

if (serviceGuid == typeof(Outlook._FormRegionStartup).GUID)

{

if (this.formRegionManager == null)

this.formRegionManager = new RSSMessages.Regions.FormRegionManager();

return this.formRegionManager;

}

return base.RequestService(serviceGuid);

}

ThisAddin provides a new overridable function that we can be used to provide "services" to Office. If you add a ribbon to the project, you will see a similar piece of code for hooking it up. Office queries VSTO addins for various services (ribbons and FormRegions for now, there are others coming). We worked with the Office team to make this mechanism extensible, so that we could add more integrated support for the important services – you won't have to write this code in VSTO Orcas because we're providing a designer – and Office can add services over time and you can have access to them without VSTO having to change.

Anyway, Office requests the services by their COM guid. In this case it is the guid of the _FormRegionStatup interface. The FormRegionManager class in the project provides the implementation of _FormRegionStartup. Let's look at that next. These are the two methods on _FormRegionStartup in Outlook 2007 Beta2 TR. I make that distinction because this interface has changed since then. I'll discuss those changes – and update this sample – in a future post once they ship. Suffice it to say the changes will make some of the difficulties I discuss below go away. They are a good thing.

#region _FormRegionStartup Members

public void BeforeFormRegionShow(FormRegion formRegion)

{

RegionInstance ri = new RegionInstance(formRegion);

ri.OnFormRegionClose += new FormRegionCloseHandler(ri_OnFormRegionClose);

this.regionInstances.Add(formRegion, ri);

}

public object GetFormRegionStorage(string FormRegionName, object Item, int LCID, OlFormRegionMode FormRegionMode, OlFormRegionSize FormRegionSize)

{

if (FormRegionName == "TQForms.RSSFormRegion" || FormRegionName == "TQForms.PreviewRSSFormRegion")

{

return RSSMessages.Properties.Resources.Rss_Form_Region;

}

return null;

}

#endregion

The first method that gets called is GetFormRegionStorage. The FormRegionName parameter corresponds with the name in the form region manifest file, I'll get to that below. It returns the byte array that is the .ofs file you get from outlook. I'll talk about that below, too. Suffice it to say you simply add the ofs file to your project as a File resource and it is a simple line of code to return it as above. Then you get called on BeforFormRegionShow and get passed the instance of Outlook's FormRegion object. This gets called for each instance of the form region that is visible, and there can be any number visible at any time. So I created a separate class to represent each instance of a form region, called RegionInstance. It holds on to Outlook's FormRegion object and pulls all of the controls on the form out of that. See the function InitItems in RegionInstance.cs to see how this is done.

And that's about it for the implemetation: you hook up to events on the controls the way you would on any control and make them work the way you want. There are some interesting details about what I had to do to get the Icon for View in Browser to show up in the Ribbon, though. I'll cover those when I talk about the manifest below.

Creating a Form Region

Of course, to show a form region you have to create one, this is the .ofs file I alluded to above. The way you create one is to go into Outlook, then go to Tools…Forms…Design a Form. You'll get a dialog to choose which form you want to design – I chose RSS Article for this sample. Then you are presented with an Explorer window with the default view for that form and a bunch of tabs. From there you choose Form Region … New Form Region from the ribbon. It will add a new, blank tab and pop up a tool window with fields. You can drag and drop fields from there, and these are automatically hooked up with the outlook fields for this item. For instance the Subject and RSS Feed boxes in my form are done this way – no coding necessary. You can also show the standard Control Toolbox from the right-click menu on the form and add other controls – like the web browser control and progress bar control that I used – to the tool box and use them as well. When you have the form the way you want it, go back to the Form Region button on the Ribbon and select Save Form Region. You'll get the standard Save dialog and this will save your .ofs file. Then just copy the .ofs file to your project and add it to your resources.

You can also open up my .ofs file in the designer. Just go to the Form Region button on the designer and select Open Form Region. You'll see how my form regions was designed.

Form Region Manifest

In order for the Form Region to show up in Outlook at runtime, it must be described in a manifest and this manifest must be registered. The manifest, as you might imagine, is an XML file with a particular schema. Here is an example from my project:

<?xml version="1.0" encoding="utf-8"?>

<FormRegion xmlns="http://schemas.microsoft.com/office/outlook/12/formregion.xsd">

<name>TQForms.RSSFormRegion</name>

<title>View In Browser</title>

<formRegionType>separate</formRegionType>

<showInspectorCompose>false</showInspectorCompose>

<showInspectorRead>true</showInspectorRead>

<showReadingPane>false</showReadingPane>

<addin>RSSMessages</addin>

<version>1.0</version>

<icons>

<page>..\bin\debug\rssmessages.dll,101</page>

</icons>

</FormRegion>

As noted above, the Name element corresponds to what gets passed in to GetFormRegionStorage. The title is what shows up in the Ribbon (in this case) as the visible name. This particular manifest specifies the formRegionType as "separate" meaning it has its own separate window. The other manifest in the project specifies "adjoining" which means it shares the window. The next three elements declare where the form region will be shown. In this case it shown in the reading Inspector, but not the reading pane in the explorer. RSS Articles don't have a Composing inspector, but it they did, this would be false as well. The addin element corresponds to the name of the addin to call when looking for the FormRegionStorage and the code.

I noted above that there was some weirdness with the icon. The good news is that this weirdness goes away when Office ships, but in interest of full disclosure, I'll tell you what I had to do to make it work in this sample. As you can guess from what it says here, the page icon is a resource in my dll. But in this case it *MUST* be "win32resource" not a managed resource. There is no simple way to add a win32resource to a dll in Visual Studio. As you can see I created a simple resource script – res.rc – in my project. I added a custom pre-build step to compile that rc file into a .res file. So far so good. But it turns out to get the res file linked into the dll, I had to manually edit the .csproj file of the project. Open up the .csproj file in notepad and look for the <Win32Resource> element and you'll see what I did. It turns out there is no way that I could find to get VS to add this element, but it is honored by msbuild and passes it on to the compiler as a /win32resource directive. Again, though, the requirement to do this will be going away soon. Stay tuned for further updates.

So, we have a Form Region manifest now, how do you register it? You associate it with a "Message class" – in this case IPM.Post.RSS – and add the path to the manifest as a named value under that key under FormRegions in the registry:

HKEY_CURRENT_USER\Software\Microsoft\Office\Outlook\FormRegions\<MessageClass>.

See the sample registry script in the project to get the exact location.

So that's the story on Form Regions for right now. As I said, this gets easier when Office releases – and easier yet in Orcas. Hope this is enough to get you going in VSTO 2005 SE.

RSSMessages.zip

I was happy to see that VB .NET is being used in several companies. VB suffered a bit of a downturn recently, but it survives and is being used extensively in Office customization. C# is being used extensively as well, of course. One customer asked if they could use ML to customize Office. The short answer is yes -- but you'd have to know what you are doing. If anyone is seriously interested, it could be a future blog post. But the easiest way to do this, of course, would be to write a simple addin in C# of VB and have that load your ML assembly that does all of the work -- that is one of the beauties of .NET, the Common Language Runtime.

 Anyway, I'm going to sit right down and write myself a little Custom Form Region Cypress sample while I wait for my machines to upgrade to Vista.