Random ramblings about Technology : .NET

Office 2010 Development – Outlook main window ribbon ID

martijnh — Tue, 01 Sep 2009 09:51:00 GMT

I’m currently writing an Outlook add-in and I’m looking into getting this compatible with both Office 2007 and Office 2010. One of the new features in Outlook 2010 is the main window Ribbon.

Using VSTO, you can create your own Ribbon, which can be automatically merged with default Ribbons by setting the correct OfficeId property for your Ribbon. Office 2007 has the list of available OfficeId values available here, but I has some trouble locating a list for the Office 2010 Technical Preview.

After some trial and error, I figures out there’s an easy way to find out what the different IDs for a specific Ribbon and it’s tabs is.

Office 2010 let’s users customize the Ribbon from within Office.

Clicking ‘Customize the Ribbon’ brings up the customization dialog:

On the right-hand side of the dialog, right-click the ‘RSS’ tab within the expanded ‘Home’ tab and choose ‘Rename’. Name it e.g. ‘testRSS’. After customizing, press OK on the dialog and re-open the customization dialog once more (if you don’t close and re-open the dialog, the following steps will not lead to the desired result).

Now press the ‘Import/Export’ button and select ‘Export all Ribbon and Quick Access Toolbar customizations’. Save the file.

The exported Office UI file has a .exportedUI extension. Rename this to .xml and open up the file. You’ll see something like this:

<mso:cmd app="MSOutlook" dt="0" />

<mso:customUI xmlns:mso="http://schemas.microsoft.com/office/2007/10/customui">

<mso:ribbon>

<mso:qat/>

<mso:tabs>

<mso:tab idQ="mso:TabMail">

<mso:group idQ="mso:GroupRss" label="testRSS"/>

</mso:tab>

</mso:tabs>

</mso:ribbon>

</mso:customUI>

Note the ‘TabMail’ ID. This is the current (it’s a technical preview, things will probably change in the future) identifier for the Ribbon Tab you’ve just modified.

OK, we’ve got the Tab OfficeID. However, for a Ribbon to show up, you also need to specify RibbonType property. Normally, using VSTO, you get a drop down with all possible values for this property within Visual Studio. However, the main window Ribbon in Outlook is new, so there’s no value for this Ribbon within the list. Luckily, you can also type in your own value. Now all that’s left is finding out the name of the main Ribbon and we’d be set.

I looked around, but the value for the main Ribbon was a mystery to me. Finally, I decided Outlook probably had the string in memory during runtime, so I could use Process Explorer to find the correct value. As you probably know, Process Explorer has a tab called ‘strings’ on the properties dialog of a process. This tab enumerates all strings within the image of the process and lists them here.

I searched for ‘Microsoft.Outlook.’ (all values in the regular drop down start with this) and found ‘Microsoft.Outlook.Explorer’. Searching further, the other values we all know and love came up. However, ‘Microsoft.Outlook.Explorer’ was the only truly new value.

I tried using this value for the RibbonType and low and behold, my add-in appeared on the ‘RSS’ tab of the main Ribbon.

Key take-away: Using a RibbonType of ‘Microsoft.Outlook.Explorer’ and ‘TabMail’ as your ControlId, you can place your add-in on the main ribbon of the Outlook window.

UPDATE: in Visual Studio 2010 beta 2, you can just select the RibbonType mentioned ;-)

Disclaimer: This has been tested on the Technical Preview of Office 2010. There are no guarantees whether these IDs will be stable as we move forward with the product.

Suppressing Personal Identifiable Information (PII) in WCF log files

martijnh — Mon, 18 Aug 2008 23:00:00 GMT

Given the vast amount of information transported between systems in today's enterprise environments, a lot of which is considered either private (addresses, social security numbers, credit card information, mortgage and pension plans, etc) or of high business value, information security is key.

From the release of WCF, it has brought us tremendous flexibility and allowed development teams to be almost completely agnostic of the way information is transported between point A to point B, focusing on adding business value instead.

Another great feature WCF brings us is runtime troubleshooting. In WCF, an administrator can simply enable logging to troubleshoot an environment which is in production.

Although a great feature for troubleshooting, Personal Identifiable Information (PII) you care about deeply while on the wire (using transport and message-level security to protect it) is available in plain text if logging is turned on at the server side.

WCF's logging features currently filter out specific PII by default (only if the message is not malformed). However, this functionality is not exposed to the developer.

Consider the following scenario:

You want the administrator to be able to monitor messages for auditing, logging or troubleshooting purposes;
certain information is considered PII and should not show up in the log files.

You could write your own logging subsystem and hook it in to your services. This takes a lot of work, is error prone, needs custom maintenance, documentation, etc.

My proposal for the scenario:

Use a behavior which
- introspects the published ServiceEndPoints for published OperationDescriptions and the used DataContracts,
- finds public properties on the DataContract marked as PII;
- instructs the WCF logging runtime to ignore the contents of the specified message elements.
configure the behavior through code (this is not generally considered a best practice, but the security needs of the service outweighs the flexibility needs of configuration);

Let's have a look at how the solution works:

Take a DataContract, e.g. PurchaseOrder and apply an attribute (PII) on each property which represents PII.

Next, add a PIIProtectionBehavior attribute to your service implementation class

You're done. The PIIProtectionBehavior attribute is also an IServiceBehavior implementation which performs the introspection on the EndPoints.

The result when logging is turned on:

As you can see, 'CreditCardnumber' is no longer logged, it just displays '<-- Removed -->' .

I've attached the sample code, hope it's useful!

Ofcourse, the normal disclaimers apply, the accompanied sample is for educational purposes only, it has not gone through rigorous testing, might contain bugs due to limited testing (me ;-)), etc. Please see the sourcecode for further remarks.

Fixing exception messages on the .NET Compact Framework 3.5

martijnh — Thu, 03 Jan 2008 19:04:00 GMT

FWIW: I recently ran into trouble while developing for the .NET Compact Framework, v3.5. Upon all exceptions, the framework would tell me:

"An error message is available for this exception but cannot be displayed because these messages are optional and are not currently installed on this device. Please install ‘NETCFv35.Messages.EN.wm.cab’ for Windows Mobile 5.0 and above or ‘NETCFv35.Messages.EN.cab’ for other platforms. Restart the application to see the message."

Interpreting the message as 'I have to run the NETCFv35.Messages.EN.wm.cab (I'm developing an application for WM6) on my device', I copied the file from C:\Program Files (x86)\Microsoft.NET\SDK\CompactFramework\v3.5\WindowsCE\Diagnostics onto my mobile device and ran the installation.

To no avail, nothing changed and I was stuck. After installing the 'Power Toys for .NET Compact Framework 3.5', however, I configured logging using the '.NETCF Logging Configuration' application and found the following error for the loader log:

'Attempt to load [\Program Files\SomeApp\System.SR.dll] has failed (err 0x80001000).'

Renaming the file 'SYCCFA~1.001', included in the aforementioned CAB file into System.SR.dll and adding it as a reference in my application proved to fix the issue. I now had readable exception messages.

Just jotting this down as there's nothing to be found on the web regarding the issue that I could find.