Greg M

Hope I'm nearing the end of questions here, and thanks again for reading.

I have a Excel2003 Applcation Level Add-In made using VSTO with SE download.

Deployment package is made, I can see that registry entries are being made, that CAS policy has full trust and that prereqs are loaded.

I have set the suppressdisplayalerts environ variable =0 to see why the add-in is not loading and i have the following:

Could not load file or assembly 'office, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c' or one of its dependencies. The system cannot find the file specified.


Could not load file or assembly 'office, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c' or one of its dependencies. The system cannot find the file specified.


************** Exception Text **************
System.IO.FileNotFoundException: Could not load file or assembly 'office, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c' or one of its dependencies. The system cannot find the file specified.
File name: 'office, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c'
at SEI_IMU_xl2003_AddIn.XLAddIn.DeleteMenuBarIfExists()
at SEI_IMU_xl2003_AddIn.XLAddIn.ThisAddIn_Startup(Object sender, EventArgs e)
at Microsoft.Office.Tools.AddIn.OnStartup()
at SEI_IMU_xl2003_AddIn.XLAddIn.FinishInitialization()
at Microsoft.VisualStudio.Tools.Applications.Runtime.AppDomainManagerInternal.ExecutePhase(String methodName)
at Microsoft.VisualStudio.Tools.Applications.Runtime.AppDomainManagerInternal.ExecuteEntryPointsHelper()

WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].

************** Loaded Assemblies **************
mscorlib
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.832 (QFE.050727-8300)
CodeBase: file:///C:/WINNT/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll
----------------------------------------
Microsoft.VisualStudio.Tools.Applications.Runtime
Assembly Version: 8.0.0.0
Win32 Version: 8.0.50727.891
CodeBase: file:///C:/WINNT/assembly/GAC_MSIL/Microsoft.VisualStudio.Tools.Applications.Runtime/8.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualStudio.Tools.Applications.Runtime.dll
----------------------------------------
Microsoft.Office.Tools.Common
Assembly Version: 8.0.0.0
Win32 Version: 8.0.50727.891
CodeBase: file:///C:/WINNT/assembly/GAC_MSIL/Microsoft.Office.Tools.Common/8.0.0.0__b03f5f7f11d50a3a/Microsoft.Office.Tools.Common.dll
----------------------------------------
System
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.832 (QFE.050727-8300)
CodeBase: file:///C:/WINNT/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Windows.Forms
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.832 (QFE.050727-8300)
CodeBase: file:///C:/WINNT/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
Excel_AddIn
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0
CodeBase: ____ (stuff omitted here intentionally)
----------------------------------------
Microsoft.Office.Interop.Excel
Assembly Version: 11.0.0.0
Win32 Version: 11.0.5530
CodeBase: file:///C:/WINNT/assembly/GAC/Microsoft.Office.Interop.Excel/11.0.0.0__71e9bce111e9429c/Microsoft.Office.Interop.Excel.dll
----------------------------------------
Microsoft.Office.Tools.Excel
Assembly Version: 8.0.0.0
Win32 Version: 8.0.50727.891
CodeBase: file:///C:/WINNT/assembly/GAC_MSIL/Microsoft.Office.Tools.Excel/8.0.0.0__b03f5f7f11d50a3a/Microsoft.Office.Tools.Excel.dll
----------------------------------------
office
Assembly Version: 11.0.0.0
Win32 Version: 11.0.5530
CodeBase: file:///C:/WINNT/assembly/GAC/office/11.0.0.0__71e9bce111e9429c/office.dll
----------------------------------------


Now, I started this as an Excel2003 Add-in, and obviously it's pointing to the version 12.0 assembly for Excel 11 object model. When i look at the properties in the references to microsoft.office.core i see that gac/office/12.0.0.0 reference when the test machine wants 11.0.0.0

