none
AddIn originnaly writen for Outlook 2010 can not load file or assembly 'Microsoft.Office.Interop.Outlook, Version=12.0.0.0 RRS feed

  • Question

  • Hi,

    I'm trying to 'resuscitate' the add-in originaly written for Outlook 2010 in VS 2010 to run in Outlook 2013. After several problems with installation and then with ribbon I have anotherproblem I really can't solve already some days:

    Addin starts normally, most of the functions works normaly but when I try to open one dialog (displaying the data from database, having nothing related to the Outlook object model), it throws the exception:

    System.Reflection.ReflectionTypeLoadException: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
       at System.Reflection.Module._GetTypesInternal(StackCrawlMark& stackMark)
       at System.Reflection.Assembly.GetTypes()
       at System.Data.Metadata.Edm.ObjectItemCollection.AssemblyCacheEntry.LoadTypesFromAssembly(LoadingContext context)
       at System.Data.Metadata.Edm.ObjectItemCollection.AssemblyCacheEntry.InternalLoadAssemblyFromCache(LoadingContext context)
       at System.Data.Metadata.Edm.ObjectItemCollection.AssemblyCacheEntry.LoadAssemblyFromCache(Assembly assembly, Boolean loadReferencedAssemblies, Dictionary`2 knownAssemblies, Dictionary`2& typesInLoading, List`1& errors)
       at System.Data.Metadata.Edm.ObjectItemCollection.LoadAssemblyFromCache(ObjectItemCollection objectItemCollection, Assembly assembly, Boolean loadReferencedAssemblies)
       at System.Data.Metadata.Edm.ObjectItemCollection.LoadAssemblyForType(Type type)
       at System.Data.Metadata.Edm.MetadataWorkspace.LoadAssemblyForType(Type type, Assembly callingAssembly)
       at System.Data.Objects.ObjectContext.CreateQuery[T](String queryString, ObjectParameter[] parameters)
       at Dhi.Project.Sharelook.Data.SharelookEntities.get_Libraries()
       at Dhi.Project.Sharelook.frmAddSite.BindSyncedLibraries()
       at Dhi.Project.Sharelook.frmAddSite..ctor()
       at Dhi.Project.Sharelook.Ribbon.InitializeSettingsForm()
       at Dhi.Project.Sharelook.Ribbon.btnSettings_Click(IRibbonControl control)



    I've added the code to get the data from LoaderExceptions and it says:

    Could not load file or assembly 'Microsoft.Office.Interop.Outlook, Version=12.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 I've mentioned, my addin has been developed for 2010 office in VisualStudio 2010, it has never referenced Interop.Outlook 12. I've checked all the referenced libraries - some of the also reference this library. So I've checked that all of them reference 14 version, rebuilt them, remove them as reference in the Addin project and added them again to be sure they are added as project output (and not some old dll). No change.

    Unfortunatelly I can not reference both 12 and 14 version, so what could be the solution?

    Thanks
    Thursday, April 11, 2013 12:01 PM

All replies

  • why is EDM trying to load Outlook 12? Try yourself to do the same: iterate through all types in your assembly and see on which type it will break.
    • Marked as answer by Filip Mateasko Thursday, April 11, 2013 12:19 PM
    • Unmarked as answer by Filip Mateasko Thursday, April 11, 2013 12:20 PM
    Thursday, April 11, 2013 12:18 PM
  • Hi Damian, 

    sorry for stupid questions but:

    1) what is EDM?

    2) how to do what your are talking about? 

    Thursday, April 11, 2013 12:20 PM
  • look at stack trace:

    System.Reflection.Assembly.GetTypes() - do the same for all your assemblies that compose your add-in.

    As for EDM - you are using entity framework, so you should know ;-)

    Thursday, April 11, 2013 12:27 PM
  • hmm,

    unfortunatelly I'm still not wiser... ok, EDM is entity data model, right? good. but what to do with System.Reflection.Assembly.GetTypes()?

    I'm not able to debug on the testing computer... I can only add some log lines in the code, republish and try it...

    or?

    Thursday, April 11, 2013 12:35 PM
  • on your dev machine write console app that will do more or less the same:

    foreach(Assembly a in your assemblies)]

    {

    a.GetTypes();

    }

    and see when it explodes with the same error. If it will not, make sure you do not have anywhere PIA 12 on your system (GAC, Program files). You can also check with VS (Debug -> modules window) if after all assemblies passed loop you do not have anywhere in your process PIA 12 loaded. Or on that test machine where it fails check if you do not have policies with assembly redirection in GAC

    Thursday, April 11, 2013 12:57 PM
  • my development machine is VS2010, Office2010 and it works perfectly there. SO I can not see anything interesting there, I think.  So probably only the last option is relevant, right? How and where to check for this policy? Sorry, I haven't done sucha thing yet...
    Thursday, April 11, 2013 1:06 PM
  • I've added following code to the addin to see what's wrong :

                
    Assembly asm = Assembly.GetExecutingAssembly();
    var asmbs = asm.GetReferencedAssemblies();
     
     var asmbsNames = (from a in asmbs select a.FullName).ToArray () ;
                MessageBox.Show(string.Join(Environment.NewLine, asmbsNames));
                
    foreach (var asmbName in asmbs)
                {
                    try
                    {
                        Assembly assembly = Assembly.Load(asmbName);
                        assembly.GetTypes();
                    }
                    catch (Exception ex)
                    {
                        ex.ShowExceptionForm("Problem in " + asmbName);
                    }
                }
     
                try
                {
                    asm.GetTypes();
                }
                catch (Exception ex)
                {
                    ex.ShowExceptionForm("Problem in " + asm.FullName);
                }

    It shows me that problem is in:

    Problem in Microsoft.Office.Tools.Outlook.v9.0, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a

    Problem in Microsoft.Office.Interop.Outlook, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c

    and of course in my addin aseesmbly intself. But - this should iterate over referenced assemblies, but the Microsoft.Office.Interop.Outlook, Version=12 is not referenced, so why it could be there?

    Here is the list of the referenced assemblies - it's interesting that both versions of Outlook interop are there but only 14 is referenced in Visual studio

    Thursday, April 11, 2013 1:37 PM
  • maybe it is references indirectly via some other dll, for example Lync? you will have to find it out yourself. Try for example process monitor tool to see order in which dlls are loaded - when outlook 12 is requested, try looking up what was loaded right before it - maybe it will be the culprit.
    Thursday, April 11, 2013 4:53 PM
  • I created the console app, added all the references I have in my addin and after some time I've finaly found the same as yesterday - it seems that the problem is in Microsoft.Office.Tools.Outlook.v9.0, Version=9.0.0.0.

    I've added the code to list all indirectly referenced assemblies (and their versions) - meaning assemblies referenced by assemblies referenced in my code (to see which component references the 12 version) and I see that it is Microsoft.Office.Tools.Outlook.v9.0, Version=9.0.0.0.

    Testing Microsoft.Office.Tools.Outlook.v9.0 ...

      References:
         mscorlib, 2.0.0.0
         System.Windows.Forms, 2.0.0.0
         System, 2.0.0.0
         Microsoft.Office.Interop.Outlook, 12.0.0.0
         Microsoft.Office.Tools.Common.v9.0, 9.0.0.0
         Microsoft.Office.Tools.v9.0, 9.0.0.0
         Microsoft.VisualStudio.Tools.Applications.Runtime.v9.0, 9.0.0.0
         System.Drawing, 2.0.0.0
         System.Xml, 2.0.0.0
         Microsoft.Vbe.Interop.Forms, 11.0.0.0
         stdole, 7.0.3300.0
         System.AddIn, 3.5.0.0
    =============================================

    It'S also seen in the ildasm

    .assembly extern Microsoft.Office.Interop.Outlook
    {
      .publickeytoken = (71 E9 BC E1 11 E9 42 9C )                         // q.....B.
      .ver 12:0:0:0
    }

    But what can I do with it?


    Friday, April 12, 2013 9:11 AM
  • upgrade Tool reference to 10?

    Friday, April 12, 2013 10:04 AM
  • I don't have such a file.... 

    I have both PIA installed 12 and 14

    I have Visual Studio Tools for Office 2010 runtime installed

    Normally I think it should be able to find the library if it's in PIA. Maybe one interesting thing - to be able to run the add-in I had to set the Microsoft.Office.Interop.Outlook.dll version 14.0.0.0 as "Copy local" = true. If I didn't do it I would be "Missing" this one. Maybe something is wrong, because I think that add-in should be able to find both libraries itself, without any CopyLocal, shouldn't it?

    Couldn't be a problem, that I have both Visual studio 2010 and 2012 installed on the "failing" computer?  Because PIAs are installed in the c:\Program Files (x86)\Microsoft Visual Studio 10.0\Visual Studio Tools for Office\PIA\ directory, so they are related to VS2010 only...

    Friday, April 12, 2013 11:01 AM
  • Microsoft.Office.Tools.Outlook. does not exist anymore in vsto 2010 - just remove that reference and any other reference to *9.0 and simply add reference to Microsoft.VisualStudio.Tools.Office.Runtime.v10.0.dll
    Friday, April 12, 2013 11:25 AM
  • No,

    I can not do that - I'm in .NET 3.5 http://msdn.microsoft.com/en-us/library/vstudio/ee712616.aspx

    too many errors in  Ribbon
    Friday, April 12, 2013 12:44 PM
  • then simply switch to using local copy of PIA 12 all over your add-in.

    Friday, April 12, 2013 1:28 PM
  • how can I do that?
    Friday, April 12, 2013 1:46 PM
  • copy needed PIA assemblies to your solution and reference them from that place. Also distribute them locally with your add-in (so remove prerequisite for PIA installed on client machine).
    Friday, April 12, 2013 3:37 PM
  • I can not add reference to 12 version if I reference 14 version and I need to reference 14 version

    anyway, as far as I know, add-ins written for Office 2010 should work in Office 2013, so there must be something wrong, I guess... 

    Monday, April 15, 2013 8:24 AM
  • add-ins written for 2010 will Work on 2013 but for those based on .net 4.0, not 3.5, so if you want to support in single  add-in versions from 2007 onward, accept fact that you will have to reference PIA 12 either locally or globally. Otherwise switch to .net 4.0
    Monday, April 15, 2013 12:13 PM
  • ok. I should probably do that, but isn't here written that also 3.5 should be supported http://msdn.microsoft.com/en-us/library/vstudio/bb772080.aspx ?

    Microsoft Office 2010

    .NET Framework 3.5

    Office 2013

    Microsoft Office 2010

    Visual Studio 2010 Tools for Office Runtime

    Do I understand it wrongly ?

    Monday, April 15, 2013 12:18 PM
  • it should - apparently it will if you deploy all needed components.

    Tuesday, April 16, 2013 6:57 AM
  • Hmm, just to summarize:

    1) according the MSDN I should be able to succesfully run Addin written for Office 2010 (=14) targeting .NET 3.5 in Office 2013 if I install VisualStudioToolsForOffice 2010 Runtime (this is the only mentione prerequisite) - and this is done

    2) You tell me, that I have to reference PIA 12 (=Office 2007) to be able to run this Addin (which has been written originally in VS2010 as Outlook 2010 AddIn!)

    3) I can't reference both 14 and 12 version of the same assembly in one project, right? It's simply not allowed

    4) I must reference 14 version, because it is addin for Outlook 2010 (=14), thus I simply can't reference 12 version, right?

    5) I can't add 12 version into GAC, because then the solution can not be distributed via ClickOnce - otherwise I would need every user to add his PIAs into GAS too

    so what do you meen by "if you deploy all needed components."  ?

    Tuesday, April 16, 2013 7:10 AM
  • Ad 4 is wrong - you can use PIA 12 to develop Things for office 2010.

    Ad 5 - deploy PIA as your private assemblies.

    Tuesday, April 16, 2013 8:10 AM
  • ok, but

    1) I don't know what is a difference between 12 and 14 version, but I'd suppose there is some. Do you know the difference? Can it be neglected?

    2) if I used  newer version of dll in my addin, why should I downgrade the library to run this addin in higher version of Office - isn't it illogical? I don't need to run it in Office 2007 so I shouldn't need to use 2007 (12) assemblies.

    So my question in this thread is still the same - why do I have to use 2007 assemblies if I want to run 2010 project in 2013 version? I don't want to use 12 version instead of 14 version - my addin has been developed with the 14 version.

    Tuesday, April 16, 2013 8:20 AM
  • How can I deploy 12 version as a private assembly when I already deploy also the 14 version? 
    Tuesday, April 16, 2013 8:51 AM
  • i already answered that question previously in this thread.

    as for question from second to last post:

    Ad 1 - no, there are differences, you have to determine if you are using features that are not present on PIA 12.

    Ad 2 - did you create your original add-in from Outlook 2007 template or Outlook 2010 templace in VS?

    Tuesday, April 16, 2013 10:08 AM
  • I used Outlook 2010 template

    sorry, but I can not find where you answered "How can I deploy 12 version as a private assembly when I already deploy also the 14 version" - if I add the 12 dll into my solution (BuildAction = Content CopyToOutputDirectory = CopyAlways),  then it's overwritten by the 14 version, which is referenced and "CopyLocal" = true. If I add 12 version into the subdirectory in my solution, then it's copied to my computer by the installation, but the error persits

    Tuesday, April 16, 2013 10:27 AM
  • SO last (unsuccessful) trial:

    I created folder PIA12 in my solution

    Copied there :

    Microsoft.Office.Tools.Common.v9.0.dll

    Microsoft.Office.Tools.v9.0.dll

    Microsoft.Office.Tools.Outlook.v9.0.dll

    Microsoft.Office.Interop.Outlook.dll (version 12.0....)

    first 3 are referenced in project references from here, the last ios not referenced at all, because the 14 version is referenced in the project.

    All those files are Content, CopyAlways and they appear on the target computer

    But it still doesn't work

    Tuesday, April 16, 2013 10:51 AM
  • remove all references to global PIAs from your Projects. Copy PIA 12 dlls locally to solution folder, add reference to them by using Browse button in Project add reference window. Make sure they are always referenced by looking at path in Properties window. Deploy them along with your add-in.

    Tuesday, April 16, 2013 1:34 PM
  • see my previous post - isn't it what you are talking about? it hasn't helped... 
    Tuesday, April 16, 2013 2:14 PM
  • PIA are just dlls, nothing special here. And just like any other dlls - modify your project to deploy them as your private dlls, just as you would with some 3rd party component. You can do it.
    Tuesday, April 16, 2013 6:37 PM
  • Damian,

    I don't know if you understand me 

    - I have to reference one library in two versions - Visual studio doesn't allow to do it - how can I do it?

    - I also have to add both of them to my project physically, because if I doesn't set "copy local" to the 14 version, then it's "not found" too (why it doesn't find at least this?)

    - both libraries 14 and 12 version have the same name so I can not add them to the same (root) directory -  only the14 version is automatically copied there

    - As I've written I referenced the 14 version and 12 version I added to the subfolder, which is distributed with my app. All PIA libraries were added to to the same subfolder and referenced from there, BUT it hasn't helped!

    what can I do else?

     

    Tuesday, April 23, 2013 8:41 AM
  • this is my last reply in this thread -

     no, you do not have to reference one library in two versions, simply reference only pia 12 and remove all references to PIA 14 and all problems described by you will be gone

    Tuesday, April 23, 2013 9:50 AM
  • ok, lets finish this thread as unsolved - we are really walking in the circle - reply to your last message is in my message from Tuesday, April 16, 2013 8:20 AM

    Doesn't matter, maybe somebody else will have an answer. All Your suggested steps are just workarounds  needing changes in the code - of course, I can modify my code to use .NET 4, I can modify my code to use 12 library only, but my question is how to run it in Outlook 2013 without the code modification. Why to do it, if according the MSDN the usage of my add-in should be normally supported?

    However, Damian, thanks for your patience!


    Tuesday, April 23, 2013 10:23 AM