Microsoft Discouraging .Net use?

  • Thread starter Thread starter Jim Hubbard
  • Start date Start date
J

Jim Hubbard

Yet another hotfix alert (http://www.kbalertz.com/Feedback_823535.aspx) that
states "To resolve this problem immediately, contact Microsoft Product
Support Services to obtain the hotfix."

Whatever happened to automatic updates? Doesn't Microsoft know that
developers are busy people.....too busy to be stopped by this type of crap
every time Microsoft is alerted to something they missed in the software by
another developer (note: Microsoft rarely finds their own mistakes) ?

If it is a question of stopping unauthorized use of pirated .Net versions,
just have the upgrade functionality pass in the license info when it
requests a patch. Info no good? Then, no patch.

Get with the program Microsoft! You're supposed to make things easier, not
waste our time waiting on the phone for your off-shore "help".

When freeware routinely updates itself without user intervention, and for a
company that pushes things like webservices, this is really pathetic.

Jim Hubbard
 
Jim said:
Yet another hotfix alert (http://www.kbalertz.com/Feedback_823535.aspx) that
states "To resolve this problem immediately, contact Microsoft Product
Support Services to obtain the hotfix."

I've seen this before in other areas, like SQL server hotpatches.

In effect, they are saying that it's not totally QC'd and tested widely,
and it addresses specific needs -- but, if it's important to *you*, we
will make it available.
 
Moe Green said:
I've seen this before in other areas, like SQL server hotpatches.

In effect, they are saying that it's not totally QC'd and tested widely,
and it addresses specific needs -- but, if it's important to *you*, we
will make it available.

While I understand what you are saying, I say if it's broken it's important
to all developers - so let us get the danged hotfixes automatically.

If you look at the .Net hotfixes on KB Alrtz
(http://www.kbalertz.com/sresults.aspx?sw=Net+Framework&st=2&stec=3&pNo=1)
that deal specifically with .Net Framework 1.1 issues, you will see that
there are a LOT of them.

Do you need all of these fixes today or for your current project? Probably
not. But, how would you know - unless you subscribe to KB Alertz and call
Microsoft several times a week to keep your system up to date.

And what about all of the "FIXES" you haven't called Microsoft for? Making
customers wait until something that is supposed to work fails, and then
hoping they will find the proper Microsoft release and CALL Microsoft for a
patch is NOT the way to run a serious business.

When you are the largest provider of programming software, does that mean
that you have a right to treat your customers like they don't really matter?

We all know Microsoft is not a monopoly (in the strictest sense of the
word), but they sure act like it when it comes to customer service.

Automatic updates are very important to what few fixes will be released
after version 2.0 is released. Microsoft, like most companies, will focus
its efforts and resources on the newest version of the framework - leaving
those calling for a 1.1 "fix" on the line even longer.

And, what programmer knows what s/he will be called on next week to code?
Therefore, it is a requirement of the job to have a coding system (including
the programming software) that is ready to assist you in handling any coding
job that is placed on your plate. Only self-updating software can give you
that.

I sincerely hope that this is not an indication of the level of commitment
that Microsoft is placing on the .Net platform. Hopefully they will not be
as lax with version 2.0. But, then again........where's any indication that
the current level of commitment(?) will not continue or (God forbid) worsen?

Jim Hubbard
 
Jim Hubbard said:
While I understand what you are saying, I say if it's broken it's
important to all developers - so let us get the danged hotfixes
automatically.

So, Jim, you want to automatically get these fixes before they're fully
tested, or afterwards?

John Saunders
 
Some of these fixes for VS.NET 2003 are more than one year old and for
VS.NET 2002, it's more than two years. With these kind of delays, I don't
think it's only a question of taking sufficient time for testing.

Also, if some of these fixes were relevant about the .NET Framework itself
and may have been corrected with the SP1 for the .NET Framework; many other
are clearly affecting only the Visual Studio itself, are around for more
than 6 months, 1 year or even 2 years and have never been included into some
sort of service pack or being publicly available for downloading somewhere
or even simply to be grouped into an easy to consult information page. Not
only they are not easy to get but they are also very hard to find and even
harder to be analysed and evaluated.

S. L.
 
What he said....

Jim Hubbard

Sylvain Lafontaine said:
Some of these fixes for VS.NET 2003 are more than one year old and for
VS.NET 2002, it's more than two years. With these kind of delays, I don't
think it's only a question of taking sufficient time for testing.

Also, if some of these fixes were relevant about the .NET Framework itself
and may have been corrected with the SP1 for the .NET Framework; many
other are clearly affecting only the Visual Studio itself, are around for
more than 6 months, 1 year or even 2 years and have never been included
into some sort of service pack or being publicly available for downloading
somewhere or even simply to be grouped into an easy to consult information
page. Not only they are not easy to get but they are also very hard to
find and even harder to be analysed and evaluated.

S. L.
 
Jim Hubbard said:
What he said....

Ok, but you were talking about automatic distribution, and didn't answer my
question. There's got to be some (tested) package to be automatically
distributed.

BTW, passage of time does not imply that the fix has been tested - as a
service pack. The fact that the individual hotfixes may have been tested
does not in any way imply that they will work if packaged together with
other fixes. Also, a service pack will get testing on multiple OS versions
and in many different situations. It's a lot more testing than just testing
an individual fix.

John Saunders
 
Microsoft writes all of the operating systems you mention. Microsoft writes
the coding tools we are talking about. Microsoft writes the "hotfixes".

Shouldn't Microsoft know what the "hotfixes" will affect? If you have all
of the source code, isn't it incumbent on YOU to do the testing of your
latest patches?

That has always been the case in every software shop I have worked in. We
wrote the code. We made the mistakes. We cleaned them up.

With $50 BILLION in cash reserves and investing over $400M in Indian
programmers at once.....don't you think Microsoft should know it's own
code.....or at least be able to test it's own software?

Microsoft cannot, obviously, guarantee the hotfixes to work with all 3rd
party software. But, they don't have to.....they just need to make sure
that hotfixes don't break their codebase and alert the programmers to the
affected modules so the programmers can change their code if needed.

And, yes.....I do think that programmers paying $2500 for a year's
subscription are entitled to tested hotfixes.

Jim Hubbard
 
Jim Hubbard said:
Microsoft writes all of the operating systems you mention. Microsoft
writes the coding tools we are talking about. Microsoft writes the
"hotfixes".

Shouldn't Microsoft know what the "hotfixes" will affect? If you have all
of the source code, isn't it incumbent on YOU to do the testing of your
latest patches?

Yes. That's the testing they do on a service pack. The testing that they
don't do on a hot fix.
That has always been the case in every software shop I have worked in. We
wrote the code. We made the mistakes. We cleaned them up.

With $50 BILLION in cash reserves and investing over $400M in Indian
programmers at once.....don't you think Microsoft should know it's own
code.....or at least be able to test it's own software?

No, I don't.

Besides, they not only have to know their own code, they have to know all
the crazy things their customers will do with their code. And Microsoft has
a rather large number of customers doing crazy things.
Microsoft cannot, obviously, guarantee the hotfixes to work with all 3rd
party software. But, they don't have to.....they just need to make sure
that hotfixes don't break their codebase and alert the programmers to the
affected modules so the programmers can change their code if needed.

Few of the hotfixes break existing code (except to the extent that the code
may depend on the bug being fixed).

This will absolutely guarantee that the hotfixes will cause random problems
on random customers' systems, because they were not all tested together, and
weren't tested in that customer's configuration, and because the customer
didn't get a chance to go through a proper test cycle.
And, yes.....I do think that programmers paying $2500 for a year's
subscription are entitled to tested hotfixes.

Again, Jim, it is my understanding that the hot fixes _are_ tested. They are
tested individually, not in all permutations. A Service Pack takes a number
of hot fixes and puts them together in a single package which can be
thoroughly tested. The fixes in a Service Pack can be tested as a group, and
can be tested in many different environments, and can then be released to
customers for Beta testing. How long was the Beta period of XP SP2?

John Saunders
 
John Saunders said:
No, I don't.

Why not?

Besides, they not only have to know their own code, they have to know all
the crazy things their customers will do with their code. And Microsoft
has a rather large number of customers doing crazy things.


Few of the hotfixes break existing code (except to the extent that the
code may depend on the bug being fixed).

This will absolutely guarantee that the hotfixes will cause random
problems on random customers' systems, because they were not all tested
together, and weren't tested in that customer's configuration, and because
the customer didn't get a chance to go through a proper test cycle.


Again, Jim, it is my understanding that the hot fixes _are_ tested. They
are tested individually, not in all permutations. A Service Pack takes a
number of hot fixes and puts them together in a single package which can
be thoroughly tested. The fixes in a Service Pack can be tested as a
group, and can be tested in many different environments, and can then be
released to customers for Beta testing. How long was the Beta period of XP
SP2?

The very nature of the .Net framework invalidates your arguments for
Microsoft's failure to test.

According to Microsoft, many different versions of .Net (both the framework
and code) should be able to reside on a single machine and run side-by-side.

So, what's to stop Microsoft from making a change to the version of the .Net
framework with each hotfix? Are they going to run out of numbers? If so, I
have some numbers I can let them borrrow. (For a monthly fee, of course.)

The whole idea behind the .Net framework was to allow different versions of
the framework and code to run side-by-side. Since I have only been
addressing the .Net framework in my posts, I fail to see any validity in
your arguments.

Please let me know if I misunderstand the nature of .Net or there are
reasons for not issuing incrementing versions of .Net with each hotfix.

Jim Hubbard
 
Jim said:
Microsoft writes all of the operating systems you mention. Microsoft
writes
the coding tools we are talking about. Microsoft writes the "hotfixes".

Situation:

A problem happens.

A young intern, goes and writes a hotfix to address the problem.

He hands it to his boss, then leaves to go party in Daytona.

This is one hotfix, among 10,000 others.

It only affects version n.nn.nn, and has only been tested with computer y in
configuration z.

If a customer should call having that problem, it's made available.

Otherwise, there's no idea of the implications the fix might cause for other
configurations, and there's not enough resources to test it.

Shouldn't Microsoft know what the "hotfixes" will affect? If you have all
of the source code, isn't it incumbent on YOU to do the testing of your
latest patches?

That has always been the case in every software shop I have worked in. We
wrote the code. We made the mistakes. We cleaned them up.

With $50 BILLION in cash reserves and investing over $400M in Indian
programmers at once.....don't you think Microsoft should know it's own
code.....or at least be able to test it's own software?

Microsoft cannot, obviously, guarantee the hotfixes to work with all 3rd
party software. But, they don't have to.....they just need to make sure
that hotfixes don't break their codebase and alert the programmers to the
affected modules so the programmers can change their code if needed.

And, yes.....I do think that programmers paying $2500 for a year's
subscription are entitled to tested hotfixes.

Jim Hubbard

--
"The Bush administration aims in its 2005 budget to cut by $1 billion the
$18 billion fund that helps about 2 million Americans--generally the poor,
elderly, and disabled--pay their rent."
-Mother Jones
http://www.motherjones.com/news/dailymojo/2004/05/05_520.html
 
Jim Hubbard said:

Because there's too much of it to go test for every hotfix.
The very nature of the .Net framework invalidates your arguments for
Microsoft's failure to test.

According to Microsoft, many different versions of .Net (both the
framework and code) should be able to reside on a single machine and run
side-by-side.

So, what's to stop Microsoft from making a change to the version of the
.Net framework with each hotfix? Are they going to run out of numbers?
If so, I have some numbers I can let them borrrow. (For a monthly fee, of
course.)

The whole idea behind the .Net framework was to allow different versions
of the framework and code to run side-by-side. Since I have only been
addressing the .Net framework in my posts, I fail to see any validity in
your arguments.

Please let me know if I misunderstand the nature of .Net or there are
reasons for not issuing incrementing versions of .Net with each hotfix.

You haven't caught my point.

A great amount of testing is necessary before you release a fix to a
customer for use in a production environment. That testing takes too long to
do it for each hotfix. Instead, hotfixes are grouped together to create a
Service Pack, which is tested appropriately.

Jim, are you thinking about a production environment, or a development
environment?

John Saunders
 
John Saunders said:
Because there's too much of it to go test for every hotfix.

Maybe it's time to start cutting out the fat. When you can't fix one part
of your code because it may break another part, that's just poor design.
And, in a company the size and importance of Microsoft to daily business,
it's dangerous and borders on crimminal misconduct by a corporation.
You haven't caught my point.

A great amount of testing is necessary before you release a fix to a
customer for use in a production environment. That testing takes too long
to do it for each hotfix. Instead, hotfixes are grouped together to create
a Service Pack, which is tested appropriately.

I agree with these points. The fact is that Microsoft is not doing what you
are suggesting. There are hotfixes for the .Net framework (1.1) that have
been available for months but have not been placed into any released service
packs. I can list some of them if you like.
Jim, are you thinking about a production environment, or a development
environment?

Production. Programmers don't pay $2500 for beta code. I expect it to
work. I expect problems in the framework to be fxed. And I expect the fix
to actually fix things....not break new stuff. That's what Microsoft should
test for. That *is* what I paid for isn't it? Is expecting working code in
exchange for some of the highest software prices in the industry so
unreasonable?

It seems that you glossed over entirely the easy solution to this problem.
When Microsoft fixes the framework, simply increase the version number of
the framework and release the newest version! Is that so hard to
comprehend? Isn't that one main goal of the .Net framework....to be able to
run several different versions on the same machine WITHOUT corrupting each
other?

Let's imagine for a moment that Microsoft used their own technology as they
said it was designed to work and issued new versions of .Net with each new
service pack (or even hotfix). Let's also say they screw up something new
with the latest service pack or hotfix. According to them, this would not
break or interfere with the old code you had written in a previous version
of the framework. So where's the harm?

If it screws up your code, either change your code or drop back and punt
from the previous version of .Net that didn't screw up your code.

This isn't that difficult to understand. I'm not talking over anybody's
head here. They just don't want to do it.

Hell, short of that you *could* make the hotfixes save their changes so that
you could apply them one at a time, test your code and roll back any
hotfixes that screwed up your programs. Microsoft doesn't even do that.

The sad but obvious fact is that they don't care about making your life
easier, it's all about making their lives easier. That was the original
premise of .Net in the first place. If not, they'd use the technology they
built to enhance it's effectiveness instead of hobbling it.

Jim Hubbard
 
Jim Hubbard said:
Maybe it's time to start cutting out the fat. When you can't fix one part
of your code because it may break another part, that's just poor design.
And, in a company the size and importance of Microsoft to daily business,
it's dangerous and borders on crimminal misconduct by a corporation.


I agree with these points. The fact is that Microsoft is not doing what
you are suggesting. There are hotfixes for the .Net framework (1.1) that
have been available for months but have not been placed into any released
service packs. I can list some of them if you like.

I don't see what that has to do with my point. They happen not to have
scheduled a service pack. This could be due to lack of QA resources. For
instance, if they were working on a major new release, then some of the
resources which would have been used to test service packs might instead be
working on testing the new release. BTW, I'm sure you're aware that they are
working on both SQL Server 2005 and VS.NET 2005 and Framework 2.0?
Production. Programmers don't pay $2500 for beta code. I expect it to
work. I expect problems in the framework to be fxed. And I expect the
fix to actually fix things....not break new stuff. That's what Microsoft
should test for. That *is* what I paid for isn't it? Is expecting
working code in exchange for some of the highest software prices in the
industry so unreasonable?

Actually, some programmers pay $2700 anually for an MSDN Universal
subscription, and that's what I thought you might have meant.

If you expect humans to produce perfection, make sure you don't accidentally
pinch yourself and wake up.
It seems that you glossed over entirely the easy solution to this problem.
When Microsoft fixes the framework, simply increase the version number of
the framework and release the newest version! Is that so hard to
comprehend? Isn't that one main goal of the .Net framework....to be able
to run several different versions on the same machine WITHOUT corrupting
each other?

Versioning isn't the issue. The quality of releases is the issue.

You also seem to be assuming that fixes are sequential, and that each hotfix
can be associated with a single version number.
Let's imagine for a moment that Microsoft used their own technology as
they said it was designed to work and issued new versions of .Net with
each new service pack (or even hotfix). Let's also say they screw up
something new with the latest service pack or hotfix. According to them,
this would not break or interfere with the old code you had written in a
previous version of the framework. So where's the harm?

If it screws up your code, either change your code or drop back and punt
from the previous version of .Net that didn't screw up your code.

How often do you plan to do this? And how much do you plan to test your code
for each new hotfix?
This isn't that difficult to understand. I'm not talking over anybody's
head here. They just don't want to do it.

No, you just don't seem to be too clear on how a production operation works.
The very idea of having so many versions around on a set of production
machines scares the hell out of me.

John Saunders
 
Section 8 said:
Situation:

A problem happens.

A young intern, goes and writes a hotfix to address the problem.

He hands it to his boss, then leaves to go party in Daytona.

This is one hotfix, among 10,000 others.

It only affects version n.nn.nn, and has only been tested with computer y
in
configuration z.

If a customer should call having that problem, it's made available.

Otherwise, there's no idea of the implications the fix might cause for
other
configurations, and there's not enough resources to test it.

You also choose to ignore the ability to run multiple versions of the
framework side-by-side.

There is no excuse for not alerting developers to hotfixes as they become
available and allowing developers to download and test patches without a
*ing phone call to Microsoft......other than just not giving a damn.

Should I also rehash the ability to roll-back patches that Microsoft also
ignores in many cases?

Jim Hubbard

"The Bush administration aims in its 2005 budget to cut by $1 billion the
$18 billion fund that helps about 2 million Americans--generally the poor,
elderly, and disabled--pay their rent."
-Mother Jones
http://www.motherjones.com/news/dailymojo/2004/05/05_520.html

Expand your horizons....read a little more current "news" -
http://harkin.senate.gov/news.cfm?id=225889.

And, in the interest of full disclosure, you *should* mention that the
webmaster of this liberal website (masquerading as a journalism site) is on
the payroll of MoveOn.org. Not exactly an impartial view of the subject.
 
You also choose to ignore the ability to run multiple versions of the
framework side-by-side.

There is no excuse for not alerting developers to hotfixes as they become
available and allowing developers to download and test patches without a
*ing phone call to Microsoft......other than just not giving a damn.

Should I also rehash the ability to roll-back patches that Microsoft also
ignores in many cases?

Jim Hubbard

I agree on this one. There should, at the very least, exist some kind of
hotfix mailing list that you could subscribe to.
/ Fredrik
 
Fredrik Wahlgren said:
I agree on this one. There should, at the very least, exist some kind of
hotfix mailing list that you could subscribe to.
/ Fredrik

Subscribe to KBAlertz.....it's free. http://www.kbalertz.com/

Dave Wanta and Scott Cate are the responsible parties for the website.
THANKS GUYS!

Again, KBAlertz is something Microsoft should have done. You *should* warn
your subscribed users when you find a problem, shouldn't you? Maybe
Microsoft could do the right thing and buy it from them.

Be forewarned......Microsoft issues a LOT more warnings than you might
expect so be choosy about which technologies you pick.

Jim Hubbard
 
Jim Hubbard said:
Subscribe to KBAlertz.....it's free. http://www.kbalertz.com/

Dave Wanta and Scott Cate are the responsible parties for the website.
THANKS GUYS!

Again, KBAlertz is something Microsoft should have done. You *should* warn
your subscribed users when you find a problem, shouldn't you? Maybe
Microsoft could do the right thing and buy it from them.

Be forewarned......Microsoft issues a LOT more warnings than you might
expect so be choosy about which technologies you pick.

Jim Hubbard

Well, I haven't. Is there any way I can get hotfix alerts for say, SQL
Server only. If not, like you said, I will get lots of emails. That's why I
haven't subscribed.

/ Fredrik
 
Also, it's not all hotfixes that got annonced into the knownledge base
article. Others are available but will be found only after a direct
discussion with the technical support on a paid call while others are simply
put into some *limbo* cybernetic space.

S. L.
 
Fredrik Wahlgren said:
Well, I haven't. Is there any way I can get hotfix alerts for say, SQL
Server only. If not, like you said, I will get lots of emails. That's why
I
haven't subscribed.

/ Fredrik

Yes. Simply select only the SQL Server 2000 and SQL Server 7.0 checkboxes.
Then you'll only get Knowledge Base alerts for those Microsoft Technologies.

You only get what you check. No spam.

And, it's easy to unsubscribe if it's not all that you thought it would be.

Jim Hubbard
 
Back
Top