By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,686 Members | 2,770 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,686 IT Pros & Developers. It's quick & easy.

1,596 problems in .Net 1.1

P: n/a
Are you up to speed on the difficulties in using the 1.1 .Net framework?
Not if you are unaware of the 1,596 issues listed at KBAlertz
(http://www.kbalertz.com/technology_3.aspx).

If you are going to use .Net......I highly recommend signing up for the free
KBAlertz newsletter at http://www.kbalertz.com/default.aspx.

Looking at all of the errors and quirks sometimes makes me wonder if this
thing is really ready for prime time.

I still think Microsoft is using us as the world's largest beta test group
for it's own internal initiatives. But, that's just my paranoia shining
through........isn't it?

Jim Hubbard
Jul 21 '05 #1
Share this Question
Share on Google+
14 Replies


P: n/a

"Jim Hubbard" <re***@groups.please> wrote in message
news:0Y********************@giganews.com...
Are you up to speed on the difficulties in using the 1.1 .Net framework?
Not if you are unaware of the 1,596 issues listed at KBAlertz
(http://www.kbalertz.com/technology_3.aspx).


Ah. Selling Thinstall by means of FUD?

Jul 21 '05 #2

P: n/a

"Michael A. Covington" <lo**@ai.uga.edu.for.address> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

"Jim Hubbard" <re***@groups.please> wrote in message
news:0Y********************@giganews.com...
Are you up to speed on the difficulties in using the 1.1 .Net framework?
Not if you are unaware of the 1,596 issues listed at KBAlertz
(http://www.kbalertz.com/technology_3.aspx).


Ah. Selling Thinstall by means of FUD?


Nah Thinstall sells itself. Once you try it - you're hooked. And,
Thinstall is not .Net specific. It also works with Visual Basic and C++
applications. (I really need to learn C++.....know of any books for fast
learners? My attention span can't handle most dry, drawn out manuals.)

I am just surprised at the number of errors you run into while programming
..Net. It can be frustrating, and this site can help with that.

To be complete honest, I am not a fan of .Net. I liked classic VB. It was
easy, it was RAD, it was just what I (and 3,000,000+ other developers)
needed.

..Net removed the RAD from VB, added complexity that 98% of the classic VB
developers never asked for, didn't desire and will never use. For me,
VB.Net sucks.

..Net is the death of VB. I wish they had been honest enough to name VB.Net
something else.....like B#. It would be like C# - where the syntax is
similar to JAVA, but that's all that's similar.

If we hadn't been lead to believe that this .Net stuff was a continuation of
VB, there would be less of an uproar. Of course, there'd be fewer B#
developers, but there are fewer VB developers with the current approach - so
it wouldn't really matter.

I'm concerned that Microsoft has again rushed a product to market full of
holes. This product (.Net framework) in particular can produce problems
with much more than a simple desktop app. Screw-ups here affect company
bottom lines....and that affects the economy.

Sometimes its REALLY important to get things right the first time.

Jim Hubbard
Jul 21 '05 #3

P: n/a

"Jim Hubbard" <re***@groups.please> wrote in message
news:uJ********************@giganews.com...

Nah Thinstall sells itself. Once you try it - you're hooked. And,
Thinstall is not .Net specific. It also works with Visual Basic and C++
applications. (I really need to learn C++.....know of any books for fast
learners? My attention span can't handle most dry, drawn out manuals.)

I am just surprised at the number of errors you run into while programming
.Net. It can be frustrating, and this site can help with that.

To be complete honest, I am not a fan of .Net. I liked classic VB. It
was easy, it was RAD, it was just what I (and 3,000,000+ other
developers) needed.

.Net removed the RAD from VB, added complexity that 98% of the classic VB
developers never asked for, didn't desire and will never use. For me,
VB.Net sucks.

.Net is the death of VB. I wish they had been honest enough to name
VB.Net something else.....like B#. It would be like C# - where the syntax
is similar to JAVA, but that's all that's similar.

If we hadn't been lead to believe that this .Net stuff was a continuation
of VB, there would be less of an uproar. Of course, there'd be fewer B#
developers, but there are fewer VB developers with the current approach -
so it wouldn't really matter.

I'm concerned that Microsoft has again rushed a product to market full of
holes. This product (.Net framework) in particular can produce problems
with much more than a simple desktop app. Screw-ups here affect company
bottom lines....and that affects the economy.

Sometimes its REALLY important to get things right the first time.

Jim Hubbard


FUD, regardless. Many of us are using the .NET Framework successfully
despite your list.
Jul 21 '05 #4

P: n/a
FUD, regardless. Many of us are using the .NET Framework successfully
despite your list.


Correction: Microsoft's list.

Please note that all 1,500+ are listed in the Microsoft KB.

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.

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.

But, doing so would show that the .Net framework is no the end-all-be-all
solution that Microsoft said it was.

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.

..Net has not and cannot deliver the experience Microsoft has promised
without automatic updates (including fixes) to all .Net-capable desktops.

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, Thinstall app are immune
from this "fix" issue.

Don't throw FUD at me just because you are unfamiliar with the tool that you
are placing your company's future on.

Jim Hubbard
Jul 21 '05 #5

P: n/a
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.
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).

--
Helge Jensen
mailto:he**********@slog.dk
sip:he**********@slog.dk
-=> Sebastian cover-music: http://ungdomshus.nu <=-
Jul 21 '05 #6

P: n/a

"Helge Jensen" <he**********@slog.dk> wrote in message
news:OA**************@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
Jul 21 '05 #7

P: n/a
Funny, we've been using c# extensively since beta 1, and experienced no
problems. Mind you, we have writen our own stuff from primitives, such as
O/R mapper and dont used datasets etc, but we've got a full ERP system
hosted as Web Services with stateful user sessions. So far, so memory
leaks, no crashes, no hacks. Thats in over 4 years totals, and about 2
years live in production. If there are bugs, they are not in the core
functionality. Overall, .NET and the CLR are one of the best things MS has
ever done (although I do miss MI, and see no need for so many languages - c#
will do fine).

Radek

"Jim Hubbard" <re***@groups.please> wrote in message
news:0Y********************@giganews.com...
Are you up to speed on the difficulties in using the 1.1 .Net framework?
Not if you are unaware of the 1,596 issues listed at KBAlertz
(http://www.kbalertz.com/technology_3.aspx).

If you are going to use .Net......I highly recommend signing up for the free KBAlertz newsletter at http://www.kbalertz.com/default.aspx.

Looking at all of the errors and quirks sometimes makes me wonder if this
thing is really ready for prime time.

I still think Microsoft is using us as the world's largest beta test group
for it's own internal initiatives. But, that's just my paranoia shining
through........isn't it?

Jim Hubbard

Jul 21 '05 #8

P: n/a
"Jim Hubbard" wrote:
Are you up to speed on the difficulties in using the 1.1 .Net framework?
Not if you are unaware of the 1,596 issues listed at KBAlertz
(http://www.kbalertz.com/technology_3.aspx).
Yea, im sure all 1500+ issues affect typical day-to-day development. We've
been doing large, complex apps with .NET since beta and I can think of maybe
3 or 4 times a KB item has applied.
If you are going to use .Net......I highly recommend signing up for the free
KBAlertz newsletter at http://www.kbalertz.com/default.aspx.

Looking at all of the errors and quirks sometimes makes me wonder if this
thing is really ready for prime time.
Are you aware that there are even more KB items for your favorite tool VB6?
And VC++ 6.0 has almost twice as many as .NET? So in your professional
opinion VB6 and VC++ 6.0 may not be ready for primetime. Thanks for the tip.
I still think Microsoft is using us as the world's largest beta test group
for it's own internal initiatives. But, that's just my paranoia shining
through........isn't it?

Jim Hubbard


If this is the typical of the logic and reasoning skills you use in your
daily job, its no wonder that you are having difficulties adjusting to .NET
development, which really isnt difficult at all as long as you stop wasting
brainpower on constantly crying "but it didnt work like this in VB6 or ASP!"
Jul 21 '05 #9

P: n/a

"Jim Hubbard" <re***@groups.please> wrote in message
news:mr********************@giganews.com...

Correction: Microsoft's list.

Please note that all 1,500+ are listed in the Microsoft KB.

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.

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.

But, doing so would show that the .Net framework is no the end-all-be-all
solution that Microsoft said it was.

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.

.Net has not and cannot deliver the experience Microsoft has promised
without automatic updates (including fixes) to all .Net-capable desktops.

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, Thinstall app
are immune from this "fix" issue.

Don't throw FUD at me just because you are unfamiliar with the tool that
you are placing your company's future on.

Jim Hubbard

Maybe you're just having trouble adapting to change. Every major development
tool has long lists of open "bugs", including the now *very* mature VS 6.
Microsoft, unlike some competing vendors, chooses to make the issues public
so we *are* aware of potential problems. Try getting a list of open "bugs"
from Oracle.
It appears to be you who wants to apply the "chicken little" spin to the
situation.
Jul 21 '05 #10

P: n/a
"Peter van der Goes" <p_**********@toadstool.u> wrote in message
news:u4**************@TK2MSFTNGP09.phx.gbl...
Maybe you're just having trouble adapting to change. Every major
development tool has long lists of open "bugs", including the now *very*
mature VS 6. Microsoft, unlike some competing vendors, chooses to make the
issues public so we *are* aware of potential problems. Try getting a list
of open "bugs" from Oracle.


Well said. Does nobody remember what IBM mainframe operating systems were
like in the 1970s? I think the last version of OS/360 was v. 21 G.

Some manufacturers reveal the issues and release frequent patches. Other
manufacturers keep quiet about them and never fix them. Which is better?
Jul 21 '05 #11

P: n/a
Funny, we've been using c# extensively since beta 1, and experienced no
problems. Mind you, we have writen our own stuff from primitives, such as
O/R mapper and dont used datasets etc, but we've got a full ERP system
hosted as Web Services with stateful user sessions. So far, so memory
leaks, no crashes, no hacks. Thats in over 4 years totals, and about 2
years live in production. If there are bugs, they are not in the core
functionality. Overall, .NET and the CLR are one of the best things MS has
ever done (although I do miss MI, and see no need for so many languages - c#
will do fine).

Radek

"Jim Hubbard" <re***@groups.please> wrote in message
news:0Y********************@giganews.com...
Are you up to speed on the difficulties in using the 1.1 .Net framework?
Not if you are unaware of the 1,596 issues listed at KBAlertz
(http://www.kbalertz.com/technology_3.aspx).

If you are going to use .Net......I highly recommend signing up for the free KBAlertz newsletter at http://www.kbalertz.com/default.aspx.

Looking at all of the errors and quirks sometimes makes me wonder if this
thing is really ready for prime time.

I still think Microsoft is using us as the world's largest beta test group
for it's own internal initiatives. But, that's just my paranoia shining
through........isn't it?

Jim Hubbard

Nov 22 '05 #12

P: n/a
"Jim Hubbard" wrote:
Are you up to speed on the difficulties in using the 1.1 .Net framework?
Not if you are unaware of the 1,596 issues listed at KBAlertz
(http://www.kbalertz.com/technology_3.aspx).
Yea, im sure all 1500+ issues affect typical day-to-day development. We've
been doing large, complex apps with .NET since beta and I can think of maybe
3 or 4 times a KB item has applied.
If you are going to use .Net......I highly recommend signing up for the free
KBAlertz newsletter at http://www.kbalertz.com/default.aspx.

Looking at all of the errors and quirks sometimes makes me wonder if this
thing is really ready for prime time.
Are you aware that there are even more KB items for your favorite tool VB6?
And VC++ 6.0 has almost twice as many as .NET? So in your professional
opinion VB6 and VC++ 6.0 may not be ready for primetime. Thanks for the tip.
I still think Microsoft is using us as the world's largest beta test group
for it's own internal initiatives. But, that's just my paranoia shining
through........isn't it?

Jim Hubbard


If this is the typical of the logic and reasoning skills you use in your
daily job, its no wonder that you are having difficulties adjusting to .NET
development, which really isnt difficult at all as long as you stop wasting
brainpower on constantly crying "but it didnt work like this in VB6 or ASP!"
Nov 22 '05 #13

P: n/a

"Jim Hubbard" <re***@groups.please> wrote in message
news:mr********************@giganews.com...

Correction: Microsoft's list.

Please note that all 1,500+ are listed in the Microsoft KB.

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.

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.

But, doing so would show that the .Net framework is no the end-all-be-all
solution that Microsoft said it was.

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.

.Net has not and cannot deliver the experience Microsoft has promised
without automatic updates (including fixes) to all .Net-capable desktops.

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, Thinstall app
are immune from this "fix" issue.

Don't throw FUD at me just because you are unfamiliar with the tool that
you are placing your company's future on.

Jim Hubbard

Maybe you're just having trouble adapting to change. Every major development
tool has long lists of open "bugs", including the now *very* mature VS 6.
Microsoft, unlike some competing vendors, chooses to make the issues public
so we *are* aware of potential problems. Try getting a list of open "bugs"
from Oracle.
It appears to be you who wants to apply the "chicken little" spin to the
situation.
Nov 22 '05 #14

P: n/a
"Peter van der Goes" <p_**********@toadstool.u> wrote in message
news:u4**************@TK2MSFTNGP09.phx.gbl...
Maybe you're just having trouble adapting to change. Every major
development tool has long lists of open "bugs", including the now *very*
mature VS 6. Microsoft, unlike some competing vendors, chooses to make the
issues public so we *are* aware of potential problems. Try getting a list
of open "bugs" from Oracle.


Well said. Does nobody remember what IBM mainframe operating systems were
like in the 1970s? I think the last version of OS/360 was v. 21 G.

Some manufacturers reveal the issues and release frequent patches. Other
manufacturers keep quiet about them and never fix them. Which is better?
Nov 22 '05 #15

This discussion thread is closed

Replies have been disabled for this discussion.