473,289 Members | 1,917 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,289 software developers and data experts.

1,596 problems in .Net 1.1

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
14 2263

"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

"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

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

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

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

"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
"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 thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

0
by: Jerome Lefebvre | last post by:
Hello, Hope this will interest a few. I been working with a friend on the problems given out during the "International Collegiate Programming Contest" (ICPC) http://icpc.baylor.edu/icpc/ ....
1
by: 3f | last post by:
Hello; We have made a web application that people can download from our web site and installed on: Windows XP Windows 2000 Professional Windows 2003 Server Windows 2000 Server
5
by: Corky | last post by:
This works: db2 SELECT DISTINCT PROBLEM_OBJECTS.PROBLEM_ID FROM PROBLEM_OBJECTS INNER JOIN PROBLEMS ON PROBLEM_OBJECTS.PROBLEM_ID = PROBLEMS.PROBLEM_ID WHERE INTEGER(DAYS(CURRENT DATE) -...
2
by: Ellen Graves | last post by:
I am having a lot of problems with DB2 8.3.1 on RH Linux AS2.1. Installing and running stored procedures is problematic. Stored procedures I have used for years on V7 on WinNT are now failing...
19
by: Jim | last post by:
I have spent the past few weeks designing a database for my company. The problem is I have started running into what I believe are stack overflow problems. There are two tab controls on the form...
10
by: BBFrost | last post by:
We just recently moved one of our major c# apps from VS Net 2002 to VS Net 2003. At first things were looking ok, now problems are starting to appear. So far ... (1) ...
19
by: Dales | last post by:
I have a custom control that builds what we refer to as "Formlets" around some content in a page. These are basically content "wrapper" sections that are tables that have a colored header and...
2
by: Brian | last post by:
NOTE ALSO POSTED IN microsoft.public.dotnet.framework.aspnet.buildingcontrols I have solved most of my Server Control Collection property issues. I wrote an HTML page that describes all of the...
0
by: Sergistm | last post by:
Hello World, :D I have a problem that it is making me crazy, I hope you can help me. I'm trying to execute a .exe file with the Procces.Start, and there is no problem when the file is on my...
2
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 7 Feb 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:30 (7.30PM). In this month's session, the creator of the excellent VBE...
0
by: MeoLessi9 | last post by:
I have VirtualBox installed on Windows 11 and now I would like to install Kali on a virtual machine. However, on the official website, I see two options: "Installer images" and "Virtual machines"....
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.