Benefits of .Net?

[Optikal]

At my work, all our development is done currently in VB6 in a client/server architecture using fat clients and an Oracle database server. I want to put together a business case document, that looks at switching our development to .Net. But I'm having a hard time brainstorming benefits that actually have an impact. About the only one I've come up with so far is increased productivity due to the VS IDE enhancements.

 

The problem is, alot of the issues we have that .Net solves nicely, we've already invested time to come up with a custom solution in VB6. For example, deployment in .Net is much better than VB6, but we already have a custom deployment framework in place, that we spent a considerable amount of time developing, and hence deployment for us is extremely easy using our custom framework (all we do is copy the exe to a fileshare and it automatically propagates to all clients as they need it). So I don't know if I could spin the deployment features of .Net as a benefit to us.

 

Was hoping some of you that have made the switch to .Net could help me brainstorm some benefits that will actually help me persuade management that we should make the switch.

[Merrion]

In addition to Microsofts 10 reaons I would add that the tracing and debugging capabilities of .NET are so much better than VB6 as to be incomparable.

[Optikal]

Thanks for the link, it was helpful. But it mostly still leaves me with the same problem. Most of the stuff on that list is either stuff that I can already do in VB6, or its productivity/IDE enhancements. I'll try and go through the list:

 

1) Deployment - already have a custom VB6 system in place. This would have been nice to have 5 years ago, but now that we have a system in place the benefit is moot.

 

2) Robust Code - stict type checking is the only concrete benefit from this point. The todo list falls under IDE/productivity enhancement, and structured exception handling is nice, but doesn't allow us to do anything we couldn't do in VB6 (albeit, the syntax is much nicer).

 

3) Powerful Windows Apps - everything listed here is available in VB6, with the exception of controls docking which I will include in my business case document as its something we've wanted for a long time

 

4) ADO.Net - this doesn't allow us to do anything we can't do with ADO 2.x, the syntax is just nicer

 

5) Simplified Component Creation - Nothing we couldn't do in VB6.

 

6) Enhanced Control Creation - not something we do alot of here, so doesn't really apply.

 

7) .Net Framework - can do all this stuff in VB6, the framework just provides nicer syntax (ie. better productivity)

 

8) Integrated Crystal Reports - We already use CR 8.5 with VB6, and we can already design reports in the VB6 IDE via the CR designer, so nothing new

 

9) ASP.Net - I agree this is a HUGE advancement over the old ASP. But we do all fat-client development here, so this doesn't apply (however I may make a separate business case looking at changing our architecture to ASP.Net instead of fat client).

 

10) Existing Investments Carry Forward - Not really a benefit, just risk mitigation.

 

 

So after these 10 points I'm still left with just the following benefits:

 

- Improved IDE and language features leads to increased developer productivity

- Control docking allows automatic form resizing

- Stict type checking assists in creating more robust code

 

The productivity benefit is probably the most substantial out of those, the other 2 seem minor. I don't think these are enough benefits yet to make a business case for migrating to .Net.

 

More input from anybody would be highly appreciated.

[Optikal]

I believe another benefit would be decreased memory consumption of the clients. I would have to do some testing to verify this, but I suspect since the overhead of COM is gone, the memory usage *should* be lower in .Net. We currently have problems with the insanely high memory usage of VB6 clients.

[Derek Stone]

The next version of Windows ("Longhorn") is going to be built with a managed (.NET) API. Not switching would be a poor business decision altogether at this point.

[Optikal]

Well longhorn doesn't come out until 2006 at the earliest, and considering the majority of our clients are running Win95 (I just realized I don't even know if the CLR will run on 95), I don't think theres any chance of us going to Longhorn until 2010 or so.

[Derek Stone]

The CLR does not run on Windows 95. You're out of luck there.

[Optikal]

well, I believe our ops guys are in the process of upgrading our clients to Win2000 (though this will probably take a LONG time). But lets assume that all our clients are running Win2k+, and continue this discussion, because I'm still interested in trying to make a business case out of this.

[Derek Stone]

Is you build process automated? Do you perform unit testing? Do you plan on supporting remote clients behind firewalls?

 

All things made easier with .NET.

 

NAnt

NUnit

Web services

[Optikal]

No, No, and No (however we do support offline clients, and its a huge pain in the butt). I will definately look into those on the weekend. Very good ideas. Thanks.

[Banjo]

