Microsoft Discouraging .Net use?

[Jim Hubbard]

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.

That's scary. With all of the hotfixes announced in the knowledge base, I
wonder how many we are missing out on because they don't get announced
there?

Jim Hubbard

 

[Jim Hubbard]

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?


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.

Wow.....no need to continue this thread......

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.

Not neccesarily. Why not have the avilable hotfixes load like Windows
security updates with a roll-back feature in case it screws something up?

How often do you plan to do this? And how much do you plan to test your
code for each new hotfix?

Not often. Mainly in between builds. No programmer in his right mind would
update the production or development machines while still coding the
application.

Testing is mostly automated. We're talking the .Net framework here. A
bunch of pre-compiled classes that you use in your code and a JIT compiler
to make it all come together. Either a class works with the implemented
interfaces or it doesn't. Either the JIT consumes the COM objects correctly
or it doesn't.

No, you just don't seem to be too clear on how a production operation
works.

Sadly, I am all too aware of how common production operations work. That's
why I don't code for people like Bellsouth, Porsche, Qwest etc, anymore and
started my own company. They are so frigid in their thought processes
concerning development that precious little actual work gets done.

The shops that get the least amount of work done seem to be those blindly
following the Microsoft SDLC. If it doesn't work for Microsoft.....why in
hell would you put your company on it?

The very idea of having so many versions around on a set of production
machines scares the hell out of me.

But, it shouldn't. That's how .Net was written to work. They all use thier
own framework (whatever version they were coded with) and, according to
Microsoft, they will not step on each other's toes.

Jim Hubbard

 

[Gerry Hickman]

The whole idea behind the .Net framework was to allow different versions of
the framework and code to run side-by-side.

You'll be lucky. It's DLL hell all over again. This is why internet Java was
such a disaster. I remember the banks using it and then spending all day
trying to troubleshoot end-users broken and disparate JVMs.

..NET is just as bad. "Which version of .NET are my 200,000 customers using",
"oops it won't work on that one". "Oh you've got XP gold", "You need
Longhorn for that one", "You're on Win98SE". That's before you even get to
service packs on hotfixes on the client's machine.

The whole thing is a mess, and can only get worse with Longhorn. They claim
Longhorn will embrace .NET, but so far we have no credible DirectShow
assemblies, and even if we did they'll fall way short of the capabilities of
COM. Do they have an LSA in managed code yet? What about the LDAP API? Where
is WinFS? Where are the native UNIX and Fibre SAN connectors?

All we've seen so far is the step backwards known as "Avalon" where current
W3C UI markup will be replaced by proprietary "Windows Only" code, and how
exactly will this help the Enterprise? "View your sales figures in a
rotating 3D DirectX cube", LOL!

Gerry Hickman
SSRU SysAdmin

 

[Jim Hubbard]

You'll be lucky. It's DLL hell all over again. This is why internet Java
was
such a disaster. I remember the banks using it and then spending all day
trying to troubleshoot end-users broken and disparate JVMs.

.NET is just as bad. "Which version of .NET are my 200,000 customers
using",
"oops it won't work on that one". "Oh you've got XP gold", "You need
Longhorn for that one", "You're on Win98SE". That's before you even get to
service packs on hotfixes on the client's machine.

Damned right! In another thread, I had asked the question "Why is .Net an
optional download?" If .Net is so important to the future of Microsoft
products, the .Net frameworks should be downloaded and installed
automatically along with security updates and such. It should be core to
the OS.

Even if one .Net framework is shipped with the OS, what about the next
version? These things have to be required (at least highly recommended)
updates to the OS.

Now, I know each .Net framework is a bloated, massive amount of code for
most people to download - so, the next question is why Microsoft didn't use
the technology built into .Net to make .Net exe's download only the portions
of .Net that they need to run, if those portions don't exist on the machine
the exe is being launched on? If a .Net application can tell it doesn't have
the DLLs required for a function and will request those downloads from the
server hosting the program's exe, why couldn't each exe contain similar code
for the .Net framework?

Beats the hell out of me.

The whole thing is a mess, and can only get worse with Longhorn. They
claim
Longhorn will embrace .NET, but so far we have no credible DirectShow
assemblies, and even if we did they'll fall way short of the capabilities
of
COM. Do they have an LSA in managed code yet? What about the LDAP API?
Where
is WinFS? Where are the native UNIX and Fibre SAN connectors?

I SO wish you weren't right......unfortunately, you are.

All we've seen so far is the step backwards known as "Avalon" where
current
W3C UI markup will be replaced by proprietary "Windows Only" code, and how
exactly will this help the Enterprise? "View your sales figures in a
rotating 3D DirectX cube", LOL!

