Jim said:
Correction: Microsoft's list.
Fix-lists are good for seeing how actively things get fixed, their level
of detail reflects how maticulous the bug-tracking is.
This makes fix-lists a very bad tool for evaluating stability for a
specific application, but a very good way to evaluate which effort, and
quality of effort is put into improving erorrs.
If the list spreads FUD, then it is because it is interpreted wrongly.
To me it indicates that an active effort is done to improve .NET.
What would be cool is if Microsoft allowed you to actually download the
fixes WITHOUT having to call and talk to a Microsoft rep. This calling for
every fix is beyond stupid. Not to mention it's absolutely atrocious
customer service.
Actually, I haven't needed any of the fixes yet, but if such a
requirement exists, then I would agree with you; that's simply silly.
If the .Net framework (which has an integrated browser) checked for fixes,
told us what the fixes affected and allowed us to select which fixes to
install it'd be more on par with the Windows Update service.
That would be a nice feature. An API for doing it programmaticly would
be even nicer.
Being able to identify which fixes have been installed would be
marvelous (inspecting the registry sucks, it would be nice to have it
"from the horses mouth": the binary).
But, doing so would show that the .Net framework is no the end-all-be-all
solution that Microsoft said it was.
That's what fix, SP, "new version", etc. means. Everyone has to start
somewhere, code has bugs.
The CLR provides a virtual machine that fits many languages needs for an
execution run-time. This removes all kinds of problems with
calling-conventions, struct-layout, and numerous c++ ABI problems. It is
possible to share code across languages, and c++-compilers in CLR.
That's the "end-all" part.
That you can now share much more code open up new problems, as you
observe, but they are definatly "better" problems than writing all the
code you use from .NET yourself
If you apply a "fix" to your development boxes, you can be damned sure that
99.9% of your external users will NOT have this "fix" installed. That makes
the .Net runtimes incompatible. Now we're right back where we were with DLL
Hell - except it's "fixes" missing instead of overwritten files.
There is no other way, if you want to share code; it's for better and
worse, in sickness and health. The good part is, it's not 'til death do
you part, you can ask the client to fix his .NET (may be hard enough,
esp. if they got a sysadmin -- whoose job it is to do these things
.
The other good news is, that you can ship your own .NET dll with the fix
if you need, and DLL-hell isn't there, you can actually have two DLL's
with different names opened in .NET, and *use* them with minimal effort.
(have you tried dynamic-loading under WIN32?)
.Net has not and cannot deliver the experience Microsoft has promised
without automatic updates (including fixes) to all .Net-capable desktops.
Well, autoupdates are evil, you know what you have, and if it doesn't
*need* fixing, don't apply the fix, simple rule of keeping things alive.
You know the old bugs, the new ones are the ones that hurts.
And (joy of joys), if a customer installs a "fix" for another vendor's
application, it may cause unintended consequences in your .Net application.
And, again - you are screwed. Like it or not,
That's what sharing code does. Often, it doesn't cause too much trouble,
but sometimes (and those are frustrating times, I'll admit that) you
(often implicitly) depended on buggy behaviour that meant that your code
didn't exhibit it's own bugs.
Thinstall app are immune
from this "fix" issue.
If I read the docs correctly, it does this exactly by packaging the
transitive closure of the code (and registry information) of the
developer-machine and run that in a virtual machine. This sounds like a
nice solution when you have enough problems with different versions of
things: You get exactly the bugs that the developer-machine have,
nothing more, nothing less -- of course including the bugs in thinstall,
but you can try those out before you ship.
In the days gone by, this was static linking, which was really not an
option back then -- storage-space was expensive.
Strong-naming in .NET provides for some of the benefis and drawbacks of
static-linkage, but also (largely) prevents fix-after-ship with small
amounts of data and is a pain to use.
Don't throw FUD at me just because you are unfamiliar with the tool that you
are placing your company's future on.
Well, I guess the amount of problems people have with .NET differs
greatly. I got some nags about C#, found a few leaks and bugs in the
libs, but I worked them out.
The important thing for me is that the bugs that i've seen are a *lot*
easier to find than back in the c++ days (/me thinks back to the month
spent debugging untill it was discovered that std::string::string(const
std::string&) wasn't thread-safe).