Incidentally, Derek, do you know if Longhorn will support existing VB6/API programs or is it going to be purely .Net?

[divil]

It will be fully backwards compatible. Look at recent versions of Windows, which still support running Win16 programs. Microsoft can't affort not to include that compatibility.

 

The only issue that'll come up with Longhorn is the new apis. All future additions to the api (this excludes fixes obviously) will be under WinFX, not the win32 api.

 

Programs that interact with the shell might break since it's been completely rewritten in managed code, but then again, they might have made that backwards compatible too.

[AFterlife]

Dont forget its ease of OOP. With inheritance and delegates. This stuff was all a terror in VB6. VB.NEt is by far a superiour language. Dont forget polymorphism. Edited December 21, 2003 by AFterlife

[Optikal]

Afterlife, OOP is great and I love it, but its not a business benefit. I have to focus on what types of things will this great new OOP capability allow us to do that we couldn't previously do, and thats worth investing $500,000 to get.

[dragon4spy]

VB.net also support the stable version of Multi-Threading, but not in vb6 which is not so practical to use.

[dragon4spy]

Look! Most of vb6 guru are newcomer and freshman like me! :)

[dragon4spy]

Can vb.net compiles to machine code like vb6? Since JIT codes are easy to decompile back to its original source code.

[Derek Stone]

Yes it can be, but please start a new thread to discuss it. Let's try to keep this one focused to Optikal's question.

[samsmithnz]

As a developer who is currently moving our in house development team to .NET I can give a couple of examples of areas that have significant improvements over VB6. These alone were enough to convince the other developers in a presentation last week that its the right direction. If you have the VS.NET 2003 I can even send you the example with these features:

 

-Email: In about 5 lines of codeI can send an email now, on any STMP server I want.

-Event Logging: 3 lines of code is all i need, and I can even create custom event logs, a feature I was not aware of..

-Colors/Style: Its much easier to customise the look and feel of applications now, so that they look better. In VB6 you are really stuck with that grey business app look.

-Registry access: 3 lines of code now.

-Menus: MUCH better than before.

-Multithreading: YAH!

-Inheirtance: Useful to some.

 

Not to mention I think that our projects are cleaner, easier to maintain, quicker to develop, and I think they execute quicker too.

 

Their are of course negatives, the biggest I think is the learning curve, plenty of VB6 developers struggle at first to understand where to start!

 

good luck.

[Optikal]

All good points, but alot of them I don't think I could use.

 

Email - we already have a custom component that allows us to send email, so we only need a few lines of code currently.

 

Event Logging - not somthing we've ever used

 

Colors/Style - good if your developing commercial software, but I doubt we'd want to create flashy apps here

 

Registry - again, we have a custom component that wraps this functionality up and makes it available with minimal coding

 

Menus - can you elaborate a bit on this. I know I like the in-form designer better than VB6, but I don't know much else about differences.

 

Multithreading - thats a good one, I can think of quite a few instances where multithreading would be nice

 

Inheritance - not a business benefit, just a nicety for programmers

 

 

Good input though, keep it coming :).

[samsmithnz]

We all have modules to do email and registry access, but for new apps it really cuts down on code, and makes it all look a lot better.

 

What about the new project types? You can create Windows Services easily in VB.NET now. And web services!?! We're about to use a web service to download the currency conversion rates, instead of getting an email and inputting it manually everyday!

[Merrion]

UI Regionalisation is better in .NET too - you set the property on your form and it goes off and makes the resource file for you.

[samsmithnz]

Hey and internationalisation is a lot easier too.

[bri189a]

I don't have page 2 of this post...dead link, so maybe this was already mentioned... you said ADO 2.X can do anything ADO.NET can do... I know people who would argue otherwise... I'm not as experienced as them but back when I thought VB6 was awesome... before I came to the light of C#.NET, and had to use ADO 2.X looking at ADO.NET seemed basically the same... but now after working with ADO.NET several times I love it's ease of use. Disconnected Data-Set's.... DataReaders... both great things that yes... with a good coder possible to do something similiar in ADO 2.X, but very sloppy in comparrision, and much more resource intensive mainly because ADO 2.X wasn't designed to do those things. Some of the more experienced at both may speak up to enlighten you more.... Personally if it were me, if the company I worked for didn't want to go .NET, I'd change jobs... narrowminded suits with that kind of attitude is why Xerox didn't make a fortune off of the mouse.