Mike Feltman

I recently had the opportunity to discuss whether or not Visual FoxPro should be included with Visual Studio.NET or made a standalone product again with some of the members of the Fox Team at Microsoft. The Fox Team is very interested in hearing what the community thinks about this. The following is my opinion on the subject. It doesn't necessarily represent the Fox team's opinion.

Visual Studio 7 or Visual Studio .NET, along with many other things, is the fruition of Microsoft’s long-term goal to have their development tools share a common IDE. In VS.NET VB, C++ and C# all share a common IDE and toolset. Previous versions of Visual Studio were nothing more than a bundle of Microsoft’s development products, but VS.NET actually makes Visual Studio itself the product and makes the choice of development language somewhat of an irrelevant afterthought. The one development tool that does not share this common IDE and cross-language capabilities is Visual FoxPro.

Visual FoxPro 7.0 differs from the rest of Visual Studio .NET in several ways:

• It has its own database engine.

• It has techniques for accessing remote data that are unique to Visual FoxPro.

• It does not use the common language runtime.

• It will continue to make use of COM and COM+ to communicate with external objects instead of the new mechanisms available in VS.NET.

• It has its own set of design surfaces that differ from the rest of Visual Studio.

• Visual FoxPro provides many features that are not supported by the common language runtime.

• Visual FoxPro 7.0 code will not run in the managed code environment and will most likely outperform VB and C# code written to perform the same functions.

• It provides backward compatibility with previous versions.

• It has a proven track record of performance and stability.

Given that VS.NET is now a product in itself, verses a product bundle, does it make sense for Visual FoxPro to continue to be bundled with Visual Studio? Is it more advantageous for Visual FoxPro to attempt to explain how it fits in with Visual Studio than it is to simply say that Visual FoxPro is a different animal? These are the tough questions that the Fox team must consider and answer.

There are strong arguments for keeping VFP in VS and strong arguments for making VFP a separate product as well. I’m going to attempt to present both sides here.

The Pros of Removing Visual FoxPro from Visual Studio

If you’ve seen the Visual FoxPro 7.0 beta and the Visual Studio .NET beta, it’s clear that Visual FoxPro 7.0 is much further along and closer to being ready for release when compared to the rest of VS.NET. If Visual FoxPro were to be removed from Visual Studio it could be released prior to VS.NET. It’s my understanding that Microsoft policy prevents Visual FoxPro 7.0 from being released separately from VS.NET if it remains a part of Visual Studio. Assuming VFP could be released separately from VS.NET, there are many benefits to releasing VFP first:

• Visual FoxPro could be marketed stand-alone instead of as a side note in the VS.NET marketing material.

• Visual FoxPro could be marketed on the strength of its features.

• VS.NET is focused on the enterprise. VFP marketing would be free to point out that VFP is well suited for traditional LAN, desktop and client-server applications as well as enterprise (web applications).

• VFP would be reviewed independently instead of just mentioned in passing in reviews of the complete VS.NET product.

• If VS.NET flops, or is underwhelming in its functionality, reliability, market acceptance or in other dimensions of success, then VFP isn't tarred with the same brush. (The last time Microsoft created, from scratch, a great developer product was when, exactly? And it took that product how long to get from scratch to great?.) -- StevenBlack

• VS.NET is being called the distributed application development environment by MS while MSDN is being called the developers tool set. MSDN includes VS as well as other tools. Since VFP is not being evolved into a specialized distributed application development tool and it is the one tool that will still be realistically usefull for building desktop applications it makes sense to NOT have it in the VS.NET box but in the MSDN box instead. JimBooth

• VFP will not be subjected to ridicule in VS reviews as a tool that's part of VS in name only. Whether or not it comes in the box, it's simply not a part of Visual Studio - the product, to the same or a similar degree as much as VB, C# and c++ are.

After the initial release of VFP 7 and the release of VS.NET, there are also long-term implications to consider for VFP 7:

• VFP can continue to be marketed as an alternative as well as a complement to Visual Studio. In other words, the Fox team can now market VFP as a development tool for LAN, desktop and client-server applications as well as a provider and consumer of web-services.