And Microsoft rolls on......

We've conqured all of these problems by just sending out one EXE that wraps
all of the code (DLLs, EXEs, etc.) into a single executable that doesn't
need any installed .Net frameworks (if that is what we choose to code the
app in) or any dependencies apart from Windows itself.

If you use .Net for your apps, the EXE is still really big, but if you use
something like C++ or even VB 6 your resulting exe is much smaller.

Since we are wrapping everything, .Net really has no advantages other than
webservice ease of use. And, we get to continue using our old skillset and
thousands of dollars on third party controls without worrying about .Net COM
interop screwing it up. (The Dart/PowerTCP activeX controls will not work
with .Net 1.1 - Studio 2003 Architect.)

No control installations, no registry mess, no DLL hell, no .Net framework
hell. Just a larger exe and no worries.

Jim Hubbard

 

[Guest]

Jim, could you possibly tell me what you are using to wrap everything up in
one exe? If it is a commercial product (or free one) please let me know at:

john [at] fluidnature dot com? thanks so much (especially if its something i
can use!)
We've conqured all of these problems by just sending out one EXE that wraps
all of the code (DLLs, EXEs, etc.) into a single executable that doesn't
need any installed .Net frameworks (if that is what we choose to code the
app in) or any dependencies apart from Windows itself.

If you use .Net for your apps, the EXE is still really big, but if you use
something like C++ or even VB 6 your resulting exe is much smaller.

Since we are wrapping everything, .Net really has no advantages other than
webservice ease of use. And, we get to continue using our old skillset and
thousands of dollars on third party controls without worrying about .Net COM
interop screwing it up. (The Dart/PowerTCP activeX controls will not work
with .Net 1.1 - Studio 2003 Architect.)

No control installations, no registry mess, no DLL hell, no .Net framework
hell. Just a larger exe and no worries.

 

[Jim Hubbard]

Here's a link to Chris Sells' blog (that links to my blog) about the
program. It's called Thinstall, and it rocks!

Let me know if there is anything I can do to help.

Jim Hubbard

Jim, could you possibly tell me what you are using to wrap everything up
in
one exe? If it is a commercial product (or free one) please let me know
at:

john [at] fluidnature dot com? thanks so much (especially if its something
i
can use!)
We've conqured all of these problems by just sending out one EXE that
wraps
all of the code (DLLs, EXEs, etc.) into a single executable that doesn't
need any installed .Net frameworks (if that is what we choose to code the
app in) or any dependencies apart from Windows itself.

If you use .Net for your apps, the EXE is still really big, but if you use
something like C++ or even VB 6 your resulting exe is much smaller.

Since we are wrapping everything, .Net really has no advantages other than
webservice ease of use. And, we get to continue using our old skillset
and
thousands of dollars on third party controls without worrying about .Net
COM
interop screwing it up. (The Dart/PowerTCP activeX controls will not work
with .Net 1.1 - Studio 2003 Architect.)

No control installations, no registry mess, no DLL hell, no .Net framework
hell. Just a larger exe and no worries.

Damned right! In another thread, I had asked the question "Why is .Net
an
optional download?" If .Net is so important to the future of Microsoft
products, the .Net frameworks should be downloaded and installed
automatically along with security updates and such. It should be core to
the OS.

Even if one .Net framework is shipped with the OS, what about the next
version? These things have to be required (at least highly recommended)
updates to the OS.

Now, I know each .Net framework is a bloated, massive amount of code for
most people to download - so, the next question is why Microsoft didn't
use
the technology built into .Net to make .Net exe's download only the
portions
of .Net that they need to run, if those portions don't exist on the
machine
the exe is being launched on? If a .Net application can tell it doesn't
have
the DLLs required for a function and will request those downloads from
the
server hosting the program's exe, why couldn't each exe contain similar
code
for the .Net framework?

Beats the hell out of me.


I SO wish you weren't right......unfortunately, you are.


And Microsoft rolls on......

We've conqured all of these problems by just sending out one EXE that
wraps
all of the code (DLLs, EXEs, etc.) into a single executable that doesn't
need any installed .Net frameworks (if that is what we choose to code the
app in) or any dependencies apart from Windows itself.

If you use .Net for your apps, the EXE is still really big, but if you
use
something like C++ or even VB 6 your resulting exe is much smaller.

Since we are wrapping everything, .Net really has no advantages other
than
webservice ease of use. And, we get to continue using our old skillset
and
thousands of dollars on third party controls without worrying about .Net
COM
interop screwing it up. (The Dart/PowerTCP activeX controls will not
work
with .Net 1.1 - Studio 2003 Architect.)

