Fog Creek Software
Discussion Board

Real .NET applications out there?

Do you know of any real commercial application (not custom solutions) written using pure C# or VB.NET in the market right now?

Would you pay for an application written in a .NET language?


William Williams
Monday, May 12, 2003

What do you mean by "pure"?
I paid for would that count?

Just me (Sir to you)
Monday, May 12, 2003

SourceGear's 'Vault' on the front page of this site and probably a ton of other ones too.

Monday, May 12, 2003

Would I pay for an application just because it's written in .NET? No.

Would I pay for an application that meets my needs, regardless of what it's written in? Absolutely.

The underlying implementation language doesn't really matter to the end user. .NET is good for us developers because it lets us get more work done in less time. The end user really doesn't care.

Chris Tavares
Monday, May 12, 2003

I think the point here is that you are unlikely to see lots of client-side applications written for .NET until the install-base gets much bigger.

In addition, if a company already has a working product for the win32 platform, it's unlikely that it will port it to .NET, unless there is a very significant upside.

For new server-side applications or applications written for a controlled business environment, I believe you are going to see a significant penetration in the near future.

What I would like to see is a version of the Office suit written for .NET . That would signify the MS is eating its own dog food.

Dan Shappir
Monday, May 12, 2003

Explorer.exe in Longhorn has apparently been (re-)written as a .NET managed application.

John Topley
Monday, May 12, 2003

I'm pretty sure that Microsoft Content Management Server 2002 is at least partially built with the .NET Framework.

Monday, May 12, 2003

I'm guessing you'll have to wait until at least 2005 for that - Microsoft recently announced that as its target ship date for Longhorn, and we all know about Microsoft's record when it comes to punctuality.

Anyway, assuming Longhorn does everything it's supposed (rumored?) to do, Microsoft will have to rewrite all of its applications to run on the new OS. I don't see any reason why they wouldn't pick .NET for this task, although I'm sure that there are a lot of interesting features that they will "rewrite" by wrapping old C code in managed C++ classes. The young coders assigned to work on the new Office will probably be kind of disappointed at the lack of innovation required.

On an only-somewhat-related note, I do not envy anyone working on Office (except for the XDocs people, perhaps). They have a twenty-year-old code base of C, C-like C++, and some assembler; the applications built by that code have been notoriously late, subject to multiple hacks, rewrites, etc., just to get them out the door. To go in as a new employee and have to wade through millions of lines of:

if (IE 5 is installed && Win2K service pack 2 is installed)

would just be horrible. I mean, Word shipped, what, three years late? After an infamous death march akin to the NT horror story? I bet the code wasn't pretty then - imagine what it looks like now, years later... the product is solid, but I doubt it's due to refactoring.

Dan J
Monday, May 12, 2003


It is not clear to me that the platform or technology used to implement an application is transparent or not significant to the end user. Also, I realize that it is very convenient to write a server side application using .NET. So, my new 3 questions are:

Do you know of any desktop applications available written in .NET languages?

How exactly .NET helps me write desktop applications in less time?

You have to choose your development language by tomorrow to write a desktop application. Would you choose a .NET language?

Thanks again.

William Williams
Monday, May 12, 2003

"Do you know of any desktop applications available written in .NET languages?"

Nope. I can't think of any new desktop apps period, nevermind ones written with .NET.

"How exactly .NET helps me write desktop applications in less time?"

You only need to work with the platform for a short time before you realize how awesome the APIs are. First of all, in building off the work (and mistakes) of past technologies, Microsoft is offering an SDK that does OOP right. The components and patterns "just make sense" (obviously, this is not 100% true, but it's as close as we're going to get, I believe). Secondly, there is a lot more functionality/automation available for less; that is, you accomplish more while writing less in terms of LOC.

"You have to choose your development language by tomorrow to write a desktop application. Would you choose a .NET language?"

If you're writing a desktop app, I'd pick C# - Java sucks on the desktop, and that's all there is to it. This does not mean that Java sucks (in fact, I'm really excited about 1.5), just that it has its place, and that place is not on the desktop. C# is very Java-like, but the GUI API is platform specific and thus, more efficient/pretty/etc. Plus, it's easy to compile down to "real" executables and get another performance boost.

Of course, this assumes that you don't mind being a "Microsoft shop". If you have ideas about developing with .NET but keeping your options open... I'd say it would be best to leave those ideas behind. Windows is the only desktop platform you need to worry about in terms of making money, so you might as well throw caution into the wind and play Microsoft's game. There are people out there who are terrified of vendor lock-in, but if you're on the desktop... there's really only one vendor you want to be associated with anyway.

Dan J
Monday, May 12, 2003

I remember reading an interview by Brian Valentine, Ms's  Windows big boss. He said that new applications would be built in managead code, and rewrites would be done if necessary.

And of course Longhorn won't require anyone to rewrite their apps. All the new eye-candy is going to work with software previously written.

Not my real name.
Monday, May 12, 2003

Hippo.Net is a app the runs under the .NET framework that I came across recently, free however -

There are also a few aggregators out there such as SharpReader that people have been praising, but again, they are free.

