Why no serious MS Application in .NET yet ??

  • Thread starter Thread starter Herr Lucifer
  • Start date Start date
And the VB4/5/6 runtimes were humongous and downright prohibitive compared to
the VB3 runtime (200k and side-by-side capable to boot!). Don't even get me
started on MFC.

Your point is without insight.
 
If DDE and its peripheral technology posed a constant security hole and very
few developers use it and MS has been warning to abandon it for 10+ years,
then it should be removed.
 
Isn't at least some of SQL Server 2005 Express built using .NET. It
certainly requires the 2.0 beta of the framework. Correct me if I'm wrong (I
may well be).
 
Is it really true? .Net apps take ages to load?


Herr Lucifer" <"\n said:
Well, If it takes ages to load, then it is one!(kidding)
Ok: simply Use "Dependency Walker" which comes with VS 6 and VS 2003.

By Serious I mean sth like office. Sth that would be sold to customers.
 
Amir The Ruler said:
Is it really true? .Net apps take ages to load?

Weelll, they take longer than an equivalent C++ app to be sure, but I don't
think I'd term it ages. I figure that you could add about 0.5 to 1 seconds
to an application load time on average. Needless to say there are ways to
cut this down a bit.
 
If there is an application in widespread use that needs extreme performance,
much more than Office, is video editing. If I am correct, Sony Vegas is a
..net application. I use another product for video editing, I just downloaded
the Vegas trial, but I would say that Vegas performance is excellent. Thus,
..net performance is not a concern even for very large and extreme projects.

I agree with those who say Office is still com just because migration costs
are huge. I wouldn't bet it won't become .net in a few years.
 
there are lots of serious applications, just because word isn't coded in .NET
doesn't mean that there arn't ones out there... I work for a large insurance
agency and all our recent upgrades on our software for insurance related
programs all seemed to of went to .NET based solutions. And these are real
world applications doing real world data handling, so I would qualify that as
a serious application
 
office is NOT written in .NET, if it was it would require the framework to be
installed first to ues it, and it does not require it at all... Tablet PC and
Media Center PC how ever ARE written in .NET
 
"Tablet PC"?
"Media Center PC"?

Media Center PC. - Microsoft Windows XP Media Center Edition 2005 is a
version of Windows XP that allows home computing and entertainment to
be joined into one device -

Do you care to maybe rephrase that?
 