No control installations, no registry mess, no DLL hell, no .Net
framework
hell. Just a larger exe and no worries.

Jim Hubbard

 

[Jim Hubbard]

Not more than 4 hours sleep @ night all week......it's catching up to me.

Here's that
link.....http://www.sellsbrothers.com/news/showTopic.aspx?ixTopic=1646 .

Jim Hubbard

Here's a link to Chris Sells' blog (that links to my blog) about the
program. It's called Thinstall, and it rocks!

Let me know if there is anything I can do to help.

Jim Hubbard

Jim, could you possibly tell me what you are using to wrap everything up
in
one exe? If it is a commercial product (or free one) please let me know
at:

john [at] fluidnature dot com? thanks so much (especially if its
something i
can use!)

you said: >>>>>

We've conqured all of these problems by just sending out one EXE that
wraps
all of the code (DLLs, EXEs, etc.) into a single executable that doesn't
need any installed .Net frameworks (if that is what we choose to code the
app in) or any dependencies apart from Windows itself.

If you use .Net for your apps, the EXE is still really big, but if you
use
something like C++ or even VB 6 your resulting exe is much smaller.

Since we are wrapping everything, .Net really has no advantages other
than
webservice ease of use. And, we get to continue using our old skillset
and
thousands of dollars on third party controls without worrying about .Net
COM
interop screwing it up. (The Dart/PowerTCP activeX controls will not
work
with .Net 1.1 - Studio 2003 Architect.)

No control installations, no registry mess, no DLL hell, no .Net
framework
hell. Just a larger exe and no worries.

The whole idea behind the .Net framework was to allow different
versions
of
the framework and code to run side-by-side.

You'll be lucky. It's DLL hell all over again. This is why internet
Java
was
such a disaster. I remember the banks using it and then spending all
day
trying to troubleshoot end-users broken and disparate JVMs.

.NET is just as bad. "Which version of .NET are my 200,000 customers
using",
"oops it won't work on that one". "Oh you've got XP gold", "You need
Longhorn for that one", "You're on Win98SE". That's before you even
get to
service packs on hotfixes on the client's machine.

Damned right! In another thread, I had asked the question "Why is .Net
an
optional download?" If .Net is so important to the future of Microsoft
products, the .Net frameworks should be downloaded and installed
automatically along with security updates and such. It should be core
to
the OS.

Even if one .Net framework is shipped with the OS, what about the next
version? These things have to be required (at least highly recommended)
updates to the OS.

Now, I know each .Net framework is a bloated, massive amount of code for
most people to download - so, the next question is why Microsoft didn't
use
the technology built into .Net to make .Net exe's download only the
portions
of .Net that they need to run, if those portions don't exist on the
machine
the exe is being launched on? If a .Net application can tell it doesn't
have
the DLLs required for a function and will request those downloads from
the
server hosting the program's exe, why couldn't each exe contain similar
code
for the .Net framework?

Beats the hell out of me.


The whole thing is a mess, and can only get worse with Longhorn. They
claim
Longhorn will embrace .NET, but so far we have no credible DirectShow
assemblies, and even if we did they'll fall way short of the
capabilities
of
COM. Do they have an LSA in managed code yet? What about the LDAP API?
Where
is WinFS? Where are the native UNIX and Fibre SAN connectors?

I SO wish you weren't right......unfortunately, you are.


All we've seen so far is the step backwards known as "Avalon" where
current
W3C UI markup will be replaced by proprietary "Windows Only" code, and
how
exactly will this help the Enterprise? "View your sales figures in a
rotating 3D DirectX cube", LOL!

And Microsoft rolls on......

We've conqured all of these problems by just sending out one EXE that
wraps
all of the code (DLLs, EXEs, etc.) into a single executable that doesn't
need any installed .Net frameworks (if that is what we choose to code
the
app in) or any dependencies apart from Windows itself.

If you use .Net for your apps, the EXE is still really big, but if you
use
something like C++ or even VB 6 your resulting exe is much smaller.

Since we are wrapping everything, .Net really has no advantages other
than
webservice ease of use. And, we get to continue using our old skillset
and
thousands of dollars on third party controls without worrying about .Net
COM
interop screwing it up. (The Dart/PowerTCP activeX controls will not
work
with .Net 1.1 - Studio 2003 Architect.)

No control installations, no registry mess, no DLL hell, no .Net
framework
hell. Just a larger exe and no worries.

Jim Hubbard

 

[Guest]

Thanks! I would loan you some sleep if I had any...

Not more than 4 hours sleep @ night all week......it's catching up to me.

