What does Microsoft write in .Net?

[jim]

Maybe I'm missing something, but it doesn't look like Microsoft writes a lot
of apps in .Net (although they certainly push it for others).

What does MS write using pure .Net?

If applications like Symantec's antivirus, NeatReciepts or Franklin Covey's
PlanPlus for Windows is any guide, .Net applications are slow and clunky.
But, maybe the developers of these apps simply don't know how to write a
decent app with .Net.

Microsoft should know how to write killer .Net apps. So, where are they?

And, if Microsoft can't write killer .Net apps, is it any wonder that nobody
else can?

jim

[David Pendleton]

SQL Server Management Studio is written in .NET.

There are most certainly others, but that is one.

"jim" <ji*@home.netwrote in message
news:_d******************@bignews3.bellsouth.net.. .

Maybe I'm missing something, but it doesn't look like Microsoft writes a
lot of apps in .Net (although they certainly push it for others).

What does MS write using pure .Net?

If applications like Symantec's antivirus, NeatReciepts or Franklin
Covey's PlanPlus for Windows is any guide, .Net applications are slow and
clunky. But, maybe the developers of these apps simply don't know how to
write a decent app with .Net.

Microsoft should know how to write killer .Net apps. So, where are they?

And, if Microsoft can't write killer .Net apps, is it any wonder that
nobody else can?

jim

[Ashot Geodakov]

http://www.microsoft.com is developed in ASP.NET - at least judging by the
web page file extensions (aspx).

"jim" <ji*@home.netwrote in message
news:_d******************@bignews3.bellsouth.net.. .

Maybe I'm missing something, but it doesn't look like Microsoft writes a
lot of apps in .Net (although they certainly push it for others).

What does MS write using pure .Net?

If applications like Symantec's antivirus, NeatReciepts or Franklin
Covey's PlanPlus for Windows is any guide, .Net applications are slow and
clunky. But, maybe the developers of these apps simply don't know how to
write a decent app with .Net.

Microsoft should know how to write killer .Net apps. So, where are they?

And, if Microsoft can't write killer .Net apps, is it any wonder that
nobody else can?

jim

[Peter Duniho]

jim wrote:

Maybe I'm missing something, but it doesn't look like Microsoft writes a lot
of apps in .Net (although they certainly push it for others).

What does MS write using pure .Net?

If applications like Symantec's antivirus, NeatReciepts or Franklin Covey's
PlanPlus for Windows is any guide, .Net applications are slow and clunky.

Applications that are "slow and clunky" have been around for a lot
longer than .NET. IMHO, they are the norm. Most people writing
software don't write really good software. They write "good enough"
software, and consumers don't know any better than to just use it.

They might complain, but when a new version comes out, they're right
there in line to buy it. They don't vote with their dollar and they get
the natural consequences.

So, if you find .NET applications that are slow and clunky, don't blame
..NET. Blame the folks who wrote them.

But, maybe the developers of these apps simply don't know how to write a
decent app with .Net.

Microsoft should know how to write killer .Net apps. So, where are they?

No doubt some already exist. However, most of Microsoft's code base
predates .NET, and any business would be foolish to waste time rewriting
perfectly good code. If nothing else, it's just an opportunity to
create brand new bugs (see the latest Microsoft Excel 2007 recalc bug,
for example). It's also just a waste of resources.

And, if Microsoft can't write killer .Net apps, is it any wonder that nobody
else can?

Well, since I don't agree with the premise that "nobody else can", I
find the entire question meaningless. I'm sure that Microsoft or anyone
else could write a "killer .NET application" if they wanted to. I'll
bet some "killer .NET applications" are already out there, and you just
haven't come across them.

I haven't had the "pleasure" of using any truly awful .NET applications
yet. I know for my own part, the .NET applications I've written seem to
work pretty well (but then I haven't used any of the applications you
mentioned).

I'm impressed with the performance that's possible in .NET, and I'm
finally getting over my initial prejudice against it. That prejudice
was based solely on assumptions and no first-hand experience, and the
last few years I've been doing .NET stuff have proved me substantially
wrong about the performance cost of using .NET.

If anything, having such an extensive framework helps performance,
because I can implement remarkably complex behaviors without having to
reinvent the wheel, writing a sucky, clunky, slow implementation because
I didn't know all the ins and outs of the API I was using. I'm not
dumb, but with most APIs you have to have a fair amount of experience to
get the best performance out of them.

