Expert Texture Home Contact me About Subscribe Digipede Connect on LinkedIn rwandering on Twitter rwandering on FriendFeed

rwandering.net

The blogged wandering of Robert W. Anderson

Journey to .NET 2.0

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.

Tags: , , ,

    Trackback

3 Comments »

    Trevor Carnahan wrote @ January 17th, 2006 at 5:18 pm

Some great posts in here. I’ve got a question for you, and I’m hoping you get get me pointed in the right direction.

I am currently architecting a new Asp.Net 2.0 application. I need to rely on a. ADO.Net 1.1 data provider for my legacy database (Sybase ASE 12.5). When I create a binary reference in my 2.0 project on a 1.1 assembly what is the internal clr result? Will the 1.1 assembly run in the 2.0 clr? Can I programattically as the clr to load it in a 1.1 clr if it available? Is there any extra marshalling required if I take that approach?

This post gives me the impression that you have had to deal with some of these kinds of scenarios and might be able to point me in the right direction.

Thanks in advance!

    Robert W. Anderson wrote @ January 17th, 2006 at 7:01 pm

Thanks for the comment / question.

The short answer is that:

We do run .NET 1.1 assemblies in .NET 2.0 as a matter of course, actually. I’ve seen no problem to date.

Cheers,
Robert

    Trevor Carnahan wrote @ January 18th, 2006 at 8:45 am

Thank you for the response Robert. You confirmed my understanding of how the clr works. And it’s nice to know that other professionals are using the binary assembly reference approach for legacy 1.1 assemblies in their 2.0 applications as well.

Fortunately, there shouldn’t be any compatibility issues for our application as it will only be used to execute stored procedures in the normal fashion.

Thanks again.

Your comment

HTML-Tags:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>