I must be missing something in your requirements.

Where does the data reside? In VFP tables or in sqlserver? Or elsewhere?
Where is the first point where the data is loaded into user controls? VFP or a vb.net winform?
Is it necessary to display the data (or the modified subset of the data or what exactly) in VFP after vb.net has done something with it? And vice versa?
If you really need for VFP and vb.net to massage the data and both see the results somehow (I'm not clear on your overall goal and requirements) why not have both access the data and use event firing in vfp from .net and vice versa to tell vfp to go out and get the massaged data (or vb.net to do it) itself instead of actually passing back and forth that much data. Can you store the results (whatever vb.net has done with it) to a backend and just fire an event in vfp from vb.net to tell it to go out and get it instead of passing +-200mb of data around?

Why are passing +-200mb of data back and forth?
Can you be a little clearer on what the goal is and how you expect it to behave?

Regardless, if you need to throw events in either or both from the other or pass data back and forth, Thomas is correct that the com interop dll must be registered on the machine to use it from vfp (and all the com interop design must be done correctly). It may be easier for you to go with the ww stuff - simpler from your end.

I guess I though the vb.net piece was someone else's (3rd party) and not yours. Is that the case or are both the vfp and .net pieces something you own and control? That will make a difference in your options.


>We are using WinForms with VB.
>
>We need to pass +/- 200MB of table data to .Net UI controls and to get some table data back from those controls into VFP.
>Would it be better to :
>A) Host all UI Controls in a WinForm and just pass table data to and fro from VFP and we would call the Winform from VFP and EventBind etc (This is our preference)
> or
>B) Host the .Net UI controls on a VFP form and access the .Net Controls from within VFP ?
>
>We have never done ComInterop before - what is the performace like especially when passing large amounts of data such at 200MB ?
>
>Thanks for all the replies posted for far
>
>>But you don't need the VB interop toolkit for that, at least not to pass and receive data from a .net dll in VFP or fire events in VFP from .net. We do that now via com interop...
>
>>>The VB Interop Toolkit definately works with VFP. But you don't need it for ActiveX controls as they "just work" on a VFP form. What the toolkit does is allow you to call VFP code from .NET and vice-versa and even have events in one environment fire code in the other.
>>>>
>>>>Hi Jared,
>>>>
>>>>I have not used the VB Interop Toolkit, but my understanding is that it is supposed to work with VFP. If you're wanting to put .NET components on a VFP form (like an ActiveX control), then I think it is your only option. Otherwise, I would steer you towards wwDotNetBridge, which gives you more complete access to the .NET framework without COM wrappers. I believe it will let you open a .NET form in VFP, but you'll want to double-check on that:
>>>>
>>>>http://www.west-wind.com/webconnection/wwClient_docs/_24n1cfw3a.htm
>>>>http://www.west-wind.com/wwClientTools.asp
>>>>
>>>>As Tracy said, you could make .NET the host environment for your UI and put VFP code in a COM object. That may be a better choice if you'll be rewriting your entire UI at once. You can host a VFP form in .NET using the SetParent() API, but that's kind of a hack. It depends on who you want to do the driving.
>>>
>>>By the way, what will you be using for the new UI: Winforms, WPF, or SilverLight?