Fog Creek Software
Discussion Board




Migrating to .NET

What do people think of our .NET plans?

http://www.joelonsoftware.com/articles/Our.NetStrategy.html

Please avoid religion and favorite language debates!!

Assume *for the purpose of this discussion* that .NET is the only possible platform that will work for Windows development. What I'd like to discuss are things like:

> When will people have the CLR? At what point will it be possible to distribute .NET (Windows Forms) applications to people who are going to download them over modems?

> How hard will it be to port VB6 code to VB.NET? Has anyone tried?

> Has anybody done any significant Windows Forms development in .NET yet? What are your experiences?

Joel Spolsky
Thursday, April 11, 2002

I asked question 1 over at C# forums and got a reasonable answer: http://www.c-sharpcorner.com/forum/topic.asp?ARCHIVE=&TOPIC_ID=3995

Basically, .NET magazine said:

12 months - 10%
24 months - 40%
36 months - 95%

So around 2005 we will have 95% penetration.

Ben
Thursday, April 11, 2002

A few comments:

- For code of any significant complexity, you almost certainly want to rewrite, rather than porting. The tools for porting VB6 code are imperfect, but worse, you'll end up with a bunch of calls to stuff in the Microsoft.VisualBasic namespace, which exists just to support legacy code. You'll miss out on a lot of the consistency benefits of using the "real" Framework classes.

- If you're using a component architecture, the interop between COM and .NET works fairly well, so you can migrate one component at a time while still preserving the interfaces between components.

- Now that you're all happy about consistent data types everywhere, take a look at System.Data.SqlTypes. You'll find specialized types optimized for dealing with SQL Server data. Fortunately the conversion between these types and the regular system types is clean.

- One String class everywhere, sure. But be sure to understand when you want to use System.Text.StringBuilder instead. For that matter, when you want to start moving strings around, you'll need to take a look at System.IO. There are some pretty powerful streams-and-storages concepts there.

- The release runtime does change your user agent, so tracking adoption of the CLR should be reasonably easy.I'm betting on 1-2 years before it's feasible to ship random programs using .NET instead of VB6 and still having a hope that the runtime will already be present.

Some of this sounds pretty negative; it's not meant to be. There are moving pains, but .NET is so much better than VB6/classic ASP that it's hard to move back to maintaining existing code once you're used to .NET. One of my projects for today was to whip up a grid-based browser for a couple of database columns that ran in IE. Ten minutes, and that was only because I had to deploy it to a remote machine.

Mike Gunderloy
Thursday, April 11, 2002

.NET definitely makes the whole ASP/dynamic web page building super easy with ASP.NET, but ADO.NET as far as I can tell, is a MESS.

The documentation and the book from Apress about ADO.NET give absolutely no easy to use instructions on how to do the 4 basic SQL queries that everyone wants to do (SELECT, UPDATE, INSERT, DELETE).  There are a gazillion classes and I cannot for the life of me figure out how to do a simple INSERT and even worse, get back the identity field, without creating a stored procedure.

Why do they always make the database code more cryptic every time they rewrite it?  egads...

Please, if I'm being ignorant and this is easy to do, enlighten me...

Michael H. Pryor
Thursday, April 11, 2002

Great article, as usual.

For the curious, here's a URL (courtesy Apple Computer) that will display your current browser's user agent string.

http://developer.apple.com/internet/javascript/internetdev-sniffer.html

It looks like the .NET CLR still reported. (I have a release version of .NET installed on my browser machine.)

Jack Palevich
Thursday, April 11, 2002

Michael,

Check out http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=5029

Lots of people, including myself, had a whinge about ADO.NET, turns out its not so hard, some people in the thread had a few good comments and links.

I know exactly what what you mean about the apparent added complexity to acheive simple stuff, but as I say its really quite easy, at least as easy as it ever was.

Ca'nt really contribute to the migration discussion, I'm interested though because at some stage I'm gunna want to make a buck out of .net and I'm wondering just how long I've got before I step on board...

Tony
Friday, April 12, 2002

I think I figured out a relatively clean way to get the identity back after an INSERT. I made a SQLCommand which was "INSERT INTO table (...) VALUES (...); SELECT @@IDENTITY" and then did that ExecuteScalar thing, which, lo and behold, magically returns the new row's identity. I'm not sure why I thought I was allowed to have multiple SQL statements separated by semicolons, but, there you have it. It seems to work but still scares me since Microsoft's own documentation proposes a shockingly more difficult way to do this.

Joel Spolsky
Friday, April 12, 2002