..NET is the same, but a lot of the performance tips and tricks are very
general and not hard to learn. The actual implementations in .NET were
written by people who know their stuff, and perform very well, often as
well or much better than you or I could accomplish on our own.

So, if you're having trouble writing good .NET applications, you just
need to look harder at how you're using .NET. When used correctly,
there's really no problems at all for the vast majority of applications,
and in fact a .NET application has the potential for being much better,
because it takes so much of the opportunity for creating bugs
(performance or behavioral) out of your hands.

Pete

[Smithers]

<snip>
RE:
<< So, if you find .NET applications that are slow and clunky, don't blame
..NET. Blame the folks who wrote them. >>

Exactly.

Pointing to or even suspecting a particular platform as, itself, being slow
is completely naive. As an independent consultant who has made a very
comfortable living over the past 10 years fixing slow apps written by
idiots, I can tell that the number one cause of slow performance I've seen
is crappy architecture... followed closely by terrible database design (i.e.
not even partially normalized). I have seen smokin' fast MS Access
applications, FoxPro, Clipper, VB6 apps, and .NET apps. I have also seen
terrible C++ apps (I know, blasphemy!).

It's all about architectue and good design.

But, as you pointed out, most people can't or don't care to get it right.
It's so easy for these lazy or incompetent folks to think they can throw
hardware at it when performance is slow. Frequently that doesn't even buy
temporary relief.

-S

"Peter Duniho" <Np*********@NnOwSlPiAnMk.comwrote in message
news:13*************@corp.supernews.com...

jim wrote:

>Maybe I'm missing something, but it doesn't look like Microsoft writes a
lot of apps in .Net (although they certainly push it for others).

What does MS write using pure .Net?

If applications like Symantec's antivirus, NeatReciepts or Franklin
Covey's PlanPlus for Windows is any guide, .Net applications are slow and
clunky.

Applications that are "slow and clunky" have been around for a lot longer
than .NET. IMHO, they are the norm. Most people writing software don't
write really good software. They write "good enough" software, and
consumers don't know any better than to just use it.

They might complain, but when a new version comes out, they're right there
in line to buy it. They don't vote with their dollar and they get the
natural consequences.

So, if you find .NET applications that are slow and clunky, don't blame
.NET. Blame the folks who wrote them.

>But, maybe the developers of these apps simply don't know how to write a
decent app with .Net.

Microsoft should know how to write killer .Net apps. So, where are they?

No doubt some already exist. However, most of Microsoft's code base
predates .NET, and any business would be foolish to waste time rewriting
perfectly good code. If nothing else, it's just an opportunity to create
brand new bugs (see the latest Microsoft Excel 2007 recalc bug, for
example). It's also just a waste of resources.

>And, if Microsoft can't write killer .Net apps, is it any wonder that
nobody else can?

Well, since I don't agree with the premise that "nobody else can", I find
the entire question meaningless. I'm sure that Microsoft or anyone else
could write a "killer .NET application" if they wanted to. I'll bet some
"killer .NET applications" are already out there, and you just haven't
come across them.

I haven't had the "pleasure" of using any truly awful .NET applications
yet. I know for my own part, the .NET applications I've written seem to
work pretty well (but then I haven't used any of the applications you
mentioned).

I'm impressed with the performance that's possible in .NET, and I'm
finally getting over my initial prejudice against it. That prejudice was
based solely on assumptions and no first-hand experience, and the last few
years I've been doing .NET stuff have proved me substantially wrong about
the performance cost of using .NET.

If anything, having such an extensive framework helps performance, because
I can implement remarkably complex behaviors without having to reinvent
the wheel, writing a sucky, clunky, slow implementation because I didn't
know all the ins and outs of the API I was using. I'm not dumb, but with
most APIs you have to have a fair amount of experience to get the best
performance out of them.

.NET is the same, but a lot of the performance tips and tricks are very
general and not hard to learn. The actual implementations in .NET were
written by people who know their stuff, and perform very well, often as
well or much better than you or I could accomplish on our own.

So, if you're having trouble writing good .NET applications, you just need
to look harder at how you're using .NET. When used correctly, there's
really no problems at all for the vast majority of applications, and in
fact a .NET application has the potential for being much better, because
it takes so much of the opportunity for creating bugs (performance or
behavioral) out of your hands.

