Dear Alex,

>I wonder how realistic it is to develop BO classes with VFP with the view of later resusing them from .NET, if or when I get to that. Any comments?

It all depends on how much you'll actually reduce. I think there are some scenarios where Interop makes good sense, and those are:

- If you have components that you have to share among VFP and .NET applications
- If you have lots of properly built Business Objects that you can reuse from a .NET layer without rewriting much of them
- If you have BOs that handle very specific things that are more complex to handle in .NET like formula evaluation, etc (although there are some available solutions for that provided by the .NET community)

What I saw in some ituations is that people "think" that Interop will allow them to leverage all the logic they have in VFP from a .NET (typically ASP.NET) facade. The problem is when the VFP code is not properly layered, it is *very* stateful, or have some inherent complexities that make hard that reuse in practice. Then some people find tehmselves rewriting lots of VFP BOs just to be able to use them from .NET.

That could buy you some problems because going from one platform to another is never as easy as being in just one side. Debugging is harder, even if you research a bit and put some mechanisms in practice to improve COM debugging, and your best bet could be read a book or two about COM Interop to know what kind of quircks you may find. (By the way, I just posted yesterday a link to a free eBook on the subject in the VFP & .NET category)

If you have to rewrite a lot, it is better to stick to a single platform. That being said, as we talked the last time in Buenos Aires, from a purely technical perspective, VFP could be a better platform for your applications -maybe. There are some other reasons, like the available human resources and such, but VFP could still be better for some scenarios, not tlking about learning curves, etc.

Un abrazo,