Some real-world advice: despite what Mike says above, we have had a great deal of problems with COM interop, mainly in the area of incompatible threading models.  Some context switches are causing response times (this is a C# web service on top of a C++ component) to increase by three orders of magnitude.

Could this be because our COM code stinks?  It's possible, I can't speak to that (not having directly worked with the code or the coders).  Either way, it is something to keep in mind.

Despite this problem, I have found .NET and C# especially to be excellent to work with - I'm just waiting for .NET Server to complete the puzzle (this from a J2EE/Unix freak).

Matt
Friday, April 12, 2002

What does .Net Server do that NT 2000 + CLR don't already do?

(For some reason I've been assuming that .NET Server is just the marketing name of the Server edition of WinXP?)

Joel Spolsky
Friday, April 12, 2002

A small request:
Could you (Joel, or anybody else) maybe make such a "check % of visitors having CLR" site publicly available. You just need to through together a very simple asp.net page, which looks for the HttpBrowserCapabilities.ClrVersion Property and logs that into a database (of course you can write that also in every devlopment environment). I think such a page could also be seen as a promotion asset for your site.

I would do this myself, however, you have obviously have a higher sample of visitors.

BTW I totally agree with your .Net strategy, and basically we are following the same process, that is why we need information of how distributed the CLR currently is.

Markus

Markus
Friday, April 12, 2002

I think calculating the percentage of CLR user agents based on this site statistic is not a good idea.
We are not exact target audience for CityDesk. I can bet that 30%-50% of this forum visitors have .NET on their machines.

Roman Eremin
Friday, April 12, 2002

On the issue of CLR penetration - I rely on "hired webspace", because I have enough trouble managing my *project* so that I'm more than happy to give someone an angry call instead of trying to fix that Apache configuration myself... :-P  ;-)

So I don't have (much) control over the runtime available on the webserver, and I probably would switch the bug tracker software rather than switching the hoster once the rest of my web presence is up and running.

Currently, the top three hosters in Germany are either SUN or Linux/x86 based.

Martin Baute
Friday, April 12, 2002

http://www.joelonsoftware.com/articles/fog0000000049.html

::rollseyes::

Anon
Friday, April 12, 2002

Oh, and I think you may want to look at the documentation for SCOPE_IDENTITY( )

Anon
Friday, April 12, 2002

CLR penetration is "egg and chicken" problem. Users won't download it just in case but they are definately doing it if there is some app out there they are interested in. They don't think twice if it is needed for some colorful Tetris clone. It may be better idea to bite the bullet and educate your users about CLR instead of just sitting and waiting for penetration growth.

One note about ADO.NET critique - I have no better expression for that than "learned helplessness". No-one will convince me that good old sequence - connection, command, commandtext, execute is something that kept your CPU-s busy for weeks. You are way smarter than that.

Tarmo Tali
Friday, April 12, 2002

Currently I have an Open Source project written in VB6 - TanGo Go Client @ http://www.amourtan.com/ .  I will *not* migrate to the current VB.NET even if all machines are installed with the runtime (not true for a long time).  This is why:

1.  "Edit & Continue" - a very valuable feature for me is not there in VB.Net.

2.  Upgrade Wizard doesn't try hard enough.

3.  Buggy - .NET Framework Service Pack 1 is out! So fast?  The seat is not warm yet!  I mean, writing good code is hard enough.  Now trying to write code with buggy library is a nightmare.

4.  IDE much slower than VB6's.  Maybe they can congratulate themselve for building an IDE that is much faster than JBuilder, but still slower than VB6.

Not this version, maybe the next.

Amour Tan
Friday, April 12, 2002

jack - i suspect (i have not tried) that the sniffing code at the url you posted will not necessarily produce the correct results. in fact i am pretty sure that if i browsed from home it would tell me that the system is a mac and that is is running telnet. but then i am twisted, and junkbuster is my friend.

nope
Friday, April 12, 2002

Joel, You asked, "What does .Net Server do that NT 2000 + CLR don't already do?" I am running XP Standard Server Server Beta 3 (has been rock solid). The big difference is IIS 6.0 which has a tighter integration with the .NET Framework. For instance the identity that the ASP.NET process runs under now is specified from the IIS Control Panel (thus the metabase, which is accessible through code as well) not in the Machine.Config file. Also, you get Passport Authentication built in. And if you like the new look and feel you can turn that on too. I am sure there a a bunch of other things, this is just what I have been forced to deal with.

Nick
Friday, April 12, 2002

Armor, you say "3. Buggy - ...". Please tell us what bugs you have encountered specifically. What bugs the SP fixed. My experience is that since beta 2 it has been very solid. The one drag is the way it occasionally mangles HTML code.

As for adoption rates. If you are doing ASP.NET development the time is now. Plenty of xSp are offering .NET hosting - some for extremely cheap rates on shared servers.

For the CLR redistribution, I wish I had the diffusion rate for the last VB Runtime. I would expect that CLR diffusion would be faster becasue of the number of people with high-speed connections. If you can download 100 MB of french rap music and not sweat it, why is the measly CLR download such a problem?

The bigger issue in my mind is how much FUD is there in the IT community. What will it take for a corporation with locked down desktop deployment to actually OK someone to install the CLR?

Nick
Friday, April 12, 2002

Matt - By "fairly well" I meant that at least COM interop lets you call code in both directions and get the right result back. It is indeed much slower in some cases. Also you need to watch out for complex situations that it can't handle - things like interfaces defined in one COM component and then implemented in another and you try to use the second one. (May not be a problem in the release bits; I haven't retested). But the nice thing about interop is that it can make porting less of a "big bang" and more of a gradual experience, if you can miminize the number of cross-platform calls by porting components in the right order.

Amour - Have you actually looked at .NET Framework SP1? It's insignificant. The vast majority of applications won't be affected by it at all.

Joel - Semicolons as SQL statement separator is standard SQL Server syntax. It's one of the things that makes SQL injection such a dangerous thing.

Mike Gunderloy
Friday, April 12, 2002

Joel made a decision for his company and now he is asking if his decision is the right one from the opinions of those who read this message board.  I too was gungho about .NET about 2 months ago.  I plopped down and installed the CLR, read up on C#, and read lots of articles from .NET early adopters.  No doubt my conclusion is the same as many of yours regarding .NET.... wow, finally they did something right.  After 2 weeks of deep digging into .NET, I realized something.  There's nothing new here... it's the same old computer concepts rehashed in a different way.  Object oriented-ness and dividing different technologies into namespaces?  Well haven't the Unix folks been doing this for some time already?

I have no doubt .NET will eventually be a success.  But like what was mentioned in the previous message... it won't be for years to come, not months.  A seasoned developer would not take more than 3 or 4 months to be completely immersed in .NET.  Don't worry about getting left out if you haven't climbed on the band-wagon yet.  It will only take you a short time if the market swing in the way of .NET. 

My thoughts are that computing ought to be about providing solutions no matter what the technology should be.  It would be good if the implemented technology should be superior, but not necessarily (I learned that from Joel - VB over C++ for certain things).  I am seeing Python and PHP providing similar capabilities but have been in the field for 6 or 7 years.  That ought to say something in itself....  I am not a proponent of open-source but I am certainly just as impressed in that camp's development as in Microsoft's.

That said, I just like to mention that Joel's views are beginning to steer towards that of a business owner.  Your views in earlier works are very candid and not obscured by the pressures of business... now, they very much are.  And that is the main reason driving you to embrace .NET.

Hoang Do
Friday, April 12, 2002

Could somebody explain to me where exactly the difference is between a .Net Component and a COM Component and if I had to develop a component today, which way should I go ?

Also, to add to the discussion... the big problem is that it won't only take 3 months to get aquainted with .Net. In fact, I'm reading documentation for a week now and still wasn't able to figure out the question I posted above.  Also it seems that Class-Generation in VS.NET works much better for ATL-based applications, while with Managed C++ you just get a "Hello World"-Console-Application mixed with obscure attributes.

Where does COM+ 1.5 come in ?

If you read Dr. GUI.Net for example, it seems that Microsoft changed the names of their technologies so many times, nobody is able to figure out what technology to use.

Btw, another example for that is ADO.Net, ADO, OLE DB and ODBC all mixed with MDAC which in version 2.7 (the newest one) comes without JET. Which actually means that there is no file-based database left on Windows operating systems (well, there is, you can ship the *new* version of JET with your product, it'll work fine with MDAC 2.7, even if it is deprecated).

In fact, Windows Development has become so obscure I think many developers are going back to developing libraries on their own, not using vendor-supplied libraries.

Jonas
Friday, April 12, 2002

"Assume *for the purpose of this discussion* that .NET is the only possible platform that will work for Windows development. What I'd like to discuss are things like:

"> When will people have the CLR?"

From your assumption, it's obivous people (well, Windows users at least :-) will have the CLR as soon as they load their next application; their next application must be a .NET application, since that's the only possible platform available, per your assumption.

Your assumption created a self-fulfilling prophicy, making any answer meaningless.

Rick
Friday, April 12, 2002

Good article, but I comes as a shock considering that you mentioned that .NET was vaporware: http://www.joelonsoftware.com/articles/fog0000000049.html and that you should be wary of data access strategies:
http://www.joelonsoftware.com/articles/fog0000000339.html. This pro .NET migration article was logical but suprising. Good Luck with your plan.

Mark B.
Friday, April 12, 2002

Not sure if this is an appropriate post for this thread, as it is sort of a "meta-.Net" post, but here goes.

Having played around with .Net, I must say I am impressed. I think there is great promise in the platform. However, my concern isn't so much with .Net, as it is the Microsoft servers that .Net will run on top of.

I have done network security work for close to 10 years, with all sorts of platforms. Given my experience, I cannot currently ever recommend using a Microsoft OS on a server that will be deployed on the Internet, especially if that server is running IIS. Microsoft's security is broken, broken, broken.

To be sure, it is the admin's job to patch his/her servers. Also, there are security issues with all OSes. But Microsoft doesn't seem to ever get security right. There seems to be an almost continual stream of security problems with Microsoft products.

Joel, this has the potential to hit home for FogCreek. Yesterday, I was trying out FogBugz for a client, who needs a bug tracking database that is secured, but accessable on the Internet. I was very impressed with the product. As I went to go email my client, recommending FogBugz, I received two security notices from Bugtraq about problems with IIS.

Given the almost continual security problems with IIS, I could not recommend FogBugz to my client, in spite of the fact that it is a superior product. The foundation that it runs on is rotten, and I have little faith in Microsoft to improve this, given their track record to this point. It is my opinion that this is why people don't trust Microsoft with Passport.

Development decisions cannot be divorced from the whole picture.

Wayne Earl
Friday, April 12, 2002

I have to say our adpotion of ASP.NET has been bumpier than the one you describe.  The whole event-driven model seems buggy (controls suddenly stop firing events, etc).

While about half our complaints can be attributed to the learning curve of the framwork (we'll write that off), the other half is that it really seems like ASP.NET, the controls, etc all seem to work intermittently at best, and there isn't an obvious way to troubleshoot or debug these things since no hard "errors" are generated.

Of course, because Microsoft does "generate their own gravity" we will be force-feeding .NET to ourselves untill it works (or we can make it work) and in two years we'll laugh at the trouble we had the same way we now take the the simplicity of the old ADO for granted.

Jason J. Gullickson
Friday, April 12, 2002

"...event-driven model seems buggy (controls suddenly stop firing events, etc)"

Are you sure you aren't basing this of experience with the Beta? I remember the event handlers in ASP.NET "worked themselves loose" now and again - but this was Visual Studio.NET's designers forgetting to "wire up" the handlers sometimes when you had made a change in the HTML designer. As far as I have seen in the released product this seems to have been pretty much solved. And anyway, with practice I'd remember to just go around double-clicking on all of the controls to "rewire" them again.

"...the simplicity of the old ADO..."
I don't understand what everyone finds so difficult about ADO.NET. Previously you had 3 choices with ADO: 1) server-side cursors (dynasets), 2) firehose cursors, and 3) disconnected recordsets. Well now the first choice has gone because it was a bad scalability idea. 2 has become DataReader, and 3 is now the DataAdapter/DataSet pattern.

Rather than get the Recordset do everything, they've refactored it into separate objects.

Duncan Smart
Friday, April 12, 2002

I think .NET penetration will be much quicker than everyone here believes.

If you go to Windows Update (the XP one) it's already there. I was very surprised to see it there already. Surely ALOT of people will download it - especially those with broadband connections.

I also think that it will be part of Windows XP SP1 which will apparently be released in Q3.

Patrick Ansari
Friday, April 12, 2002

Funny that Microsoft finally got around to creating their own NeXTSTEP and WebObjects. Hell, AppleScript can do XML-RPC and SOAP. APPLESCRIPT! :P

I'll continue to sip my hot cup of Cocoa, thankyaverymuch.

Erik J. Barzeski
Friday, April 12, 2002

My company is airing on the side of caution, although we've been really impressed and inspired with the possibilities of .NET.  We have two product lines:  one for Windows and one for web.  We'd love to introduce a unified product line (our XP of sorts).

But we have the obvious concerns of code reuse and whether people will have the framework (market penetration).  We're extremely worried that there's a lot of people still running Win95, which would leave them up a creek (pardon the pun).

As of yet we've adopted the "wait till 75% of people have .NET", but as I keep seeing this among others, I wonder if .NET will roll out slower with everyone waiting for the other to move.  Now I wonder if I should keep waiting or try to be a forerunner.

Joel mentioned that he didn't want to bloat his install by 20MB.  I can understand that, since our entire distribution CD is less than 20MB.  But if you've got the CD space, why not use it?  If you're doing distribution via the web, I believe there's at least a compact framework available.

I know I'm not making a specific point, but I guess that's because I'm starting to reconsider my stance on moving to .NET (to the positive).

Walter Williams
Saturday, April 13, 2002

>We're extremely worried that there's a lot of people still running Win95, which would leave them up a creek (pardon the pun).

That would include me. By choice, I prefer the UI to any of the others so far and haven't run across many programs that simply won't run on win95. I don't get the pun though.

Mark W
Saturday, April 13, 2002

Putting a funny spin on employers....  I will bet within 3 to 6 months you will see many job requirements stating:

"minimum 5 to 7 years experience in .NET"

Hoang Do
Saturday, April 13, 2002

Windows 95 is now officially non-supported, and OEMs are no longer allowed to sell it. I realize that there are still lots of Win95 desktops out there, but with no effective support and no patches, it's going to become a less important platform.

There is a Compact .NET Framework, but it has nothing to do with web distribution - it's a condensed version for PocketPC (Windows CE) devices. Web applications still need the full 20 MB Framework redistributable.

Mike Gunderloy
Saturday, April 13, 2002

I think you guys have failed to account for a net reality: the majority of computer stuff out there is not corporate. Of course I am talking about .net in terms of the web; I do web dev mostly.

PHP was very mainstream for about a year and began being not too much of a surprise for a webapp (at least more common than cf).

Indie crowd seems happy with php. Someone new to the scene will choose either ASP or PHP. If ASP is picked, it'll be .net probably.

Why are a lot of developers using php? Some because they have a irrational avoidance of all things microsoft/corporate. The others because of the abundance of scripts out there [equating with code power]. So php at this points looks like the stronger language - not in potential but in reality.

So here comes .net. Scaled back and simplified structure, but still having to be different enough to account for new functionality. And if I understand it right, a very sweet system for remote coding/apps.

Web developers have two choices then: open source community [a lot of items out there but scattered about] and then .net [promise of a lot of items out there + ms support]. Both are appealing. Depending on how much time the developer wants to put into their app, both have their peaks.

For market acceptance - I am suprised ms didn't start including it awhile back. However, the next time directx or some other major ms product is out, guess what will be tacked on. In a year the majority will have it, but after that it'll be slower. 10% probably really won't get it for 2-3 years if at all, but they'll be experiencing other problems as well by their stubborness not relating to ms probably. Many of the people who will get it will not even realize it.

First it'll be used in an intranet environment or public website. Once that is common enough (a year?) it will be acceptable to start porting.

For now, I think that people who can, should. Those who cannot, should realize that their code won't be their forever (which should  be obvious from the getgo - it'll either be replaced, phased out, or ported).

The situation with .net is the same as with vb6 and what's going on with new web standards. It's not a matter of if, just when and how.

Final cliche: programming is the means of accomplishing your goal. This means a balance between processing speed, scripting time (via creation and update ease), and resources available. Programming is not a religion with one true path - it is a solution. Some people take pleasure from avoiding "corporate hegemony" and great. Others just want to get their objective up there. Trying to declare a universal language at this point is not so good. Some tasks need cars, others trucks. Maybe one day when the earth has an infinite supply of metal and gas and we can go any speed and there are no collisions etc we will all drive SUVs and it won't matter, but for now medium/small business apps use ms and larger scale programs stick with the powerful yet more complex unix evironment.

And thats my final answer [back to trying to get dell to send me a working computer.. never knew their 24hour on-site nexty day warrenty would take 4 months to actually take affect and have them return a call].

leo m
Monday, April 15, 2002

There's nothing wrong with ADO.NET. It's new. Some people are scared by new. When I first looked at it I nearly burst a pancreas, but now it seems very natural, and many parts are quite intuitive and helpful.

As far as penetration and conversion of your tools, I have only this to offer: FogBugz is built for developers, to run on MS servers. The majority of these people will have the .net runtime, so why not port FogBugz. Based on what you said, it sounds like you're going to do it anyway.

As far as CityDesk, well, I would still look at porting it. You don't have mass market penetration at this point, and you have favourable media. I'd say make the switch now, but don't include the runtime as part of your install. Point users to Microsoft's website and offload part of the anguish on them.

But what do I know? Rewrite everything in Fortran.

Geoff Bennett
Monday, April 15, 2002

First I want to say Joel's website is really interesting. There are great articles and intelligent comments and feedback. I're read the online version of Joel's UI book and it is so true. Anyway to answer your .NET questions:

> When will people have the CLR?

When it gets distributed with the O/S, Windows 2004 I guess. (sorry I split the first question into two).

> At what point will it be possible to distribute .NET (Windows Forms) applications to people who are going to download them over modems?

Never, not over a modem. It's bad enough downloading MP3s (not that I ever have:) ). If I had broadband access maybe I would download the 20MB .NET runtime. But that is very expensive in Europe and cable operators are going bust. I think only 1% or 2% of home users use broadband in the UK. Modems cost about a penny a minute, at cheap rate. And 300m of us live here...

> How hard will it be to port VB6 code to VB.NET? Has anyone tried?

You should read Bruce McKinney's comments on VB.NET. He was a VB guru and made some really interesting comments. His conclusion was VB.NET had the same difference from VB as other languages like Delphi, Eiffel etc.

> Has anybody done any significant Windows Forms development in .NET yet? What are your experiences?

No, but I would like to.

One of my concerns with .NET is that you're getting locked into the Microsoft upgrade treadmill. I use C and the Win32 API, and although a fairly basic way of programming, it allows simple effective code and the language doesn't change every 2 years.

I also wonder about the potential runtime complexity. As I understand it, .NET executables use assemblies which are DLLs with versioning information. Windows somehow manages differently named DLLs, DLLs of the same same with different versions and keeps them all separate. Somehow that worries me.

All the best
Bill Rayer

PS: As I type in my name and email, glad to see you follow the recommendations in your own book and use a monospaced font!

Bill Rayer
Monday, April 15, 2002

Since I seem to have picked up a rep as an unofficial VB.NET evangelist (if this corporate web guy gig at Stratagene ever runs out, maybe I should try and get MS to pay me for the job...)...

What I'm doing (noting that all the projects I work on have a development staff that consists of either just me or me and my boss) is
1) All new web projects are done in ASP.NET/VB.NET (for various nit-picky reasons I prefer VB.NET to C#)
2) All old code is staying in ASP/VBScript.
3) When the time comes to do a major refresh of old code (and I consider this inevitable in web projects), migrate it to ASP.NET.