Pete

[Martin CLAVREUIL]

Hi,

Just two of them as an exemple : Report Builder (SQL Reporting Services
Client), Lots of part of sharepoint (ASP.net)

Smithers wrote :

<snip>
RE:
<< So, if you find .NET applications that are slow and clunky, don't blame
.NET. Blame the folks who wrote them. >>

Exactly.

Pointing to or even suspecting a particular platform as, itself, being slow
is completely naive. As an independent consultant who has made a very
comfortable living over the past 10 years fixing slow apps written by
idiots, I can tell that the number one cause of slow performance I've seen
is crappy architecture... followed closely by terrible database design (i.e.
not even partially normalized). I have seen smokin' fast MS Access
applications, FoxPro, Clipper, VB6 apps, and .NET apps. I have also seen
terrible C++ apps (I know, blasphemy!).

It's all about architectue and good design.

But, as you pointed out, most people can't or don't care to get it right.
It's so easy for these lazy or incompetent folks to think they can throw
hardware at it when performance is slow. Frequently that doesn't even buy
temporary relief.

-S

"Peter Duniho" <Np*********@NnOwSlPiAnMk.comwrote in message
news:13*************@corp.supernews.com...

>jim wrote:

>>Maybe I'm missing something, but it doesn't look like Microsoft writes a
lot of apps in .Net (although they certainly push it for others).

What does MS write using pure .Net?

If applications like Symantec's antivirus, NeatReciepts or Franklin
Covey's PlanPlus for Windows is any guide, .Net applications are slow and
clunky.

Applications that are "slow and clunky" have been around for a lot longer
than .NET. IMHO, they are the norm. Most people writing software don't
write really good software. They write "good enough" software, and
consumers don't know any better than to just use it.

They might complain, but when a new version comes out, they're right there
in line to buy it. They don't vote with their dollar and they get the
natural consequences.

So, if you find .NET applications that are slow and clunky, don't blame
.NET. Blame the folks who wrote them.

>>But, maybe the developers of these apps simply don't know how to write a
decent app with .Net.

Microsoft should know how to write killer .Net apps. So, where are they?

No doubt some already exist. However, most of Microsoft's code base
predates .NET, and any business would be foolish to waste time rewriting
perfectly good code. If nothing else, it's just an opportunity to create
brand new bugs (see the latest Microsoft Excel 2007 recalc bug, for
example). It's also just a waste of resources.

>>And, if Microsoft can't write killer .Net apps, is it any wonder that
nobody else can?

Well, since I don't agree with the premise that "nobody else can", I find
the entire question meaningless. I'm sure that Microsoft or anyone else
could write a "killer .NET application" if they wanted to. I'll bet some
"killer .NET applications" are already out there, and you just haven't
come across them.

I haven't had the "pleasure" of using any truly awful .NET applications
yet. I know for my own part, the .NET applications I've written seem to
work pretty well (but then I haven't used any of the applications you
mentioned).

I'm impressed with the performance that's possible in .NET, and I'm
finally getting over my initial prejudice against it. That prejudice was
based solely on assumptions and no first-hand experience, and the last few
years I've been doing .NET stuff have proved me substantially wrong about
the performance cost of using .NET.

If anything, having such an extensive framework helps performance, because
I can implement remarkably complex behaviors without having to reinvent
the wheel, writing a sucky, clunky, slow implementation because I didn't
know all the ins and outs of the API I was using. I'm not dumb, but with
most APIs you have to have a fair amount of experience to get the best
performance out of them.

.NET is the same, but a lot of the performance tips and tricks are very
general and not hard to learn. The actual implementations in .NET were
written by people who know their stuff, and perform very well, often as
well or much better than you or I could accomplish on our own.

So, if you're having trouble writing good .NET applications, you just need
to look harder at how you're using .NET. When used correctly, there's
really no problems at all for the vast majority of applications, and in
fact a .NET application has the potential for being much better, because
it takes so much of the opportunity for creating bugs (performance or
behavioral) out of your hands.

Pete

[jim]

David Pendleton wrote:

SQL Server Management Studio is written in .NET.

There are most certainly others, but that is one.

"jim" <ji*@home.netwrote in message
news:_d******************@bignews3.bellsouth.net.. .

>Maybe I'm missing something, but it doesn't look like Microsoft writes a
lot of apps in .Net (although they certainly push it for others).

