5

I'm using two computers, one has Office 2010 installed and the other has Office 2016. The first one is my main PC.

Let's say I started a project on the main PC. If I add a reference to any of the following:

  • Microsoft.Office.Interop.Word (Microsoft Word 14.0 Object Library).
  • Microsoft.Office.Interop.Excel (Microsoft Excel 14.0 Object Library).
  • Microsoft.Office.Interop.PowerPoint (Microsoft PowerPoint 14.0 Object Library).

..and then open the project on the second PC, Visual Studio will automatically select the applicable version for all of them (i.e., "Microsoft XXXX 16.0 Object Library") since "Embed Interop Type" property is set to true.

So far so good, but when I add a reference to Microsoft.Office.Core (Microsoft Office 14.0 Object Library), I can't get the same behavior, that is, when I open the project on the second PC, I find the reference with the same version (14.0) flagged with an icon indicating that the reference is missing along with warnings telling me the same thing (the reference cannot be found).

Obviously, if I remove the reference and replace it with the newer version (16.0), everything works fine except -of course- that I won't be able to open the solution on the main PC anymore.

So, my questions are:

  • Why doesn't it select the appropriate version for Microsoft.Office.Core like what happens with Interop.Excel, Interop.Word, etc?
  • Is there a solution for this so I can open the project seamlessly between the two computers?

Please note:

  • The main focus is not about running the application by the end user with different versions of Office (this have been asked and answered many times before). I'm more concerned about opening the solution/project on a secondary development machine with a different version of Office installed.

  • In case that's relevant, this is a WinForms application.

Update:

  • I tried copying the MSO.DLL file to a local 'lib' folder but whenever I add it as a reference, it shows "C:\Windows\assembly\GAC_MSIL\Office\14.0.0.0__71e9bce111e9429c\Office.dll" as the path of the reference. Then, no matter whether I disable/enable the Embed Interop Types property, it still doesn't compile on the secondary development machine.

  • Although I'm not quite sure I fully get Eugene's answer, it helped by giving me the idea of adding the PIA references in the Assemblies tab, not the COM tab and still have the Embed Interop Type property set to true. That actually seems to work but I'm not sure if not using the COM references might have any downsides. Does it?

41686d6564 stands w. Palestine
  • 19,168
  • 12
  • 41
  • 79
  • In response to your question about downsides when not using the COM tab to add references: The PIAs installed with any given version of Visual Studio will be those for the version of Office current when Visual Studio was released. These may not be the same as the version of Office installed on the development machine. The PIAs from the COM tab will be those of the version of Office you specify. – Cindy Meister Jun 04 '18 at 13:43
  • And the object models of the individual Office applications are in the *.olb* files, not in the executables. I don't have Eugene's experience in this area, but I'd think you'd need only copy (and distribute) the MSO Core file, that's giving you problems... – Cindy Meister Jun 04 '18 at 13:46
  • @CindyMeister _"the object models.. are in the .olb files, not in the executables"_. I'm not an expert on COM objects and referencing them so I might be misreading (misinterpreting) this, but [this is where I got it from](https://s22.postimg.cc/x7gol5j1t/COM.png). Did I misunderstand that? – 41686d6564 stands w. Palestine Jun 04 '18 at 15:32
  • _"you'd need only copy (and distribute) the MSO Core file"_, I just tried copying the MSO.DLL file to a local 'lib' folder but whenever I add it as a reference, it shows "C:\Windows\assembly\GAC_MSIL\Office\14.0.0.0__71e9bce111e9429c\Office.dll" as the path of the reference. Then, no matter whether I disable/enable the `Embed Interop Types` property, it still doesn't compile on the secondary development machine. – 41686d6564 stands w. Palestine Jun 04 '18 at 15:32
  • Yes, what you see in a References dialog is mis-leading. If you search in Windows you'll find the actual *.olb files. – Cindy Meister Jun 04 '18 at 15:39
  • As I said, I don't have Eugene's experience with this approach. Usually, if someone is advised to put something in a local folder (for distribution with the solution) it's an IA generated using TlbImp. I've never see anyone propose to copy a PIA to a local folder, and it's standard that VS will take a PIA from the GAC, if it's available. If you do NOT enable embedding interop types does the solution make the change automatically? – Cindy Meister Jun 04 '18 at 15:43
  • @CindyMeister _"If you do NOT enable embedding interop types does the solution make the change automatically"_ What change? Let me explain what happens. Once I add a reference to the local MSO.DLL file, it's added with `Embed Interop Types` **enabled** and the path changes to what's mentioned above (yes automatically if that's what you're asking). Then, If I set `Embed Interop Types` to false, nothing changes (it still refers to the Office.DLL file). – 41686d6564 stands w. Palestine Jun 04 '18 at 15:53
  • Yes, and when you open the solution on the other machine, with Office 16, does it then update? Or is the behavior the same whether Embed interop types is true or false? – Cindy Meister Jun 04 '18 at 16:11
  • When I open it on the other machine, I get the same behavior (the original behavior explained in the question) whether Embed Interop types is true or false (I'm assuming because that path doesn't exist on that machine). – 41686d6564 stands w. Palestine Jun 04 '18 at 16:16

1 Answers1

3

You need to copy interop assemblies (Microsoft Word/Excel/PowerPoint/Core 14.0 Object Libraries) to a local folder in the solution. And then you can add them as references, so they will be accessible on both machines and you will be able to open the project seamlessly between the two computers.

Eugene Astafiev
  • 47,483
  • 3
  • 24
  • 45
  • Can't this work with "Embed Interop Types" property set to true? – 41686d6564 stands w. Palestine Jun 02 '18 at 10:09
  • You need to re-add references pointing to the local interop files. Then you will be able to set the `Embed Interop Types` property. – Eugene Astafiev Jun 02 '18 at 10:51
  • Aside from "MS Office Object library" _which is the MSO.DLL file_, the other "MS XXXX Object libraries" are the Office programs executabales, do I need to copy those? – 41686d6564 stands w. Palestine Jun 02 '18 at 11:19
  • Your answer helped in giving me an idea to try something else though. I didn't actually copy any files locally. Originally, I've been using the references from the COM tab [as suggested by Hans Passant](https://stackoverflow.com/a/21018418/4934172), but now, I used the references in the Assemblies tab (located in "..\Visual Studio Tools for Office\PIA\Office14") instead. Do you know if there's any downside to not using the ones in the COM tab? – 41686d6564 stands w. Palestine Jun 02 '18 at 11:19