Of course, it helps that we've got a new Win2K server to host the .NET projects on.

Dave Rothgery
Monday, April 15, 2002

>> At what point will it be possible to distribute .NET (Windows Forms) applications to people who are going to download them over modems?

> Never, not over a modem. It's bad enough downloading MP3s (not that I ever have:) ). If I had broadband access maybe I would download the 20MB .NET runtime. But that is very expensive in Europe and cable operators are going bust. I think only 1% or 2% of home users use broadband in the UK. Modems cost about a penny a minute, at cheap rate. And 300m of us live here...

--------------------

I think the question Joel is asking is related to the downloading of *applications* that use the .net runtime. Ie, it's already installed on your machine. The whole concept of the .net runtime allows for the good ol' days of simply dropping an exe on your machine and being able to run it. Hence, if someone has the .net runtime installed on his/her machine, then all the required data access libraries and component framework etc is already installed. All they need is your exe.

It is unfortunate that some telco's in the world charge such phenomenal rates for dial-up access. Here in Australia, I'm with Primus ( www.iprimus.com.au ) on their business plan. I pay $20AUD per month for the connection, and 16c per meg for data. This gives me a permanent dial-up connection, and a static IP. I run a webserver and mail server off it. I am routinely downloading multi-megabyte applications and patches (another Joel topic entirely), and while slow it doesn't cost me that much. I average between $40AUD - $70AUD per month.