What does MS write using pure .Net?

If applications like Symantec's antivirus, NeatReciepts or Franklin
Covey's PlanPlus for Windows is any guide, .Net applications are slow and
clunky. But, maybe the developers of these apps simply don't know how to
write a decent app with .Net.

Microsoft should know how to write killer .Net apps. So, where are they?

And, if Microsoft can't write killer .Net apps, is it any wonder that
nobody else can?

jim

I haven't had a need for this software, but thanks for the pointer. I'd
like to see it just to see the performance.

jim

[jim]

Ashot Geodakov wrote:

http://www.microsoft.com is developed in ASP.NET - at least judging by the
web page file extensions (aspx).

"jim" <ji*@home.netwrote in message
news:_d******************@bignews3.bellsouth.net.. .

>Maybe I'm missing something, but it doesn't look like Microsoft writes a
lot of apps in .Net (although they certainly push it for others).

What does MS write using pure .Net?

If applications like Symantec's antivirus, NeatReciepts or Franklin
Covey's PlanPlus for Windows is any guide, .Net applications are slow and
clunky. But, maybe the developers of these apps simply don't know how to
write a decent app with .Net.

Microsoft should know how to write killer .Net apps. So, where are they?

And, if Microsoft can't write killer .Net apps, is it any wonder that
nobody else can?

jim

Thanks Ashot! I should have been more explicit and stated that I am
mainly interested in the performance of desktop applications. I don't
really consider web-pages applications at all - especially with how they
lag behind desktop apps in functionality and speed.

This may change in the future, but I don't see it doing so in the near
future.

jim

[jim]

Peter Duniho wrote:

jim wrote:

>Maybe I'm missing something, but it doesn't look like Microsoft writes
a lot of apps in .Net (although they certainly push it for others).

What does MS write using pure .Net?

If applications like Symantec's antivirus, NeatReciepts or Franklin
Covey's PlanPlus for Windows is any guide, .Net applications are slow
and clunky.

Applications that are "slow and clunky" have been around for a lot
longer than .NET. IMHO, they are the norm. Most people writing
software don't write really good software. They write "good enough"
software, and consumers don't know any better than to just use it.

They might complain, but when a new version comes out, they're right
there in line to buy it. They don't vote with their dollar and they get
the natural consequences.

So, if you find .NET applications that are slow and clunky, don't blame
.NET. Blame the folks who wrote them.

As a programmer of 24 years, I agree with you. People can write crap in
any language, any IDE and on any platform. But, these are companies
that formerly put out very responsive UIs and applications.

I find it hard to believe that all 3 abandoned quality coding at the
exact same time that all 3 adopted .Net.

And, its not just them. I have written small, simple apps to compare
the UI responsiveness in VB, C++ and .Net. UI responsiveness in .Net
has ALWAYS been slower than even VB6 apps with the same functionality.

That is just not acceptable for my clients. Time is money to them.
They don't give a hoot what the code base is....they want, need and
demand performance.

>

>But, maybe the developers of these apps simply don't know how to write
a decent app with .Net.

Microsoft should know how to write killer .Net apps. So, where are they?

No doubt some already exist. However, most of Microsoft's code base
predates .NET, and any business would be foolish to waste time rewriting
perfectly good code. If nothing else, it's just an opportunity to
create brand new bugs (see the latest Microsoft Excel 2007 recalc bug,
for example). It's also just a waste of resources.

I agree. If it ain't broke, don't fix it. But Ms disagrees. They used
excuses like the fictional "DLL Hell" to completely destroy and rewrite VB.

>

>And, if Microsoft can't write killer .Net apps, is it any wonder that
nobody else can?

Well, since I don't agree with the premise that "nobody else can", I
find the entire question meaningless. I'm sure that Microsoft or anyone
else could write a "killer .NET application" if they wanted to. I'll
bet some "killer .NET applications" are already out there, and you just
haven't come across them.

And, I am looking. If you run across any, please let me know. I will
be comparing their UI speed and application processing speed to other
apps that do the same things.

>
I haven't had the "pleasure" of using any truly awful .NET applications
yet. I know for my own part, the .NET applications I've written seem to
work pretty well (but then I haven't used any of the applications you
mentioned).

Thank your lucky stars. They are real time wasters.