• The Fox team and community can spread the word of VFP’s reliability, performance and backward compatibility. In comparison to VS.NET, which is basically a 1.0 product, this is a big win for Fox.

• Future versions of Visual FoxPro can focus more closely on the features that are important to the Visual FoxPro developer community instead of being tightly focused on how to make Visual FoxPro fit in with VS.NET.

• Service packs for VFP would be available separately and released when they are ready instead of whenever a complete VS service pack ships!

The Cons of Removing Visual FoxPro from Visual Studio

• The primary con in removing Visual FoxPro from Visual Studio is perception. Many nay-sayers will say that this is clear evidence of the death of Visual FoxPro once and for all. For the most part, I think these will be the same people that are already making these statements, so the net effect is basically zero. The reality of it is that whether or not Visual FoxPro ships in the Visual Studio box, it’s not a part of VS.NET. There are developers that are able to use Fox today because it is a part of Visual Studio. Some of these developers may be lost, but the reality of it is that if they have to justify their use of Visual FoxPro on this basis, then they still may be lost anyways when VS.NET ships.

• There are some new VFP developers that picked up VFP and decided to use it because it comes in the Visual Studio box with the rest of the tools. Removing VFP from the VS box may mean that VFP will no longer pick up these new developers. Conversely, more developers may be gained by separate marketing and inclusion in MSDN.

• Marketing may not improve or increase.

• Some developers have been able to justify their use of VFP because it is in Visual Studio. Some of these developers feel they will no longer be able to justify using VFP if it is removed.

Conclusion

I think the pros greatly outweigh the cons in both the long and short-term. If future versions of VFP fit more closely with the VS model then there’s nothing that would prevent VFP from becoming a part of Visual Studio again. If the message from Microsoft is clear that it was the decision of the Fox team to remove VFP from Visual Studio and the reasons for doing so are stated strongly, I think the overall perception will be positive. Remember, there were Fox developers that didn’t like VFP becoming a part of Visual Studio in the first place. If Fox developers are armed with the right facts and really want to help their customers choose the right tool for the job then there will be places for both VFP and VS.NET applications.

One of the issues that keeps coming up is marketing. I obviously can't speak for Microsoft in terms of how VFP would be marketed, but, consider this.

Here are some of the key features in VS.NET:

• the CLR,

• one IDE for VB, C++, C# (with limited support for VFP PRG files.)

• easier deployment

• the new IDE with tools like the "Server Explorer"

• Web Forms

Is VFP a player in all of this? No. You might see the VFP logo in the ads because it's in the box, but when MS marketing starts trying to spread the message of what VS.NET is, there won't be any significant mention of VFP because it's not a part of it whether or not it's in the box.

I can imagine how the reviews will go... Visual Studio.NET does this and this and this and this and oh BTW, Visual FoxPro can't do any of this, but it does now have flat toolbar buttons.

I don't really know what will happen if VFP is marketed by itself, but I'm fairly certain that it will be completely lost in the VS marketing.

RobertGreen recently commented on this subject on the Universal Thread. IMO, his most poignant comment follows:

"To be perfectly honest with you, our ability to do that (market VFP on its strengths) is greater if VFP is not in the VS box. If VFP is in VS, it has to have a VS story. In 6.0 that meant middle tier and DNA. In VS.NET that means the next generation of Web apps. If VFP is not in VS, then we can have our own story, which means we can go back to bragging about the things that Fox does best."

Off topic comments have been moved to ShouldVFPBeInTheCLR and WillMicrosoftMarketVFP. My apologies to anyone that feels their comments have been unfairly snipped. There were a lot of things raised here that weren't really on topic and this subject had denigrated badly into Thread Mode. These topics are obviously closely related to this one however. -- MikeFeltman

Since this is now a done deal, I removed the thread mode stuff that was in this document. -- MikeFeltman (See _WillMicrosoftMarketVFP_HowItStarted for excerpts)

See also: Microsoft FoxPro People: Mike Feltman