Geoff Bennett
Monday, April 15, 2002

Hi there

I have strong feelings about language design, interpreter-type environments, high level languages and costly net access, which is why I'm breaking the habit of a lifetime and getting involved in a discussion. Which is costing me 4p/min by the way from Virgin.net.

In principle I'm in favour of the new .NET languages, and realize I will have to make the move to vb.net or c#.net at some stage, or face early retirement :)

I have some concerns with the complexity of the .NET environment. As you add components and interfaces, the possibility of obscure bugs rises in a squared relationship. Although the idea of interpreters is great (I include JIT executers and anything where your object code does not run on the physical CPU) my experience of dealing with different versions of the Java VM was very negative. I think interpreter-type environments make for hard-to-reproduce errors and subtle incompatibilities. These will be found by my customers, not my testers.

Also the web access element troubles me. I'm a great fan of the US, but I detect technological hubris here. In the US high-speed access may be cheap and real-time radio, TV and .NET downloads are just round the corner. Maybe in the US, but everywhere else it's different. Most countries have telecoms operators that are state owned monopolies. In Europe there has been a flattening off in web use and it is being used more for email or online ordering.

Also, consider well that although broadband is spreading, web access is spreading at a faster rate, so the *average* web access speed is probably staying constant. When 200m Chinese get netted, will they do so via fibre? Or using the existing phone system?

