Benefits of .Net?

O

Optikal

Regular
Joined
Oct 8, 2002
Messages
67
Location
Canada
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.
 
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.
 
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.
 
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.
 
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.
 
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.
 
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.
 
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.
 
Last edited:
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.
 
Can vb.net compiles to machine code like vb6? Since JIT codes are easy to decompile back to its original source code.
 
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.
 
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 :).
 
Back
Top