---

[Ofer Goren is a frequent guest in this blog. He has posted here on his experiences with multicore optimization, as well as a follow up post to that. Today's treat is of a frequent developer problem - backwards compatibility.]

As mentioned in one of my previous posts, we do have customers. Some of those customers do have special needs (don’t they all?). Lately, one of our customers asked us to update our workspaces, so that they can use our product with Microsoft’s Visual Studio 2008.

The Whole IDEa

Up until now, we had two types of solutions for the Windows platform flavor of our toolkit: the “legacy” Visual Studio 6.0 (or VC6) .dsw files, and the Visual Studio 2005 (or VS2005) .sln files. That was OK, because we actually had to support only one type. After all, who else but us still uses Visual Studio 6.0? But we liked it: the IDE was clear, menus were fine, Visual Assist supported it — We were happy. In fact, most of our development was done using this IDE version, while Visual Studio 2005 was used mainly for testing before releasing new stack versions for those of you out there, the adventurer types, who call a 2-years-old technology “new”.

The New Found Problem

We have many customers. It’s a problem. We want to support them all. It’s even a bigger problem. If they want to work with VC6, we should have a solution for that. And if they want to work with VS2005, we should also support that.

From file-tree perspective, we need to support these two options at the same time. We also have to support Unix and Linux flavors, as well as other embedded operating systems, but that’s a different story.

Back then, when we added support for VS2005, life was easy. VC6 had .dsw and .dsp files, and VS2005 had the matching .sln and .vcproj files. Two different set of files, unique extensions. But how do you support two versions of the IDE that have the same file extensions?

You see, with Visual Studio 2008 (VS2008), Microsoft didn’t change the file extensions. You have the same .sln and .vcproj files as in VS2005. The contents are different, but the extensions are the same. We needed to differentiate them somehow, but not work too hard on maintaining those 2 sets.

And it gets worse: If you try to open a VS2005 .sln file in VS2008, it will automatically convert it and all of its contained .vcproj files to VS2008 format. If you then try to re-open them in VS2005, Visual Studio will tell you that you can’t:

Why? Because they can. A possible solution for this may be to put the VS2008 .sln files in a different folder than the VS2005, but our customers are already used to finding our .sln files and Makefiles (for non-Windows OS) in the same folder. We can use 2 different sets of files, but we will have to maintain them, which is time-consuming. And we also had to think of the future – after all, VS2010 is coming, and the VS train doesn’t stop there. The horror…

This was frustrating, really. I get that some general information about your project should be aggregated in some file: dependencies, project settings and such. But what crucial information should be saved there, that needs to be different between versions? How come no one thinks of me, the programmer, at the end of the fool chain, who needs to support (at least) 2 Visual Studio IDEs in parallel?

The Easy Solution is Always Worth a Shot

Yes, we eventually decided not to support that customer, and asked him to contact our competitor. Hopefully, no other customer will have such a ridiculous request.

Well. Not really. Our PM didn’t really agree to that solution.

Alternate Ending: A Real Solution

My bosses in Radvision have foreseen the future, and sent me to a Perl course a while ago. Seeing that it was good, they said “let’s send him to another course. Maybe cooking. With enough courses, the solution will eventually present itself”. I didn’t object, of course, but the budget controller did. So it was just Perl.

We decided that all of our engineers will start working with VS2008 when developing. And we will maintain 2 sets of .sln/.vcproj files: VS2008 files will have the suffix “_vs2008″ added to them; VS2010 files will have the suffix “_vs2010″. And VS2012 files? We’re just programmers. We’ll have to wait for the PM to decide what suffix to use there.

And, we will write two Perl scripts:

The first will be used once, to duplicate all our .sln/.vcproj files while concatenating their copies with the new suffix to their names. The script will also update the internals of the .sln files to use the new project file names. We have dozens of .vcproj files, so an automatic operation of a script is required. Once done, the rest will be magically completed by the upgrade wizard of VS2008. We’re even making this wonderful script available to you, if you think it might assist you. Just follow this link.

The second script will be used to downgrade the VS2008 files to VS2005 files before releasing new versions to customers. So we will need to maintain two (more in the future) sets of VS files, but scripts will be used to do the editing tasks (removing new attributes added to new .sln files , altering .vcproj files, etc.), and all we will need to do is to just check that everything is compiling and running at the end.

And voila —

Before	After

Conclusions

Here’s my 2 cents (hey, there’s a recession going on!):

• When developing a system, think about the future as well. In the VS case, I don’t see any reason why VS2005 shouldn’t open VS2008 .sln files, chew up everything it can, and drop everything it doesn’t understand.
• On the bright side, XML is a good option when considering making a configuration file, as in the case of .sln and .vcproj files. A simple scripting language can then greatly help when deciding to do some automatic operations on them.

Oh – and choose your customers wisely.