Fog Creek Software
Discussion Board

Welcome! and rules

Joel on Software

Just to make sure

I understand things correctly : While .Net adds a few features that VB users might want, the whole .Net thing doesn't offer much to current VB users...

- this,
- the fact that current "legacy" VB code needs to be rewritten,
- WinForms require a 20-MB runtime ("framework"), the markert share and,
- due to the poor client interface that are web browsers in 2002, the great majority of applications are _not_ web-based but rather dedicated applications...

why on earth did Microsoft make the decision of putting an end to its current development tools and force _everyone_ to move to .Net when web-based applications only represent a tiny percentage of applications?

I just don't get it. Could a kind soul tell me if I forgot something important that would make sense of the usefulness of .Net for legacy apps?


Frederic Faure
Monday, November 18, 2002

Well, I was a current VB user. Now I'm a VB .NET (and C#) user. The .NET Framework and Visual Studio .NET are so much more productive than VB6 that I hope never to go back.

I'm fortunate that I didn't have to drag any VB6 code forward; I'm still doing VB6 mintainence. But VB .NET is where I am for new products. The runtime requirement is a problem, but only if you're focused on download distribution. In a year or two, we won't worry about it any more than we currently worry about the VB6 runtime -- and if you go far enough back, you'll remember the pain we all had with THAT massive runtime at the download speeds of the time.

As for browsers - browser-based applications are only one small part of what .NET is about. You don't like the browser interface, don't use it.

Mike Gunderloy
Monday, November 18, 2002

As a former VB developers, what are the goodies that make it worth to move to VB.Net? Would you recommend going all the way, and moving to C# instead of VB.Net?


Frederic Faure
Monday, November 18, 2002

There's no reason to think VB.NET is going to go away (except in the minds of some paranoid disgruntled VB6 developers), or that it will stop being a full-featured OO language, so unless you're a C/C++ expatriate who wants to go back or you have a real need for something that's not in VB.NET (primarily bitshifiting, unsafe code, and operator overloading), I don't see any reason for someone whose primary experience is with VB to use C# over VB.NET.

Dave Rothgery
Monday, November 18, 2002

Dave, as "someone whose primary experience is with VB," I'll tell you my main reason for learning C# instead of VB.NET:  I wanted to move away from VB syntax and get more used to looking at a terse, curly-brace language, so when I have to sit down and write JavaScript or whatever else, I may still not know the specific quirks of the language, but it at least won't look like gibberish anymore.  ;>

Monday, November 18, 2002

Off the top of my head, a few things I like about using .NET instead of VB6:

1) More powerful IDE with better integration of other tools (including the availability of good unit-testing frameworks).
2) The .NET Framework classes, which save me a bazillion lines of code.
3) ASP.NET for compiled Web applications.
4) Easy support for Web services.
5) UI tools that make it a snap to put together data-backed applications.

I'm sure I could extend the list indefinitely.

VB.NET vs C#: Except for a very few features, the two are isomorphic. I don't see a particular advantage to one over the other, and in fact I move back and forth frequently depending on the project. With a bit of experience it's trivial to translate C# code to VB .NET or vice versa.

Mike Gunderloy
Monday, November 18, 2002

"why on earth did Microsoft make the decision of putting an end to its current development tools and force _everyone_ to move to .Net when web-based applications only represent a tiny percentage of applications?"

IMO, Microsoft is pushing .NET in order to abstract away the application programming interface (API) for *both* web and compiled apps.  This would allow them to do several things:

- Rewrite/refactor the guts of the Windows OS without breaking existing applications. 
As long as the .NET objects and interfaces stay constant, Microsoft can do whatever they want behind the scenes. 

Testimony in the anti-trust trial showed that the current Windows code base is a house of cards.  Executives had to admit that they can't remove components (IE, Windows Messanger, etc.) because they can't guarantee the OS will still work.  Windows code needs a SERIOUS overhaul.

- Provide an API that is object-oriented.
This creates a more logical framework for adding functionality as new technologies/needs arise.

- Create an API that is OS-independent.
In theory .NET apps can run on any OS that the .NET framework has been ported to.  I don't see this happening, but their marketing and legal departments can pay it lip service.