I think .NET will be a success when:
(1) The .NET interpreter (sorry, JIT execution environment) is everywhere, when MS provide it on CD with Windows 2004 or whatever, and...
(2) MS rewrite Office using it. Nothing like using your own dev tools, is there?

Also I think C# is the way to go. At least this is standardized, so you're not on the MS upgrade treadmill!

Regards
Bill Rayer

Bill Rayer
Tuesday, April 16, 2002

One thing I noticed, regarding CLR adoption, is that I was given the CLR as a download choice last time I went to Windows Update - Product Updates.  I don't know if that was because I already had it installed, but the decription made it look like generally-available software.

If MS pushes the CLR through Windows Update, and if people are willing to take it, adoption could be a lot sooner than otherwise.  (Unless Windows Update gets regulated out of existence... ;)

M. Hedlund
Tuesday, April 16, 2002

>The whole concept of the .net runtime allows for the
>good ol' days of simply dropping an exe on your
>machine and being able to run it.

Must....bite....tongue!

Sonny
Wednesday, April 17, 2002

Last out turn out the lights....
Hope I didn't frighten people off!

Bill Rayer
Friday, April 19, 2002

Sonny said:

>>The whole concept of the .net runtime allows for the
>>good ol' days of simply dropping an exe on your
>>machine and being able to run it.