So, really simple question here (and i'm excited to be near then end of this)....How exactly do I manually remove that reference and add the right one I'm generally familar with adding references but i don't know how to find the specific one i need here.

Thanks in advance,

Greg



Re: Visual Studio Tools for Office Fixing Bad Office.Core Refernce in xl2003 Application Add-In

Cindy Meister

I have to ask...

Is Office 2007 (or was Office 2007) installed on your development machine 2007 is 12.0; 2003 is 11.0.






Re: Visual Studio Tools for Office Fixing Bad Office.Core Refernce in xl2003 Application Add-In

Greg M

Cindy,

Thanks for the reply and sorry for not annotating this earlier.

Complex answer. I tried the Office 2007 beta but uninstalled it (perhaps it did not fully uninstall). I have purchased OneNote2007 and use it, but not Office2007 in general.

If i look at the properties reference to Microsoft.Office.Core in my AddIn solution, it says "Microsoft Office 11.0 Library" in the description, but the path property is C:\WINDOWS\assembly\GAC\Office\12.0.0.0__71e9bce111e9429c\Office.dll

The setup project is deceting 2 dependencies to office.dll, the 12.0 and 11.0.

I can easily delete the bad reference....I just can't see how to get the right one in there inside visual studio.

Greg





Re: Visual Studio Tools for Office Fixing Bad Office.Core Refernce in xl2003 Application Add-In

Cindy Meister

Hi Greg

I was hoping someone who knows more about the technicalties of fixing such a problem would jump in here, once the information was available...

You know that references are set through right-clicking the project name in the Solution Explorer, then going over Add Reference for Office, you choose the COM tab and select the type library you need.

I think there's a "thing" with Office, however, that reverts to the newest version of the PIAs available. That's why VSTO doesn't let you install it on a machine with both 2003 and 2007 present, for example. So I think to solve your problem you're going to have to manually remove all the Office 12 PIAs from the GAC. So if removing the references to Office 12 and making sure you have the ones for 11.0 doesn't solve the problem, you'll need to find out how to strip the Office 12 PIAs out of the GAC.






Re: Visual Studio Tools for Office Fixing Bad Office.Core Refernce in xl2003 Application Add-In

Greg M

Cindy,

Thanks so much for the reply. I was comfortable with playing with the references...just not comfortable with trying to trick VS to point to the right one when I open up references.

There is a reference for Office 11 in the references box, but it's pointing to this 12.0____ version. So it seems i'm GAC bound, and that's my research task for the day. If I find a piece that helps explain it, i'll post the results here in case anyone else has the same problem later.

Cheers,

Greg





Re: Visual Studio Tools for Office Fixing Bad Office.Core Refernce in xl2003 Application Add-In

Dennis Wallentin


was hoping someone who knows more about the technicalties of fixing such a problem would jump in here, once the information was available...

Me too but I thought I would add the following:

Use the gacutil.exe to remove the PIAs from the GAC directory

Removing PIAs

1) The assemblies are located in Windows XP in the folder: C:\WINDOWS\assembly

2) Open the folder in Windows Explorer to locate the Office assemblies.

3) Add them to a textfile and

4) Read the following article about the gacutil tool: Global Assembly Cache Tool (Gacutil.exe) (where you find how to remove the assemblies based on a textfil).

5) Remove them and reboot the computer.

Install the relevant PIAs
1) Download Redistributable Primary Interop Assemblies and install them.

2) Reboot the computer.

Open the VSTO project and check to see if the above have had any impact on the project. Here I'm unsure as what the outcome actually will be (as I have gracefully avoided this kind of scenarios). But I believe that the detected dependencies need to be changed or that there exist a number of warning messages related to it.






Re: Visual Studio Tools for Office Fixing Bad Office.Core Refernce in xl2003 Application Add-In

Greg M

It's working now, and I thought I'd post my soultion to it in the event that someone finds themselves in a similar path.

The Office 2007 beta wasn't the issue, but OneNote07 was. It was throwing up the Microsoft.Office.Core dll that was a version 12 dll bundled to emulate version 11 (even says version 11 in the title).

Making a system restore point, then uninstalling it and rebooting caused VStudio to pull the correct Office.Core dll version from the GAC, and all is now good.

For the meantime I can just make this a part of my deployment process (checkpoint, uninstall, build the VS setup, then revert checkpoint to return OneNote).

To Cindy and the other VSTO team members...

