Other than by creating a library which sets up a reference to office.dll, etc., how does one access Microsoft Excel? It seems we can't reference the assemblies in C:\Windows\assembly. It just won't let me. Is there something I'm missing? As always your sage advice would be welcome.

If we can't reference the assemblies in C:\Windows\assembly, we possibly wouldn't have anything working at all - like any functionality that references System, System.Drawing and System.Forms.

Start with describing what you are doing to produce the problem - the References window? or is it a "using" directive?

You would reference a DLL placed in Wealth-Lab main directory via a call to the "using" directive in your Strategy code. If you bring up the References dialog, then by simply checking the appropriate assembly it's possible to reference from that static list. For assemblies somewhere else on your disk, use the "Other Assemblies to Reference" dialog.

Thanks for getting back so quickly. Fair point.

1. I open the reference window
2. I click on other assemblies to reference
3. I cilck on add a reference
4. I move to the folder C:\Windows\assembly
5. I double click on office or Microsoft.Office.Interop.Excel
6. Nothing happens. Nothing in the FileName textbox and doesn't return to the main references form

I hope that's clear now. So, no I am not able to create an appropriate using directive yet.

Oh and the office assembly doesn't appear in the .Net framework list, not that I can see obviously anyway.

QUOTE:
6. Nothing happens. Nothing in the FileName textbox and doesn't return to the main references form

It happens here too, but is there a point to do that if all these references are already available on my static list? I'm not sure why doesn't your interop DLL show up on the static list. Does it work in other applications?

The reference isn't available on my static list. And here's what I need to do for my library

1. Start Microsoft Visual Studio .NET.
2. Select my Library.
3. On the Project menu, click Add Reference.
4. On the COM tab, locate Microsoft Excel Object Library, and click Select.
5. Now add in the follow directive: using Excel = Microsoft.Office.Interop.Excel;

What this does is sources the appropritae details from Excel.exe and then creates three references. But you know this.

And I've checked and triple and quadruple checked my static list. Nothing.

I'm not sure what you mean by

QUOTE:
Does it work in other applications?

BTW I just drop MyLibrary.dll into the same directory as the Wealth-Lab application and so I don't need to think about creating a reference to it.

QUOTE:
4. On the COM tab, locate Microsoft Excel Object Library, and click Select.

Wealth-Lab's dialog is for .NET assemblies. A COM one won't show its face on this list.

QUOTE:
What this does is sources the appropritae details from Excel.exe and then creates three references. But you know this.

I'm not sure how does creating a COM wrapper in Visual Studio affects the availability of Excel's namespaces in the GAC?

Well, it shouldn't should it. I have no idea why Wealth-Lab is not accessing the namespaces in the GAC, but it's not. Instead I'm having to create a class wrapper in my library to do what I need.

The life of programming has a bit to do with workarounds. Is there anything you need for me to investigate this problem from my end to help with availing a solution?

QUOTE:
I have no idea why Wealth-Lab is not accessing the namespaces in the GAC, but it's not.

Are you able to reference Microsoft.VisualBasic or System.XML from the static list?

QUOTE:
Are you able to reference Microsoft.VisualBasic or System.XML from the static list?

I can access both from the list.

BTW, if anyone is following this and has the same problem, here's my workaround.

CODE:
Please log in to see this code.

QUOTE:
I can access both from the list.

Which looks like it's generally possible for you to reference assemblies in the GAC, and the problem is just with some particular assemblies. One more question: are those interop assemblies compiled against version 2.0 (as I'm trying to find the reason why aren't you finding them on the static list)?

CODE:
Please log in to see this code.

[/CODE]
I was just asking about if these assemblies can be accessed in other app of your choice as if they were in the GAC (as you understand, the COM tab in VS is a different story).

QUOTE:
One more question: are those interop assemblies compiled against version 2.0

I have no idea. How do I find this out?

QUOTE:
How do I find this out?

I thought you knew their target platform, because you were creating these interop libraries by selecting Microsoft's COM objects:

QUOTE:
3. On the Project menu, click Add Reference.
4. On the COM tab, locate Microsoft Excel Object Library, and click Select.

Anyway, Control Panel - Admin - Microsoft .NET Framework 2.0 Configuration ... - Assembly Cache.

If they are in the GAC as you imply, they have a version number at the right.

QUOTE:
Anyway, Control Panel - Admin - Microsoft .NET Framework 2.0 Configuration ... - Assembly Cache.

If they are in the GAC as you imply, they have a version number at the right.

That version number is 12.0 for both office and Microsoft.Interop.Excel. in the GAC and in Visual Studio has a TypeLib version of 1.6. This is what confused me.

In control panel Administrative Tools when I go under class view, because I'm running Vista I Imagine, there is no Microsoft .NET Framework 2.0 Configuration option. In fact I can't located it anywhere obscure within Administrative Tools. BUT. My .NET framework is 3.5 SP1. Does that matter?

Wealth-Lab is built upon .NET 2.0. I believe a .NET assembly has to be v2.0.50527 to appear in the static list of WL and therefore be accessible.

Which version of VS do you have? If it's 2008, then it defaults to .NET 3.5 for a new project. So my idea was to check if those COM interop assemblies were properly targeted for .NET 2.0. Hope it's clear.

QUOTE:
Which version of VS do you have? If it's 2008, then it defaults to .NET 3.5 for a new project. So my idea was to check if those COM interop assemblies were properly targeted for .NET 2.0. Hope it's clear.

Yes, I'm running Visual Studio 2008. And the library class I built runs well with Wealth-Lab.

Hi Eugene

I'm just wondering where we're up to on this.

Cheers
M

I'm a long-time OpenOffice.org convert, so these COM interop binaries could not be installed on my machine to test. However as seen in your reply from 10/13/2008 6:19 PM, WL5 is able to properly reference assemblies on the static list - in the GAC. What I was suggesting is to check target framework version numbers, then see if other program like VS or SharpDevelop is able to find these assemblies without creating a COM interop like you did - have you done any of those tests?

Well, I accessed them from a library that I created in Visual Studio and that's good enough for me for the time being. And maybe I'm the only one on the planet that wants to do this kind of stuff who happens to have Vista. Visual Studio accessed them just fine, but it did its own handling, it created all the accessing via the Interop.

QUOTE:
Visual Studio accessed them just fine, but it did its own handling, it created all the accessing via the Interop.

Isn't that perfectly fine as long as those Office libraries were COM?

I mean, the next step. VS have created these interops for you. Could you reference these created assemblies as if they were in the GAC? If they are not in the GAC, as I suppose, WL5 has nothing to do with it.

Your supposition is right. I cannot directly access the Interop via the GAC from within Visual Studio even it appears in Windows\assembly; it must be as a COM. So, via a library it is.