>Must....bite....tongue!

Seriously? Have you had any trouble with it? So far it's worked as promised for me. Admittedly, it's only been between a handfull of machines, but I'm yet to trip up on it.

Of course, it doesn't guarantee that sql server is installed if you need it, but for a basic windows app, no problemo. An exe, a couple of dll's and away you go.

Geoff Bennett
Saturday, April 20, 2002

>Seriously? Have you had any trouble with it?

No, it was a poor attempt at humor referencing to the fact that people here are heralding the "I only need the EXE" concept as some kind of technical nirvana.  With my current tool of choice (and fortunately my corporation's current tool of choice) I've been enjoying this nirvana since the product's inception.

I won't mention that tool lest I be accused of being a religious fanatic.  We have over a dozen major systems in production here and 100% of them were delivered on time and under budget, yet in one thread I was labelled a detriment to my employer.  Glad I don't work in that guy's organization.

I haven't played with .Net yet but I'm looking forward to learning C##.  I have high hopes for the product knowing that Anders was the lead architecht.  The CLR will become a non-issue as Microsoft starts rolling it out in XP service packs and future release of their OS.

Sonny
Saturday, April 20, 2002

>With my current tool of choice (and fortunately my
>corporation's current tool of choice) I've been
>enjoying this nirvana since the product's inception.

>I won't mention that tool lest I be accused of
>being a religious fanatic.

I'm going to go out on a (potentially suicidal) limb and imagine it's the 'D' word. That was the language I used in my first professional position, and I still use it today.

Although, for the last few years, I have been more or less full time with VB/ASP/COM etc. From the point-of-view of a VB'er, this sort of architecture is a welcome relief.

I can't count the number of times another application install has blown up my app due to DLL version mismatches, etc. Not to mention the bloated exe size (compared to other languages), and requirement of runtime distribution.

I know that last point seems unusual under the present context, but the entire idea with the .net runtime is *everyone* should have it in the end, so you should not need to distrubute it. Whether 100% penetration will be achieved is a topic for another discussion. This brings us back to finally having the ability, with MS RAD tools -- I know C/C++ have been able to do it for a while, to have what's tantamount to an exe-drop installation.

Of course, as time goes by, it won't be quite that simple.

Geoff Bennett
Monday, April 22, 2002

Has someone been taking drugs?
Of course this current clr won't be the
great last and only version of CLR to come out.
There'll be more by and by and the fun will continue.

gb
Tuesday, April 23, 2002

As a Unix/Linux/PHP/Apache developer, I thought I could bring another perspective to bear on the discussion.  I am a regular reader of Joel's column, and by and large he has valid things to say.  However, in the discussion forums I almost feel like I'm watching the Ozarks Intra-Family Dating Game.

None of you guys seem to think there's a world outside of Microsoft, when (a) most of the web runs on Unix and open-source software, (b) eWeek labs has just tested Apache 2.0 for Windows and found performance to be identical (sans the security problems), (c) corporate America is paying attention to the steady parade of security holes in IE and IE's security patches, and (d) Microsoft hasn't really conquered anything but the desktop.

.NET may actually be the greatest thing since canned beer.  I don't know.  I do know that I've heard similar hype for tools for decades, and the reality has always fallen short of the hype.  One set of problems gets solved, and another one gets created. (I've been doing software for a living since 1980, and as a hobby before that.)
The biggest downside I see for .NET (given my paltry knowledge) is that the CLR is Windows-locked.  If your bread and butter depends on knowing how to work around the idiosyncrasies and sloppy QA that Microsoft is notorious for, then I can see how you'd be happy about it.  But what happens when you want to work for a client whose entire platform is Unix/Linux and they aren't about to change it on your say-so?  If your entire web services universe begins and ends at the Redmond campus, you're not going to get that job.

As I said before, I've been around a long time.  No matter how much of a mental stiffy it gives Ballmer, Valentine, Allchin, and company to think so it's never going to be a homogenous Windows world.  The smart play is to be able to work across multiple platforms *without* having to port a framework, and I don't see that from .Net (so far).

All right, let the flaming begin!    ;-)

Chris Woodard
Thursday, April 25, 2002

No flaming, just a few points. Many of the regulars on this forum have been around for twenty years or more, and many of us are familiary with open-source and Linux (of course, not all open-source projects are Linux-based, and not all Linux development is open source).

The fact that tools do not supply magic bullets to make creating software easier is well-known to anyone who's read Fred Brooks' 1986 essay "No Silver Bullet".

There are already projects out there to recreate the .NET CLR on other platforms. Microsoft's own shared-source  "Rotor" implementation already runs on FreeBSD. And there's the open-source "Mono" project trying to bring it to Linux, which the last I'd heard was at the point of bootstrapping its own C# compiler.

Of course how well these projects succeed remains to be seen. But one of the nice things about the "Web Services" universe is that it is NOT exclusive to Redmond. You can right now, today, using existying tools, mix and match Web Services that are written using .NET and J2EE, for example.  Of course Web Services only cover a small part of what you can build with .NET.

Finally, I can't speak for anyone else, but I find enough clients who want Windows-based work to stay busy. I'd worry more about moving skills to the LAMP collection of applications if I was starving. And of course the other factor is that if I ever need to, I can pick up skills in those applications pretty quickly -- just as I'd expect you, with 20+ years of experience, to be able to learn Visual Studio .NET if one of your clients demanded work in C#.

Mike Gunderloy
Sunday, April 28, 2002

>Has someone been taking drugs?
>Of course this current clr won't be the
>great last and only version of CLR to come out.
>There'll be more by and by and the fun will continue.

No one here has every said anything different. To quote the last line in my previous message:

> Of course, as time goes by, it won't be quite
> that simple.

But, if .NET heads in the direction it appears to be, that will be no more of an issue than writing software to run across Win95/98/NT/2k/XP.

None of the API's on any of those platforms are identical. Sure, for the main part they're similar, but there are functions in each that you can't call on the other.

For instance, I can write an exe that calls in to the Win2k performance monitoring software. But that exe wont run on Win95. That's just the way it is, baby.

MS may repair breakages in the CLR, but that shouldn't (note: shouldn't) mean altering the interface. They may add newer functionality that doesn't currently exist -- much like parts of Win32 on 2k/XP that are there on Win98 -- but you just have to deal with that.

It is still a lot simpler than dozens of different OCXs, and forcing MDAC onto different platforms etc.

If the CLR is there, you can assume a certain amount of base functionality. If *you* step outside those boundaries, then you should be well prepared for what you have to deal with.

Geoff Bennett
Thursday, May 02, 2002

[OK, I admit it -- .NET violated the Never Rewrite From Scratch rule.]

Actually, they didn't, really.  Saying MS rewrote from scratch is sorta like saying Sun rewrote C++ (see #1, below).  There are two very simple things to remember that makes what MS did with .NET different from what Netscape did with Navigator:

1.)  MS is big enough to include more than "one company".  Visual Basic 6 didn't become mired in the dirt while C# was created (which did, like it or not, come before VB.NET was lain overtop).  They had the resources to continue to support the old while having "another company" write something new.  Netscape didn't have the resources to "compete with itself and win".  To think of MS as one company is a mistake.