Here's that
link.....http://www.sellsbrothers.com/news/showTopic.aspx?ixTopic=1646 .

Jim Hubbard

Here's a link to Chris Sells' blog (that links to my blog) about the
program. It's called Thinstall, and it rocks!

Let me know if there is anything I can do to help.

Jim Hubbard

Jim, could you possibly tell me what you are using to wrap everything up
in
one exe? If it is a commercial product (or free one) please let me know
at:

john [at] fluidnature dot com? thanks so much (especially if its
something i
can use!)

you said: >>>>>
We've conqured all of these problems by just sending out one EXE that
wraps
all of the code (DLLs, EXEs, etc.) into a single executable that doesn't
need any installed .Net frameworks (if that is what we choose to code the
app in) or any dependencies apart from Windows itself.

If you use .Net for your apps, the EXE is still really big, but if you
use
something like C++ or even VB 6 your resulting exe is much smaller.

Since we are wrapping everything, .Net really has no advantages other
than
webservice ease of use. And, we get to continue using our old skillset
and
thousands of dollars on third party controls without worrying about .Net
COM
interop screwing it up. (The Dart/PowerTCP activeX controls will not
work
with .Net 1.1 - Studio 2003 Architect.)

No control installations, no registry mess, no DLL hell, no .Net
framework
hell. Just a larger exe and no worries.


:



The whole idea behind the .Net framework was to allow different
versions
of
the framework and code to run side-by-side.

You'll be lucky. It's DLL hell all over again. This is why internet
Java
was
such a disaster. I remember the banks using it and then spending all
day
trying to troubleshoot end-users broken and disparate JVMs.

.NET is just as bad. "Which version of .NET are my 200,000 customers
using",
"oops it won't work on that one". "Oh you've got XP gold", "You need
Longhorn for that one", "You're on Win98SE". That's before you even
get to
service packs on hotfixes on the client's machine.

Damned right! In another thread, I had asked the question "Why is .Net
an
optional download?" If .Net is so important to the future of Microsoft
products, the .Net frameworks should be downloaded and installed
automatically along with security updates and such. It should be core
to
the OS.

Even if one .Net framework is shipped with the OS, what about the next
version? These things have to be required (at least highly recommended)
updates to the OS.

Now, I know each .Net framework is a bloated, massive amount of code for
most people to download - so, the next question is why Microsoft didn't
use
the technology built into .Net to make .Net exe's download only the
portions
of .Net that they need to run, if those portions don't exist on the
machine
the exe is being launched on? If a .Net application can tell it doesn't
have
the DLLs required for a function and will request those downloads from
the
server hosting the program's exe, why couldn't each exe contain similar
code
for the .Net framework?

Beats the hell out of me.


The whole thing is a mess, and can only get worse with Longhorn. They
claim
Longhorn will embrace .NET, but so far we have no credible DirectShow
assemblies, and even if we did they'll fall way short of the
capabilities
of
COM. Do they have an LSA in managed code yet? What about the LDAP API?
Where
is WinFS? Where are the native UNIX and Fibre SAN connectors?

I SO wish you weren't right......unfortunately, you are.


All we've seen so far is the step backwards known as "Avalon" where
current
W3C UI markup will be replaced by proprietary "Windows Only" code, and
how
exactly will this help the Enterprise? "View your sales figures in a
rotating 3D DirectX cube", LOL!

And Microsoft rolls on......

We've conqured all of these problems by just sending out one EXE that
wraps
all of the code (DLLs, EXEs, etc.) into a single executable that doesn't
need any installed .Net frameworks (if that is what we choose to code
the
app in) or any dependencies apart from Windows itself.

If you use .Net for your apps, the EXE is still really big, but if you
use
something like C++ or even VB 6 your resulting exe is much smaller.

Since we are wrapping everything, .Net really has no advantages other
than
webservice ease of use. And, we get to continue using our old skillset
and
thousands of dollars on third party controls without worrying about .Net
COM
interop screwing it up. (The Dart/PowerTCP activeX controls will not
work
with .Net 1.1 - Studio 2003 Architect.)

No control installations, no registry mess, no DLL hell, no .Net
framework
hell. Just a larger exe and no worries.

Jim Hubbard

 

[Guest]

Well the problem is not with the hotfix concept for nontotally QA'd fixes,
but with MSFT thinking that offshore help desks provide the level of service
that their customers are entitled to. At least Dell finally (partially) got
the message. I fear that Gates and crew never will.

 

[Guest]

Dear Friends:

Please advise if Microsoft visual.net 2003 active x GUI is compatible with
windows 98 and 2000. My programmer says it is compatible only with XP, I dont
think so....can someone please help.

Thanks a lot