Again, are you trying to load the component into Visual Studio at design time? I think that's not what you want, but you're making a common mistake by people coming from Visual FoxPro.

With VFP, it's VFP all the time. The language, design time tools, and runtime libraries are all intertwined. Visual Studio is simply a design time tool. It has nothing to do with running an application. There are multiple things involved with creating an application with Visual Studio. In fact, you can create .NET applications without Visual Studio and using only free tools.

- Visual Studio. The design tool and code editor
- Language. Generally a .NET language such as C# or VB. Each has it's own compiler that is not part of VS. The C# and VB compilers actually ship as part of the Framework.
- .NET Framework. A group of classes that can be used by the language. It is separate from the language and VS.
- .NET runtime. The program created in the language is compiled into a .NET assembly (DLL or EXE) and then executed by the runtime.

Each of these can be shipped on different release schedules. And, in fact, .NET 3.5 was an update to the Framework, runtime, and languages, but not Visual Studio. Microsoft sees these as three different teams, Visual Studio shell (common VS components), Languages, and .NET. Until earlier this week, the .NET team reported to a different person than the other two teams. They now all report to Jason Zander.

So, what I think you're asking is, "What type of COM component can .NET host?" The answer to that question is EXE, DLL, and OCX. VFP cannot create an OCX. Rick Strahl has written a couple of articles about .NET and VFP/COM interop.


>>- You can't access the cursor in the COM component from the host and vice-versa.
>
>Good to know...I created a table and wrote the set('directory') value to it. That worked. Sergey B. also has a simpler solution.
>
>>- A VFP COM DLL cannot have any UI, but a VFP COM EXE can
>
>I don't need any UI, was just to find out what location I was at when the COM object loaded. Can VS 2008 load either a VFP COM DLL or a VFP COM EXE?
>
>>- Not sure what you're asking about in question 2. Are you trying to load a VFP COM object in Visual Studio at design time?
>
>No, I'm actually testing it from VFP. The VS side of this has not been written yet. The question actually relates to what type of COM object VS 2008 can load (see above).
>
>Thanks Craig!
>
>Scott