2.)  MS [arguably] has a monopoly over desktop users, and that means desktop developers as well.  Monopolies can do these kinds of things.  Apple has a monopoly of a different sort over those weirdo blokes who "think different".  Apple also managed to rewrite from scratch and, though they didn't do their OS any favors, didn't lose market share and came out with a much better product.

The key to rewriting from scratch being a killer move is if you are predominantly a one-trick pony.  To mangle a metaphor beyond death, if you want to put your eggs into two baskets, make sure you have enough chickens to keep both baskets full.

Rufwork
Friday, July 26, 2002

OK - I know you used to think .NET was(is?) vaporware. What happened to that POV? I agree with almost all your views, pragmatic as they are, but this would have been a tough one to swallow, wouldnt it? :)

Vivek Anand
Wednesday, January 29, 2003

thanks!

ff
Wednesday, February 26, 2003

Hi all.
Sorry i'll be a little rude but... quanno ce vo ce vo (when is too much is too much).

Is one year and half i'm working with asp.net in c#. While i think that the .Net framework is great, ADO.net is ok (i've programmed once then with the class i've made i've done all of my stuff), c# is the best language i've worked with (i'm an heavy class builder and i love the beauty of inheritance) well... hem... ASP.NET SUCKS A LOT.
ok
I motivate the thing.