You could try doing a search on Google for .NET Framework required or something similar and probably come up with a few results-

SourceVault looks quite good.

Monday, May 12, 2003

Um, have you ever run Visual Studio .NET? It's a fully managed .NET application, written in C#.

Monday, May 12, 2003

William, I see .Net as more for corporate i.e in-house, applications, than for packaged software, at this stage anyway.

For packaged software, C++ or VB are still the best choices.

Tuesday, May 13, 2003

Why would Longhorn require a rewrite of all the apps? Surely, if you want some new functionality, than you aree going to have to extend or adapt parts of your program. If you were relying on unpublished API's, then partial rewrites could be required. Yes, maybe some adaptation will be required to get in line with new security tightening, but full rewrites?

Just me (Sir to you)
Tuesday, May 13, 2003

Why not .NET for packaged software? I don't get it.

John Topley
Tuesday, May 13, 2003

A preview version if not a full release:

Tuesday, May 13, 2003

"Why not .NET for packaged software? I don't get it."

There's nothing intrinsically bad about .NET that would prevent one from writing Windows retail software based on the .NET Framework. Technically it's better suited to that purpose than any other platform.

However, customers need the .NET Framework which weighs in at over 20 MB. While not a big deal compared to the average user's porn/MP3 archive, most people still throw a hissy fit at the thought that they'd have to download ANYTHING extra. Even with CD-ROM distribution, the separate installation is significantly longer and more complicated than for a Win32 executable.

Also, Microsoft has rather badly botched its .NET propaganda when they first slapped that label on practically everything they were rolling out from 2002 onward. Combine that with the usual hysterical anti-MS propaganda, and you have people who firmly believe that their computer will instantly upload all their credit card numbers to Microsoft once they install the .NET Framework.

Lastly, when .NET 1.0 was released quite a few people questioned MS if/when/how they would actively promote that platform to end users, and if they would push .NET like they pushed Internet Explorer when it was new. The reply was... a deafening silence. So it was generally concluded that MS itself doesn't really trust .NET on end-user computers right now, and would like to conduct some more research with lab monkeys (i.e. in-house and web apps) while introducing the new platform gradually with new Windows releases.

Oh, and despite what I said above there are still some minor issues from a technical perspective -- generics announced but still some way off, performance problems with GDI+, people still rather puzzled how to do localisation, stuff like that. Given all the other factors, it just makes sense to hold off for now and wait how things shake out.

Chris Nahr
Tuesday, May 13, 2003

Oh yeah, and it's not as if Microsoft had any real competition in the Windows retail market anyway. Java or Delphi never went anywhere in that area. Web and in-house are the only areas where MS faces competition, and since .NET is doing well enough there, they probably figure it's no use to take on the extra risks and expenses for aggressively pushing .NET in the reail area.

Chris Nahr
Tuesday, May 13, 2003

Do a search for .aspx on google - you get lots of search result where the URL ends in a file extension of .aspx - asp .net seems to be used widely.

Michael Moser
Tuesday, May 13, 2003

"Um, have you ever run Visual Studio .NET? It's a fully managed .NET application, written in C#. "

Actually, that's not quite right.  Portions of VS were written in C#, but considerable portions are still in C++, including all of the VB.NET and C# compilers.  (The JScript.NET compiler is entirely written in C#.)

Also, some managed portions of VS.NET are written in VB.NET, not C#.  The majority of the managed components are C# though.  Generally speaking, new code is being implemented in C# whenever possible. 


Eric Lippert
Tuesday, May 13, 2003

I'll be releasing beta 1 of a new version of our shrink-wrapped Windows app that we've done completely in .net later this week. So far the rewrite has been smooth and everything has been as expected and as advertised.

The app was originally done in VB6. For version 2 we had so many radical changes that we would be rewriting everything except for the basic business logic and the general UI shell. The logic code was able to move over essentially unchanged, and recreating the UI in .NET with a few good UI components took less than a day (and it has planty of advantages over the previous version). So for us, the choice was clear. The framework is not really a big issue for us as we only ship on CD for the foreseeable future, and it's a bit of a niche app where OS requirements don't stop anyone from using it.

We'll also be releasing a major new enterprise-level product at the end of the summer. This will be a client/server app with a Win32 client and a browser-based client, a desktop-only version, and a PocketPC utility app to go with it. For this system, .NET also was the only clear choice. By clear choice I mean both from a technical and business perspective.

So, I think there are some out there, but as it's relatively new it will be a while before clean-sheet products are released and a bit longer before a lot of existing apps are moved over. But, we've not seen any reason why it would not be suitable for desktop or enterprise development. In fact, for us .NET has been a huge advantage in all of our projects.


Tuesday, May 13, 2003

Finaly found some reference to the "pure .NET" proposition. This article denounces the notion of a "pure .NET" concept (as in "pure Java")
Interesting read.

The Myth of .NET Purity

Just me (Sir to you)
Wednesday, May 14, 2003

BTW I have released 3 applications with .NET but they are internal application that are revelant to this perticuliar plant configuration so that's a REAL application it's just not out there it's out here !

Application Specialist
Wednesday, May 14, 2003

*  Recent Topics

*  Fog Creek Home