Question

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.

Was it helpful?

Solution

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).

OTHER TIPS

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!

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top