>
I'm impressed with the performance that's possible in .NET, and I'm
finally getting over my initial prejudice against it. That prejudice
was based solely on assumptions and no first-hand experience, and the
last few years I've been doing .NET stuff have proved me substantially
wrong about the performance cost of using .NET.

I have had the opposite experience on the desktop while I have seen some
gains in web page applications - especially DB connected web page apps.

>
If anything, having such an extensive framework helps performance,
because I can implement remarkably complex behaviors without having to
reinvent the wheel, writing a sucky, clunky, slow implementation because
I didn't know all the ins and outs of the API I was using. I'm not
dumb, but with most APIs you have to have a fair amount of experience to
get the best performance out of them.

True. But the payoff was usually worth the effort and, when compiled
into DLLs or written into reusable classes that work continued to pay
off for me handsomely.

>
.NET is the same, but a lot of the performance tips and tricks are very
general and not hard to learn. The actual implementations in .NET were
written by people who know their stuff, and perform very well, often as
well or much better than you or I could accomplish on our own.

So, if you're having trouble writing good .NET applications, you just
need to look harder at how you're using .NET. When used correctly,
there's really no problems at all for the vast majority of applications,
and in fact a .NET application has the potential for being much better,
because it takes so much of the opportunity for creating bugs
(performance or behavioral) out of your hands.

There are lots of good things about having a huge framework pre-written
for you. It makes coding faster and somewhat easier (once you learn the
new encyclopedia of functions again). But, being in a "safe"
environment also means that you are trapped by the performance of the
cage are in.

While there are more possible problems with more freedom, I'll take
freedom any day over security.

jim

[Smithers]

<snip>

Re:

>And, its not just them. I have written small, simple apps to compare the
UI responsiveness in VB, C++ and .Net. UI responsiveness in .Net has
ALWAYS been slower than even VB6 apps with the same functionality.

I'd be interested in knowing how you are measuring performance, on what
kinds of UI tasks, and what sorts of controls are in the UI... if you don't
mind sharing.

My personal experience is that a screaming fast UI done in .NET can slow
down noticeably when using Infragistics controls (just eyeballing it, but
noticeable for sure).

-S

[Michael A. Covington]

"jim" <ji*@home.netwrote in message
news:hI*****************@bignews8.bellsouth.net...

There are lots of good things about having a huge framework pre-written
for you. It makes coding faster and somewhat easier (once you learn the
new encyclopedia of functions again). But, being in a "safe" environment
also means that you are trapped by the performance of the cage are in.

Which, if it's designed well, will be at least as good as the performance of
anything you would have written for yourself.

I don't see any reason why .NET should degrade performance compared to
Win32.

[nightwatch77]

I also don't see any reason, and Microsoft assures everyone there's no
performance degradation if .Net is used correctly.
Then they deliver SQL Server 2005 Management Studio as a replacement
for good old Query Analyzer. The application is so unbelievably slow
(especially if used on remote desktop), if you want to do anything it
just hangs and waits and nothing happens for 10 or 30 seconds. It
looks as if they have written their first desktop application in .net
and have yet to learn how to program in new environment. The
application is not very complicated compared to other products, and
computers are hundred times more powerful than 3 years ago, so I'm
shocked that still there is a performance problem. I'm not at all
happy with that, Microsoft has done a lot of harm to desktop
developers by pushing a poor .Net implementation of Windows Forms and
they just confirm its poor quality by not using their own product.

RG

[Smithers]

Me and my team use Management Studio on a regular basis - and we have not
observed any performance problems of any kind - much less the sort you
report. My personal use goes from a couple of mid-level workstations to an
old (circa 2003) laptop. Management studio is no faster or slower than Query
Analyzer. I have used both extensively over the years.

RE: your comment:
"... (especially if used on remote desktop),..."

Have you ever thought that maybe the remote connectivity is responsible for
the slow-down? It is nonsensical to believe that somehow Management Studio,
itself, slows down when it is being controlled via RDC session. There are so
many other variables that come into play with RDC that it is simply naive to
point to SSMS and not any of those other more likely explanations. What
about the pipeline to the SQL Server? How busy is that server?

RE:
<< if you want to do anything it just hangs and waits and nothing happens
for 10 or 30 seconds >>

Your implication is that your unique experience is true for everyone. It's
simply irresponsible to imply such a false conclusion. It may be *your*
experience on crappy equipment and remote connectivity - but it's not that
way for me and the team of developers I work with who use Management Studio
extensively.

