views:

1045

answers:

2

We have a WinForms app, written in VB.NET (CLR 2.0), that does a lot of Outlook-related stuff. One of the things we do is programmatically open up a new Outlook 2003 'compose new Email' form, pre-populated with the 'to' address.

Me.WordApp = New Word.Application
Dim template As Object = System.Reflection.Missing.Value
Dim newTemplate As Object = System.Reflection.Missing.Value
Dim documentType As Object = Word.WdNewDocumentType.wdNewEmailMessage
Dim visible As Object = False
Me.WordDoc = Me.WordApp.Documents.Add(template, newTemplate, documentType, visible)
'then some other stuff

Now, this works perfectly almost everywhere we deploy the application - the user fills in the email subject and text, clicks send, and we can catch the Send event and do other good stuff.

There are just a couple of installations where it breaks, and we just can't get to the bottom of it.

Does the following give any indication of where the problem might be:

Could not load file or assembly 'office, Version=11.0.0.0, Culture=neutral, 
PublicKeyToken=71e9bce111e9429c' or one of its dependencies. The located assembly's 
manifest definition does not match the assembly reference. (Exception from HRESULT: 
0x80131040)

As far as we can tell, these are just Office 2003 installations, with Outlook and Word, just as in the cases where it works fine.

I'd be very grateful for any ideas - either on how to fix this, or on a better way of achieving the same thing.

+1  A: 

I had a similar experience with an Excel 2003 Add-In. Do you have both Office 2003 and Office 2007 installed on the development machine? If so, check the References section in your project thouroughly. I had a dependency to Office 11, but underneath the Office 12 interop assembly was used.

I think that Assembly Binding Redirection was causing me the trouble.

Edit: Microsoft's example projects helped a lot. An additional issue were the security settings on some machines (see the SetSecurity project which is used in example setup projects).

olli
+2  A: 

Ok, it's sorted, and my grateful thanks to Olli for his answer, which got me on the right track.

His 'example projects' link led me to this link about deploying VSTO solutions.

In which I found the revealing comment:

"Microsoft Office applications install the primary interop assemblies only if the destination computer has the .NET Framework 1.1 or later installed."

Lights came on - and I set up a VM, on which I installed (in the following order):

  • XP SP2
  • Office 2003 (default install)
  • .NET 3.5 SP1 (the big redistributable)
  • My application

Bingo - the problem became reproducible, as did another one I was going to ask the community's help on. As you can imagine, all our computers, and most of the clients', have .NET already installed when Office goes on, so usually it's not a problem at all.

An Office re-install failed to fix it though, as did a 'detect and repair' installation.

However, an 'add features' install lets you manually select the .NET Programmability Support option, and the problem goes away.

Bottom line:

No .NET, no Primary Interop Assemblies with an Office install.

Thanks again Olli!

ChrisA
You are welcome Chris! Honestly, I was kind of disappointed with the overall experience in developing an Office Add-In. Looks very simple via the Visual Studio wizard, but the deployment is painful.
olli
Tell me about it. Office interop has been the bane of my life for some time. There's always something that doesn't work properly, needs some workaround, gives stupid error messages - or all three. And I'm not writing add-ins, just .NET apps that automate Office.
ChrisA