Re: 1,596 problems in .Net 1.1

Tech-Archive recommends: Fix windows errors by optimizing your registry

From: Jim Hubbard (reply_at_groups.please)
Date: 03/20/05 

Date: Sun, 20 Mar 2005 04:43:35 -0500

"Helge Jensen" <helge.jensen@slog.dk> wrote in message
news:OAYhcOSLFHA.1608@TK2MSFTNGP12.phx.gbl...
> Jim Hubbard wrote:
>
>>>FUD, regardless. Many of us are using the .NET Framework successfully
>>>despite your list.
>> 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.

I think it can be interpreted both ways. Good point.

>
>> 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.

Amen!

>
> 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).

Doesn't seem like it'd be hard to list the .Net needs in the assembly.
Here's hoping they will.

>
>> 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.

Mine too. But, when the IDE and framework is buggy and they are running on
a buggy OS, it concerns me. Especially since I subscribe to KBAlertz and
see a new "problem" almost every day. Honestly, it shakes my faith in the
framework.

>
> 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.

These are the things that VB developers (the camp I'm from originally) have
never worried about. So, these neat new things mean virtually nothing to
the 3,000,000+ classic VB users like myself.

>
> 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 :)

With the mountain of 3rd party controls available, code sharing also was not
an issue for classic VB users. It's just one more thing that we didn't ask
for, need or have any plans to use.

>
>> 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;

I never wanted to share code. But, I wrote and shared activeX controls.
Maybe that's the break I'm having with this whole .Net thing. It's an
answer to a problem I never had.

>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 :).

And, if your changes break another developer's stuff, they ask them to
change back and now you're back to being broken. The end user then has to
decide which app to throw out. Let's hope it's not yours.

>
> 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?)

But you can't (AFAIK) ship the actual .Net framework DLLs with your
application - without using something like Thinstall. If they have applied
a "fix" that patches core functionality of the .Net framework, and you coded
around the bug the "fix" fixed - your code will not run correctly on their
system.

You have always been able to ship your own DLLs with Win32 apps - just drop
them in the same directory as your EXE and use that directory as your
"working" directory. This actually ends "DLL Hell" without a need for a new
language.

>
>> .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.

True. But, having a slew of clients with disparate .Net frameworks will
also be no walk in the park.

>
> You know the old bugs, the new ones are the ones that hurts.

And its the "fix" that puts the new bugs in....

>
>> 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.

What is the big deal with "sharing code"? I am not getting it.

>
>> 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.

Good thing is that if it works when you ship it, it should work for all
supported OSs without altering their systems. And, their changes shouldn't
affect your aplication.

>
> 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.

Cool! It's nice when things work 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).

Hehehe.......even the lowly VB developers had those days. I don't think
we'll ever see the end of those weird time-sucking problems. But that's
just a part of programming.

In my mind, the thing that seems to frustrate me is that my favorite
language is being killed (VB 6) instead of fixed and extended. It has been
replaced by something that only has syntax in common with my trusted classic
VB.

I am told that it is because I can now have all of this new functionality
that I never desired, asked for and can see no reason to use. It's added
complexity, reduced the RAD development capabilities and hasn't provided an
adequate tool for upgrading VB6 apps to the new language.

My old language was great for RAD development of office applications (even
for web apps - if you bothered to learn about activeX documents and controls
that would run in IE).

For me, .Net is an answer to a problem that didn't exist. And, I have daily
reminders of the flaws in .Net that makes it just as buggy as my old
solution - if not more so.

Sharing code meant writing activeX controls or classes. Now, by simply
distributing your application you have essentially joined the open source
movement.

Progress....right.

Jim Hubbard