Additionally, there are many tasks that SSMS performs much *faster* than
Enterprise Manager - like enumerating the databases and other objects on a
remote server. SSMS does that work asynchronously - letting you get on with
life (big performance booster), while Enterprise Manager makes you wait.
This is a big step forward by SSMS.

- S
"nightwatch77" <ra************@gmail.comwrote in message
news:11**********************@g4g2000hsf.googlegro ups.com...

>I also don't see any reason, and Microsoft assures everyone there's no
performance degradation if .Net is used correctly.
Then they deliver SQL Server 2005 Management Studio as a replacement
for good old Query Analyzer. The application is so unbelievably slow
(especially if used on remote desktop), if you want to do anything it
just hangs and waits and nothing happens for 10 or 30 seconds. It
looks as if they have written their first desktop application in .net
and have yet to learn how to program in new environment. The
application is not very complicated compared to other products, and
computers are hundred times more powerful than 3 years ago, so I'm
shocked that still there is a performance problem. I'm not at all
happy with that, Microsoft has done a lot of harm to desktop
developers by pushing a poor .Net implementation of Windows Forms and
they just confirm its poor quality by not using their own product.

RG

[Bart]

>Well, since I don't agree with the premise that "nobody else can", I find

>the entire question meaningless. I'm sure that Microsoft or anyone else
could write a "killer .NET application" if they wanted to. I'll bet some
"killer .NET applications" are already out there, and you just haven't
come across them.

And, I am looking. If you run across any, please let me know. I will be
comparing their UI speed and application processing speed to other apps
that do the same things.

>>

Take a look at Paint.net.

I think it's a good example

http://www.getpaint.net/

Regards Bart

[nightwatch77]

Yes, I have used Paint.net some time ago and it's a very good piece of
software.
And regarding the Management Studio, I don't want to imply anything,
just have expressed my opinion about its behavior
in remote desktop environment. Maybe the problem is related to poor
network connection, but in this case all other applications
would also be very slow.. Perhaps the Management studio has greater
network bandwidth requirements than other applications,
for example MS Visual Studio 2005 performs much better. In normal
(local) use the Management Studio works fine for me, a bit slow but
acceptable, but in remote desktop its startup time is very long and
some operations start with very long delay. Well, maybe I was too
hasty in attributing the performance problems to .Net only, they could
be caused by
other factors.
RG

[Jeremiah Gowdy]

What nonsense! You need to go download Paint.NET right now.
http://www.getpaint.net This is a Photoshop type application.

You can also try Poderosa http://en.poderosa.org which is a terminal / SSH
client

There's also SQL Server Studio which is awesome.

I think your opinion on whether you should consider ASP.NET web based
applications to actually be applications is quite dated. If you look at
what can actually be done in web based applications, it compares quite
nicely with what can be done in desktop applications. The only real
difference is the output mechanism. What does it matter if your code
outputs GDI function calls to paint the screen, or outputs HTML to paint the
screen? Is a console application any less of an application because it
doesn't use the GDI directly? The type of output an application produces
doesn't define whether or not it is an application. Console, Win32 GDI,
DirectX, OpenGL, or ASP.NET / HTML applications are all applications.

As far as the "performance" of .NET overall, I have replaced the entire C++
based middleware of our telecommunications company with a straight port of
the code to C# and it outperforms our solution simply because it was easier
to take advantage of async in .NET and do less of the plumbing ourselves.
The transaction turn-around time on our middleware in .NET is now 0.0009
rather than 0.007 (timed with high rez timer).

There's nothing "clunky" about .NET, just a few ignorant people making
"clunky" applications.

"jim" <ji*@home.netwrote in message
news:_d******************@bignews3.bellsouth.net.. .

Maybe I'm missing something, but it doesn't look like Microsoft writes a
lot of apps in .Net (although they certainly push it for others).

What does MS write using pure .Net?

If applications like Symantec's antivirus, NeatReciepts or Franklin
Covey's PlanPlus for Windows is any guide, .Net applications are slow and
clunky. But, maybe the developers of these apps simply don't know how to
write a decent app with .Net.

Microsoft should know how to write killer .Net apps. So, where are they?

And, if Microsoft can't write killer .Net apps, is it any wonder that
nobody else can?

jim