Despite the serious deployment learning curve, I just wanted to say that I love VSTO. I'm a finance/business person, not a career coder (I'm a VBA convert), and the structure that VSTO provides is just excellent. Excel is a great sandbox for business types, but it completely breaks MVC by conflating UI, business rules and data. (I'd go as far to say that it just makes the requirements process more difficult with us business types sometimes because we have to unlearn the way we approach problems in Excel every day).

The ability of VSTO to restore the MVC pattern while keeping the users in the perceived friendly confines of an Office UI is tremendous, and I'm sure that the next and future releases will make the deployment process less of an issue.

Thanks so much for the time you put in not only this product, but also this group.

Greg

(ps: I know it's not directly tied to VSTO, but the ability in [Project]>References>Add to select a specific version of an assembly out of the GAC would be a tremendous benefit for VStudio to avoid this in the future).





Re: Visual Studio Tools for Office Fixing Bad Office.Core Refernce in xl2003 Application Add-In

Cindy Meister

Hi Greg

I'm glad you were able to solve the problem. And thank you for letting us know what helped :-)

<<(ps: I know it's not directly tied to VSTO, but the ability in [Project]>References>Add to select a specific version of an assembly out of the GAC would be a tremendous benefit for VStudio to avoid this in the future).>>

Actually, it's not even the Visual Studio that's in control here. The problem comes from COM, and more specifically from Office. It's related to the old "DLL He**" problem: Office is designed to register ONE application DLL as the "current version", and that's what Visual Studio is forced to pick up. It's sort of like the double-click-on-an-Office-file behavior: it will open up in the "current" version of the application, according to the Registry. If Office were ever to become .NET-based then this problem would go away.

One way many of us avoid the kind of situation you find yourself in is to use Virtual Machine software for development environments. Personally, I use VMWare, but many also work successfully with Virtual PC. Beats separate boot partitions, or exchangeable hard disks <g>






Re: Visual Studio Tools for Office Fixing Bad Office.Core Refernce in xl2003 Application Add-In

Dennis Wallentin


...but many any also work successfully with Virtual PC.


Compared with vmWare it's so ***** which explains why it's free...

The more I work with a third-part's tool to create .NET based solutions with the more I wonder why MSFT cannot provide us with version neutral PIAs (which the third-part tools do) Although it's not supported I can successfully use several Excel versions on the same configurations with the version neutral IAs.






Re: Visual Studio Tools for Office Fixing Bad Office.Core Refernce in xl2003 Application Add-In

Cindy Meister

Dennis Wallentin wrote:

The more I work with a third-part's tool to create .NET based solutions with the more I wonder why MSFT cannot provide us with version neutral PIAs (which the third-part tools do) Although it's not supported I can successfully use several Excel versions on the same configurations with the version neutral IAs.

I can imagine is one reason would be guaranteeing that things actually work across all versions. If a third-party doesn't get it right MSFT can't be sued :-) If MSFT doesn't get it right... There's also the over-head involved in making sure it works across all versions; money MSFT probably figures can be better used elsewhere. Office already invests a lot of money in backward compatibility, coding as well as testing.

Another might be that MSFT policy for over ten years has been that one should not install more than one version of Office in-parallel. Providing version-neutral IAs would be in violation of that policy.

Then there's the .NET philosophy which says: for each application version, a single software version. Of course, in the .NET world one can also install those versions in-parallel in the GAC, which is not true for Office applications (DLL-He**).






Re: Visual Studio Tools for Office Fixing Bad Office.Core Refernce in xl2003 Application Add-In

Dennis Wallentin

Cindy,

As long as the PIA is outside the control of the VSTO team then it will have no priority at all.

The backward compatibility was already broken when 2000 was left out (or perhaps it's more correct to say when 97 was left out when it become possible to create unmanaged COM Add-ins in 2000).

Then there's the .NET philosophy which says: for each application version, a single software version.

...Providing version-neutral IAs would be in violation of that policy.

That's why customers request .NET based solutions where a mix of Office versions are in use. Or have You never faced demands like this in the real world

BTW, to some degree the above reminds me about using Office on Windows servers. We all know that it's not recommended but due to real world practical aspects it's done. Yeah, I'm already aware that VSTO can be used in this context so I don't need any write up on that too






Re: Visual Studio Tools for Office Fixing Bad Office.Core Refernce in xl2003 Application Add-In

Cindy Meister

<<The backward compatibility was already broken when 2000 was left out (or perhaps it's more correct to say when 97 was left out when it become possible to create unmanaged COM Add-ins in 2000). >>

Actually, I was thinking specifically of backwards compatibility within the UI, the object model and the file formats. Not about support for COM Add-ins, which were quite a new concept in the late 90's, when Office 2000 was in development. The days when VB6 was all new and shiney...

From what I know about how flakey the automation interface as well as application reliability in Word and Excel were in version 97 (and with Word, I know quite a lot), you can be happy MSFT has taken that out of the mix for you. Supporting that in a multi-version Add-in would be a nightmare. I had to do a VBA-level (template) mixed Add-in for 97 - 2003 a couple of years ago. The number of things that worked great for all versions... except 97 and required hair-raising work-arounds... <shudder> And Powerpoint didn't even have an automation interface back then :-)

As a matter of fact, I'm just as glad that 2000 was left out of the "official" mix (PIAs), as well, when it comes to Word's object model: almost no events, and some really weird things happening in odd corners of the object model. But still much better and more stable than 97. Actually, in my personal opinion, Word only became ready for the "big-time" with version 2003. Excel is different, of course, having had an object-oriented object model since Excel 95 and the C API for even longer.