1) there is a general smoke about "you can build web apps in no time using the stunning web controls provided by MS (and not to mention all the ones you can create on your own)"
Ok... are 4 years i heavily program webbapps. I've been part of a team that produced a mastodontic eLearning app (1500 asp pages,150 tables in the db, countless stored pro) and i my opinion is that as long as:

- if you have no experience is web applications or
- you like to produce apps that allows users to interact with a single table of a DB yes...but keeping loading and reloading and reloading pages after pages because is so or
- if DHTML is a funny useless thing of the past and Flash is a nice apostrophe between the words "<body>" and "<form>" and "user interface" is something that has nothing to do with the web development or
- yes ,you have made a load of apps in the past but for some strange reason you don't ever reused a piece of your code or
- History is ended and the way we make web application with it

the assertion is true. ASP.NET is great.
Beatuful to make Macdonalds style web applications (and i know how much guys dreamed about it).

2)Another smoke. "Is faster than anything else thanks to the compiled code"...well...I know out there a lot of people loves fast stuff. Yeah. Lots of nerds too. But actually... between the last two apps i've made (one in .NET and one in PHP) i dunno wich one is the fastest... i mean... both of  them i don't think will be used by more than 1000 users in the same time (Hey, i'm not programming Yahoo...and even Yahoo uses VB or C or C++ or JAVA libraries behind for make things faster). So... ok... is faster than anything else ...thanks a lot Bill.

3)This is not a smoke... but is generally intended that ASP.NET allows to make stuff a little better than ASP does.
A simple example:
Because my Interface analyst is a bit naif, he asks me to use a combo box instead of the radio buttons if the available choices are more than 10.
No problems I say (actually in both languages).
But at the end comes out that the form must be embedded inside the ASPGrid that shows the data and that the content and the type of the controls must vary depending on the data in the recordset. No problems, you can say. Use a ITemplate or use onDataBind event to attach the right control inside the cell. ERROR!! the control will not work properly. This was a normal issue in ASP. Why .NET fails so badly?
The evangelist i posed this question replied me in this funny way, with a so emphatic face that i wandered to cry.
"The event model is just simulated in asp.net. If you fail to put the right things in the right moments (aka events) some things will not work as expected."
I ask wishful "So, what must be done, when?". He admitted that he don't know. His final consideration was:"Yes probably if you know perfectly all the System.web.UI classes and childs and all the event model, you can make things better than ASP". Oh gosh...as usually I am the problem....i know... i'm inadeguate....

4)Browser compatibility...
a) Is NS7.1 a browser with such a pour Javascript engine that does not deserve having dhtml enabled controls? (Guys... who write the javascript for MS?)
b) In times where the 90% of clients runs IE5.5/6/6.1 on Windows 98 and up, was not possible to put some more dynamic "pepper" in the user interface?...

I'll jump over that ".NET will soon run on all platforms rumor of 3 years ago?" Ok, i'll jump over...

... till the final considerations:

As long as costumers will ask me ASP.NET i'll give them .NET stuff (that has the good thing that is really reusable)
And as long as i've a bunch of syuff made already with .net i'll use that...

But..in my opinion, half of the things told by MS Marcheting propaganda is pure bullshit.

ALb
Monday, August 04, 2003

*  Recent Topics

*  Fog Creek Home