I am not sure if this has been pointed out (I didn't read every post) But
most of SharePoint is written in .NET and parts of SQL Server 2005 will be. I
think someone mentioned .NET was released about 3 years ago and Microsoft has
been busy getting it to a point where they want it. The newer applications
are starting to include more and more .NET code; but it's a step by step
transition just like any company.

- Jonathan
 
I am not sure if this has been mentioned yet, but in addition to SPS 2003,
BizTalk Server 2004 is touted as the worlds largest .NET code base with >1
million lines of C#. With an investment like that it is hard to convince me
that MS is not fully vested in its .NET strategy.
 
i'm convinced now for sure

--
Regards,
Alvin Bruney
[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
available at www.lulu.com/owc
_________________________
 
1: Look at the website you're browsing right now. The address looks to me
like http://msdn.microsoft.com/newsgroups/default.aspx?...
So that's a section of the microsoft site, and the default page has an aspx
extension. That means it's using ASP.NET. You'll see that all over the
microsoft site - most of it (from what I've seen anyway) uses ASP.NET now.
That seems to me like a pretty serious MS (Web) Application in .NET don't you
think.

2: Ever heard of Longhorn? WinFX, Avalon, Indigo, WinFS, etc... Though I
guess as an Operating System, Windows doesn't really count as an application
so it doesn't quite fit with your question.
 
I was under the impression that most of ASP.NET was written in .NET. If this
is the case, I would call that a very serious and indeed, large MS
Application.
 
Well... clearly you are unaware or overlooking the first official, major,
inarguably serious Microsoft application every written exclusively by
leveraging the .NET framework.

You probably remember what it is by now and surely you're a bit embarrassed,
but for the benefit of everyone else, that application is:

Microsoft Customer Relationship Management

I can hear the objections already... but, make no mistake, MS CRM is, in
fact, a Microsoft application.

It's also a show case for no compromise, no legacy development methods we
should all seek to emulate. Further, an application of MS CRM's scale being
developed using the most advanced development system Microsoft has to offer -
PROVES that if you have unlimited financial resources, two years, enough
graphic artists, marketing professionals and offshore developers to rebuild
the Hoover dam, and an unrepentant capacity to mislead the industry; you TOO
can build a collection of incomprehesible pages that are almost good enough
to install if it were free - with or without the framework.

But, just for the record. I like .NET.
 
Herr said:
Replace the API? You're kidding! Dot Net doesn't really do anything on its
own. It only calls the unmanegd APIs (built in Win32) from a managed
environment. Take a look inside the framework yourslef to see what is really
there.

But what does it matter, really? This is what OO is all about, create an
object with a defined purpose, expose an interface and hide the
implementation. Today they are wrappers, tomorrow they can be fully managed.

Mono today implements 95% of Windows.Forms in managed code, in the
future .NET Windows.Forms can be based in Avalon and the application
won't even notice.
 
True from what I see. Next version of ASP.NET is about 95% c#. Not sure
about how much, if any, is in rest of IIS 7.0.
 
Another reason, which may have been mentioned already, is .NET is slower,
for one obvious reason. Current Windows is build in unmanaged code, so, .NET
code must run in an AppDomain. Doing that requires the creation of a seperate
environment for that code, and, must then use .NET's internal interop to turn
it into unmanaged code, then finally machine code the computer can process
outside of the AppDomain. However, when Longhorn is released, It will go from
managed code directly to machine code, skipping any interop. In today's date,
that is just extra work, when using Forms at least. Web Applications on the
other hand, are a different matter. Look at Microsoft's Web Site. You can see
for the most part, they are porting it to ASP.NET. It isn't limited to
console applications. However, there are little programs Microsoft has made
with .NET. Like the "Time Zone Utility", you can see that in Downloads. We
are talking about a massive code shift. It it hailed as a revolution.
Revolutions take time to go into effect. Unmanaged code will be around for
decades, maybe longer. I still see Applications written in COBOL and Turbo
PASCAL. Even though .NET is really nice to use, why re-write a program with
Managed Code if the Unmanaged code is equally is good? Interop will always be
a part of .NET In a sense, Interop is what makes .NET famous. It was hailed
because it was a major update, and it didn't require a complete abandon of
old code.
 
VC# Jones said:
Another reason, which may have been mentioned already, is .NET is slower,
for one obvious reason. Current Windows is build in unmanaged code, so,
.NET
code must run in an AppDomain. Doing that requires the creation of a
seperate
environment for that code, and, must then use .NET's internal interop to
turn
it into unmanaged code, then finally machine code the computer can process
outside of the AppDomain. However, when Longhorn is released, It will go
from
managed code directly to machine code, skipping any interop.

You're confusing managed and native code. Managed code is generally compiled
to native (via JIT/NGEN). Interop is the transition between
managed/unmanaged. Even if you have 2 sets of code compiled to native, if
one is managed and one unmanaged, it will still require interop to cross
between them. Longhorn will not make any changes in the execution model, but
will result in more managed interfaces to the OS, which *should* result in
less interop requirements. AppDomains do not always imply a separate
environment, merely a separate logical process.
In today's date,
that is just extra work, when using Forms at least. Web Applications on
the
other hand, are a different matter. Look at Microsoft's Web Site. You can
see
for the most part, they are porting it to ASP.NET. It isn't limited to
console applications. However, there are little programs Microsoft has
made
with .NET. Like the "Time Zone Utility", you can see that in Downloads. We
are talking about a massive code shift. It it hailed as a revolution.
Revolutions take time to go into effect. Unmanaged code will be around for
decades, maybe longer.

Oh yeah, I'd say at least as long as assembler has been around so far.
I still see Applications written in COBOL and Turbo
PASCAL. Even though .NET is really nice to use, why re-write a program
with
Managed Code if the Unmanaged code is equally is good?

Couldn't agree more.
Interop will always be
a part of .NET In a sense, Interop is what makes .NET famous. It was
hailed
because it was a major update, and it didn't require a complete abandon of
old code.

Again, couldn't agree more. I hear people whining about how stuff isn't
"pure" .NET, and the whole point about COM Interop/P/Invoke/IJW and suchlike
is that they make all these disparate technologies part of .NET in a sense.
 
Small Business Accounting 2006, Business Contact Manager, Retail Management
System to name a few, and that's just in the business solutions org.
 
Back
Top