After some discussion about the timing of a move to .NET 2.0/VS2005, we have decided to take the plunge and natively build for .NET 2.0 for (a currently planned) release in November.  The main reason we have delayed in this decision is that we need to continue supporting current and prospective customers who, for various reasons, are not ready to move from .NET 1.1.

There are a couple of things about our product that make this a bit more complicated than simply upgrading all of our VS2003 projects.:

1.      We offer a .NET API to our product.  Since we are committed to supporting .NET 1.1, we will have to continue maintaining a 1.1 version of the API’s main assembly.

2.      The Digipede Network can instantiate distributed objects, serialize them, and return them to the caller of the API.  If the caller is using the .NET 1.1 CLR then the serializing assembly cannot be running in a newer CLR; otherwise, deserialization errors will occur. To solve this problem we need to select the proper CLR based on characteristics of the caller (or, more practically, on configurable requirements).

These details are worked out (and basically functional), so what is left is integrating the new tools into development, build, and test.  We have already tested it all against .NET 2.0, so there is little concern there.  The CLR team has done a great job on compatibility.

Integrating the tools is (mostly) straightforward, but includes nant, NDoc, ResHacker, FxCop, Dotfuscator, NUnit, NCover, XHEO, Infragistics, NDepend, and Resharper. 

Some of these are critical for our commercial release and some can be dealt with later.

I’ll continue to post about this port with any gotchas I come up with.