Peter Duniho said:
There is.
http://msdn.microsoft.com/en-us/netframework/aa570326.aspx
Here's the page specific to ASP.NET run-time changes (i.e. those that
would affect an already-delivered web app):
http://msdn.microsoft.com/en-us/netframework/aa497240.aspx
It wasn't an ASP.NET change that was relevant in my case but something
with Windows Forms. The guy used Windows Forms classes to construct a
client side control on a web page -- a grid with a bunch of extra
features. Actually now that I look over the first link you gave, it
might have been something in System.Data too. It's been a while
though. I'd have to review the changes to remember it exactly.
There are similar pages for the more recent versions, though of course
there's a _lot_ less to document in those cases.
As you can see from reading through the documentation, many of the
changes are either security issues or affect only those applications
that are doing something non-standard or invalid anyway. .NET 2.0
added better security, and does more/stricter data validation. In
other words, applications affected by those kinds of changes ought to
be updated anyway.
Even with the large degree of changes between 1.1 and 2.0, the large
majority of pre-2.0 .NET applications work fine on .NET 2.0 and later.
There will be exceptions, to be sure...but one should not assume there
will be a problem.
Pete
Okay, but one should also not assume that there will not be a problem.
This is the difference between backward compatibility and close to
backward compatibility. It made my company look bad and gave me some
unexpected extra work to do. It should not be an unexpected sort of
thing, perhaps, that development tools and runtimes change. When we
changed C++ compilers we had lots of work to do too. The nasty thing
in this case was that it happened outside of our control at the
client's site without us being around and the error messages weren't
very helpful, leaving me with some interesting detective work to do.
The client upgraded to .NET 2.0 for a separate application. Because
of the way the, what's it called again, Internet Explorer 6's .NET
container picked the run time to use it hit us by surprise. If I
remember rightly, even though both 1.1 and 2.0 were installed, it
picked the most recent runtime they had instead of matching the
runtime to that noted in the assembly metadata, as it would have done
if it were a simple Windows Forms application and not a client side
control on a web page. Reminded me of the old descriptions of DLL
hell, which I haven't really experience myself with our native code
because of how we deploy our libraries.
That said, I'm not sure why installing various CLR versions is such a
concern for the original poster (assuming he's not silly like we were
and isn't using .NET for client side web controls). Java has dealt
with this sort of thing for years. Are people so resistant to
installing multiple runtimes? With the popularity of .NET, they'll
eventually have most of them anyway if they're running Windows. If it
is a genuine problem, then I'm told Delphi is a pretty good dev
environment still. Perhaps it would be a better choice. Or Tcl/Tk
has a very interesting deployment model with its Star Kits or whatever
they're called.
.