I recently sat down with my new employers to plan out our product development strategy for the rest of 2010. The discussion surfaced issues that we have in common with every ISV who uses Microsoft Visual Studio: when to switch over to Visual Studio 2010 internally, when to target .Net Framework 4 internally, and when to plan to release new product versions built on those new technologies.
One of our developers has been tracking the Visual Studio 2010 betas and release candidate, successfully compiling and linking C++ modules, one at a time. His short summary: "Most of the hard work was done when we went from Visual C++ 6 to Visual Studio 2005, and some more when we went to Visual Studio 2008. While we still have some code adjustments to make for Visual Studio 2010, they aren't difficult: just tedious. Meanwhile, the code generated is faster, although a bit larger than our shipping product."
[ Get an inside look at what to expect from Microsoft's Visual Studio 2010 with Martin's "InfoWorld preview: Visual Studio 2010 Beta 2 impresses." ]
As for making the switch to Visual Studio 2010 internally, we'll branch our source tree for new development as soon as the entire product builds in Visual Studio 2010. Externally, we'll keep shipping our existing product compiled the same way it has been for the past year, and we'll only ship our next-generation product with Visual Studio 2010.
"We have a complex product that needs significant testing before we ship," the developer added. "If we use the Visual Studio 2010 builds internally for the new product version, we'll have most of the compiler-related bugs flushed out by the time we're ready to go into beta testing. But shipping a stable product with a new compiler would just be asking for trouble."
What about .Net Framework 4? The biggest win for us in .Net 4 is the Dynamic Languages Runtime, since we have a dynamic language (Xbasic) as part of the product. We're already in the process of moving some of our functionality to the .Net Framework, which expands our capabilities and reduces the size of our own code base. Again, we'll start using it internally shortly after it ships, but we won't ship it with our current product: We'll need the time to dog-food our .Net code as we develop.
Your situation might be different, but your concerns and considerations might be similar to ours. What is your shop planning to do?
This article, "Making the switch to Visual Studio 2010," was originally published at InfoWorld.com. Read more of Martin Heller's Strategic Developer blog and follow the latest news in Microsoft Visual Studio and software development at InfoWorld.com.