It's both a pragmatic move on Microsoft's part and an upgrade to the tool(s); they just emphasize the bells and whistles they put in for the developers.

Joe Paradise
Monday, November 18, 2002

>>> - Create an API that is OS-independent.
In theory .NET apps can run on any OS that the .NET framework has been ported to.  I don't see this happening, but their marketing and legal departments can pay it lip service. <<<

Actually, MS Research just released Rotor 1.0 - an implementation of the CLR that runs on Windows, one of the BSDs, and MacOS X. And I have written (admittedly simple) .NET apps under the desktop .NET and run it under Rotor. What's missing in Rotor is some of the more specialized libraries (WinForms being the most obvious example).

So it's not as vapor as you might think.

Chris Tavares
Monday, November 18, 2002

As Mike and others mentioned, the BCL (Base Class Library) is reason enough to move from VB6 to VB.NET (or any .NET language).

Things like socket programming, threading and creating Windows Services were next to impossible in VB6, but classes in the BCL now make it possible.

Remoting is a much better solution than DCOM.  It allows communication over HTTP, something that DCOM has had trouble with.  Instead of having to open various ports up on a company firewall, you can allow traffic to use port 80 instead.

Windows Forms, is an object oriented, easily extendable way of creating rich client applications.

Having trouble with the registry of COM components?  Private assemblies (the default) allow for a much easier versioning strategy in .NET, meant to clean up "DLL Hell".

Guy Incognito
Monday, November 18, 2002

Thx much everyone for sharing your knowledge on what .Net is and the reasons for moving from VB.

A couple of things that surprise me:

- why did it take so long for MS development & marketing teams to give a clear, concise explanation of what .Net is all about?

- why the emphasis on .Net's capability in building web applications and services more easily than with current tools, considering that, since the browser is such a poor client interface, web applications represent only a tiny part of the number of projets that developers work on using Microsoft tools?

Here's how I woul sum things up:

- .Net is a 20Meg run-time with lots of code; The framework must be installed on all hosts that run .Net applications, ie. it must be installed on a web server when using web-based applications (a.k.a. WebForms), and on all client hosts when supplying dedicated applications (a.k.a. WinForms)

- The framework's goal is to save developer time by providing a lot of routines, especially when used through the VS.Net IDE. It is, however, possible to build .Net applications using your favorite editor

Another goal is to isolate developers from the underlying OS and its API's by abstracting that deeper layer, making it OO, and compiling code into byte-code (MSIL) which is turned into binary code by a compiler called CLR.

Any language that outputs byte-code in MSIL format can be compiled by the CLR; IOW, a .Net-based program can run, unchanged, on any platform that has a .Net framework (For instance, the .Net framework as ported on the FreeBSD platform is called Rotot.) MS intends to offer up to 27 languages, but currently, only VB.Net and C# are supported, with Perl and other main-stream languages in the works

- VB.Net provides VB developers with an enhanced version of VB (OOP). Unfortunately, VB code will usually requires some rewrite to run in a .Net environment

- ASP.Net is a sub-set of the .Net architecture which makes it easier to build Web applications and services (SOAP)


Frederic Faure.
Wednesday, November 20, 2002

A couple of points:

1) Although MSIL will run on any platform that supports a CLR implementation, this does not necessarily make .NET applications portable. That's because there's no guarantee that the whole Framework will be available on the target platform.

2) There are many more languages than VB and C# that can build .NET applications today. Microsoft also includes C++ and J# in the box. ActiveState is shipping Perl and Python for .NET already. Haskell, Cobol, Fortran...they're out there already.

3) "Web Applications" encompasses much more than browser-based user interfaces. Web Services, for example, can use a Windows Form client just as well as a browser-based client.

Mike Gunderloy
Wednesday, November 20, 2002

It's true that web services can be called from dedicated applications, although they're basically revamped RPC.

BTW, is Rotor available for other *nix platforms besides FreeBSD?


Frederic Faure.
Wednesday, November 20, 2002

Rotor runs on WinXP, FreeBSD, and Mac OS X -

The licensing requirements are somewhat problematic, though. For cross-platform .NET I'd keep more of an eye on Mono.

Mike Gunderloy
Wednesday, November 20, 2002

*  Recent Topics

*  Fog Creek Home