Explosion of .NET programs?

[Olaf Baeyens]

I have seen a lot of talk about .NET and C# and stuff, but so far I didn't
see any commercial programs yet.
Until know, I happen to stumble on some programs that seems to be a .NET
program and expects the .NET framework installed.

Is this .NET thing finally taking off? Or is it just sheer luck that I
stumbled on these?
This would be nice since that means many more machines have this .NET
framework already installed.

The lack of installed .NET framework on client machines, is what prevents us
to create commercial .NET programs.
A lot of our customers simply find installing the .NET framework through the
windows update too complicated.
And because the mulitple language versions of this .NET, it is impossible to
ship our software with a .NET version for each possible Windows language.

It would be nice if the .NET framework is installed by Microsoft in some
service pack or critical update automatically.
But I am afraid if they do that, then Microsoft might end up in some court
again.
One potentional solution might be that Micrsoft updates its windows core
that it can detect .NET programs and automatically starts up a dialog box
telling the user that this is a .NET program and that he needs to install
the .NET framework. Maybe this dialog can automatically direct the user to
the correct download area.

 

[John Spiegel]

Hey Olaf,

Some theories on the lag time for .NET programs becoming prevalent:

1) A lot of preexisting packages continue to be written in their prior
languages. This is a bit of a shift from before in that with, say a VB5
app, migrating to VB6 was fairly simple. Now an existing product would need
to nearly be rewritten to use .NET.
2) As it's still kind of newish (though, yes, in IT three or so years is
"established"), it hasn't had a LOT of time to have companies decide to make
the jump then get the code written (many projects take a couple years before
they're ready for release).
3) Many efforts are web-based these days. Unless you're looking for the
"x" on aspx, you may have little way to know whether it was .NET based or
not.
4) As to the issues you've indicated with framework installation, I can't
remember, but isn't it preinstalled on 2003 server and upcoming Windows
platforms? Not a lot of companies have everything upgraded to the latest
and greatest--many are still running OSs that don't even support the
framework, much less have it preinstalled. I'm guessing that's made it less
attractive to bet your product on it for some companies.

Just my thoughts...

- John

 

[Guest]

I'd bet that you have seen .Net executables but you just didn't realize that
they were .Net applications.

Yes, there are a lot of developers that are still using previous versions of
software to develop their software.

Still have some Visual Basic 6 projects but those are to be converted soon
to VB .Net!

All my new projects are .Net based.

 

[Olaf Baeyens]

1) A lot of preexisting packages continue to be written in their prior

languages. This is a bit of a shift from before in that with, say a VB5
app, migrating to VB6 was fairly simple. Now an existing product would need
to nearly be rewritten to use .NET.

This is one of the reasons I hear why people do not jump onto the .NET
wagon.
Another thing is they think that .NET applications are only for Internet
related stiff.
Another thing I hear is that it is a Java clone, so also slow, which is
untrue as far as I have discovered: I do not notice a performance difference
between conventional and .NET programs.
Some things are faster in .NET some things are faster in conventional code,
but the average speed of the programs stays equivalent.

But the reason that always comes back, and in my opinion is the main reason
why it is lagging behind, is the fact that it is not pre-installed on user
machines.
Unlike the mfc dll's it is too big to ship it with the program, and there
are too many language versions of the .NET framework to create a good
installer.
As far as I understand, if I install the English .NET framework shipped with
my installer, then the user cannot install the French version anymore if he
is a Frenchmen.
So we have to rely on the user to get it from the Internet themselfes and
this seems to be a too big a step for common users. As a IT and developer
this sounds funny since it is only a few button clicks away, but the scare
of people that they will not be able to complete the task and make their
computer selfdestruct or something like that, makes users not to want to use
the program. They prefer to stick to the older program. (Ok I made it sound
more dramatic than it really is. )

I even know software developers that refuses to install that .NET framework
like it is some evil thing.
They are scared that it wil disrupt their system, or slow down their
existing none-.NET applications.

3) Many efforts are web-based these days. Unless you're looking for the
"x" on aspx, you may have little way to know whether it was .NET based or
not.

You are right about this!

4) As to the issues you've indicated with framework installation, I can't
remember, but isn't it preinstalled on 2003 server and upcoming Windows
platforms? Not a lot of companies have everything upgraded to the latest
and greatest--many are still running OSs that don't even support the
framework, much less have it preinstalled. I'm guessing that's made it less
attractive to bet your product on it for some companies.

The problem is that most users use Windows 2000 and up, but our software is
not server oriented software.
I do not know if Longhorn will have .NET installed by default. I do know
that they have something that resembles .NET but I have no idea if current
..NET programs will run on it without installing something else. Then again,
it is still a loooong way for the release of Longhorn.

The bet is something like this: The choice to develop the same code in
conventional style in 10 months or develop that same code using the .NET
framework in 2 months.
I have to admit that the first .NET program will take more time than the
convetional program, but since you create modular assemlies you will speed
up afterwards.

Now these are my viewpoints only.
Other people might have other viewpoints.

I really do love the way the .NET is going, from IT point (security, robuust
programs) of view and a developer point of view (RAD).