>I believe we did as described in http://www.devx.com/codemag/Article/22404/1763/page/2 by, if memory serves me right, Claudio Lassale along with articles by Rick Strahl, but I don't get intellisense.
>
>Well, strictly speaking, I guess I do - but not quite what I expected.
>
>I also run:
>%systemroot%\Microsoft.NET\Framework\v1.1.4322\regasm.exe comtest.dll /tlb:.\Com.comtest.tlb
>%systemroot%\Microsoft.NET\Framework\v1.1.4322\gacutil /if comtest.dll
>
>Regardless, the intellisense popup always only displays Equals, GetHashCode, GetType and ToString, which appear to be some sort of default.
>
>TIA
>
>Peter

A couple of things...

Try using the /codebase in addition to /tlb when registering your COM component with regasm. I note you are putting your assembly in the gac, so this may have no effect. I can't tell whether you are using an invisible class here or a usercontrol of some sort. If it is a usercontrol then you are going to want to ensure that it was created using the VB Interop toolkit or that the .NET assembly has code for registering and unregistering the "control" key for the ActiveX when regasm is applied to it (see steps 11 and 12 on my blog entry http://www.sweetpotatosoftware.com/SPSBlog/PermaLink,guid,3dd24f92-a52c-4bb0-8121-c2e6e2cc4f93.aspx)

COM visible assemblies are usually coded to provide exposed interfaces for the exports (see steps 6 and 7 in that same blog entry above, I think I saw Cetin had said something about this to you as well). If the assembly you are registering doesn't have, then it will only expose (surface) the public methods and properties (such as the ones you are seeing in your intellisense popup) - regasm actually does this by inferring the interface(s) for you (see my comment regarding this being a bad practice below). If you have access to the source for the .NET assembly then go in there and expose the other methods/properties you want to see. If you don't have access to the .NET assembly's source, then you'll need to create your own .NET COM visible wrapper (your wrapper will speak to the .NET dll's classes and VFP will talk to your .NET wrapper).

As an side, it is really bad practice to just allow regasm to infer COM visible classes/methods/properties based on their scope (public). When the vendor (of said assembly) comes out with a new version and you register it again, the guids will be different and stuff will break and you'll have to issue an update for your application as well to work with the new.

The only time I've seen VFP needing to be shutdown, is when I am actively working on a COM visible .NET assembly and testing it in VFP at the same time. Basically, this is a bug (don't worry it exists in VB interop stuff). I was with YAG several years ago, and showed him this bug... he called in and the devs told him that they were aware of this (they were mumbling something about hard locks and a dangling reference - sounded like a punt to me, but YAG did what he could which I appreciated at the time), but it doesn't appear that it can or will be fixed. Not that big of a deal to shut down the VFP environment between .NET assembly builds I guess... just mildly irritating mostly.