Move to .NET from Visual Studio 6?

[JoshLindenmuth]

We're embarking on a long-term (2 year) development effort for a distributed client/server application (our clients are worried about security and data entry speed, so we're not focused on a web product yet). A few of my developers have been pushing for .NET instead of the Visual Studio 6 that we're using now. I have a couple questions regarding the migration:

 

Are there any disadvantages to migrating?

 

Are there significant enough advantages to justify the cost (we have a very limited IT budget)?

 

We'd like to keep all of our server-side code as straight C or C++ to ensure that we can leverage the same code on any O/S (e.g. Linux) if we move to the web. Will .NET inhibit our cross-platform options?

 

Many thanks in advance,

Josh Lindenmuth

jlindenmuth@paytimepayroll.com

http://www.paytimepayroll.com

[kejpa]

Are there significant enough advantages to justify the cost (we have a very limited IT budget)?

 

Microsoft is stopping support and updates pretty soon (compared to your estimated development schedule) at least that is reason enough for us to move from a stable VB6 C/S project to a complete rebuild in .NET

 

Good luck

/Kejpa

[Nerseus]

As a note, a little over 2 years ago my company embarked on its 2 year project (our "final QA" move is next week with a live date of Jan 2). We faced one of three options:

1. Stick with Visual Studio 6 (mostly VB6 and ASP)

2. Move to .NET WinForms

3. Move to .NET WebForms

 

We had about 20 employees but knew we'd need to grow to about 50 before project end (we're now at about 60). Our 10 core developers (at the time) new VB, COM+ and ASP inside and out. Half the team had worked *for* Microsoft so we had a pretty good team to start with (mostly senior level developers).

 

We did 3 months of testing in .NET WebForms and switched to .NET WinForms based on UI functionality. Aside from the typical 3rd party product hassles, the project couldn't have gone smoother! We've delivered on time and under budget and every review has been fantastic. We do have a few hundred thousand lines of code in ASP.NET as well (web services serve all the client code and web pages handle the majority of reports and some functionality for clients of our client).

 

It did take us over a year before our "framework" was back up to speed with what we had developed in VB6 (utility functions and misc "tricks"). The tricks your team knows WILL mostly get thrown out the window if you switch to managed code but if you've got a good team and they're willing to do a lot of "catching up" to learn .NET, I think you'd do well to switch.

 

The system we were replacing was a mainframe based client/server architecture. They got results fast, but had a lot of knowledge wrapped up only in user's brains and special "codes" that they learned over time. Our new system is *very* robust and handles about 80% of what used to be the special codes.

 

I couldn't be happier with .NET WinForms except in ONE area: the performance of the UI code and binding is a bit slow on very large forms when you hook a lot of events. Part of our problem was our architecture of using .NET's robust event management to handle the business rules, validation, and more. What we ended up with was 4 or 5 "generic" pieces of code that would each hook events to either every control or every table in a DataSet. Anytime you change one value on the screen, a cascade of events would fire that sometimes takes as long as 5 seconds to update (in an extreme case). Personally, I hate waiting more than a quarter second when tabbing out of a field. Luckily, we've had time to do some performance testing and MS has even volunteered to let us use their test center in Texas. I doubt we'll have time to make any corrections before the Jan 2 live date, but the next project will surely benefit from the knowledge we gained.

 

As a side note: All of our developers decided it would be best to switch from VB to C#. We made that decision for two reasons: the transition to VB.NET from VB6 seemed like more than just VB5 to VB6 (and it is!) and also, most of our developers were already very good at java and javascript so the C# syntax wasn't that new. Given the amount of sample code AND the perceived idea that MS was really pushing C# over VB.NET, it wasn't that hard of a decision.

 

Along those lines, C# presented its own set of problems. Notably, many of the new development staff new Java but not C# (not very well anyway). Many of the Java habits didn't carryover very well and we spent an extra amount of time with each new developer to "untrain" them in the Java way of doing things (such as using == instead of .Equals). If you stick with VB.NET you'll probably have similar code reviews where one developer insists on using CType while everyone else says using System.Convert. Locations may change, developers mostly stay the same.

 

-ner

Edited September 1, 2004 by Nerseus

[JoshLindenmuth]

Wow, thanks for the great reply. We currently have everything in VC6, so it sounds like moving to VC .NET shouldn't be a problem. I'm a bit concerned about your statement that changing a value on the screen could result in a 5 second update. We are using this application for VERY time sensitive data entry. Tabbing between fields must not take longer than 1/5th of a second (data entry personel are typing at ~3-5 characters/second). Will this be a problem with .NET?

 

Thanks again,

Josh Lindenmuth

jlindenmuth@paytimepayroll.com

http://www.paytimepayroll.com

[samsmithnz]

I don't have as much time to reply as Nerseus, but we have switched to .NET and have never looked back. Its more powerful, I'm more productive and my code is more robust.

[Denaes]

I'm a bit concerned about your statement that changing a value on the screen could result in a 5 second update. We are using this application for VERY time sensitive data entry. Tabbing between fields must not take longer than 1/5th of a second (data entry personel are typing at ~3-5 characters/second). Will this be a problem with .NET?

He said that they'd used some dynamic routine that looped through each Table in the DB or every control. This was probobly done so that they can reuse this code with EVERY data validation form needed... it also meant that it didn't do things optimally to a certain situation, instead doing everything with every change.

 

5 seconds was what he said was extreme. I've seen update times longer than that using terminals and normal dataentry apps in C.

 

It'll take longer, but you can custom create validation for every control on a form, specific to it. It'll take more planning up front and the code will be longer - but you won't have to worry about any binding or dynamics. you just check the data and move along.

 

I did a smaller data entry application in vb.net and I'd have like a half second delay when a form was first used (maybe a second if a database was being querried - I used access and XML). After the first time a form was opened it opened and closed instantly.

 

I had validation on each data control on multiple pages and while it meant I had a lot of procedures for validation, it doesn't slow down the program at all.

 

Even as Nerseus says, this is their dry run. They're getting assistance and will improve their code.

 

When you're learning any language (within 5 yrs... maybe longer) you'll wrap up the application and say to yourself "well, with what I've learned if I had to do it over, I could do it in 1/5th the time or optimize it 20%" and thats why there are many versions of software. We keep improving.

[JoshLindenmuth]

OK, you guys convinced me. I just ordered .NET for the team, thanks for your help!

 

Josh Lindenmuth

jlindenmuth@paytimepayroll.com

http://www.paytimepayroll.com

[VBAHole22]

Good move. Now all you need to decide is what incarnation to make your application. We had to devise an application that could concievably be in any of the major flavors:

 

Web Service

Web form

Win Form

Win Service

 

At this point we have tried them ALL! Switching from web services to web pages is very simple and that is part of the reason we tested that move out.

 

The biggest issues we have, and the cause of all this movement, are file permissions and threading. We are programming against a third party COM component (ArcObjects). It's single threaded so when we use it in a web service we can't access network resources with it. We can do this in web pages but only with the aspCompat=true trick (Nerseus is absolutely right on about the importance of having trickster working for you).

But web pages get hung up if you call a long function. Well the answer to that is to put the function on a thread. Well the thread you spawn doesn't have the same credentials as the source page so you are screwed there as well.

 

This is just our scenario but it's something to think about as well.

[Nerseus]

@VBAHole: There are many tricks to letting long running webservers let others in. We have a number of 3rd party plugins that we have to "work around" for smaller clients. Namely, reports that print on server-based printers use 3rd party controls that are NOT web friendly for the most part. Ideally we use a separate print server but smaller clients need a single web/print server and we use separate AppDomains with success.

 

As for long wait times, the 5 seconds was extreme (I can only think of one remaining example that takes that long). It's mostly due to our many, many events that we hook and our use of a custom XML-based rules engine for data validation (more events) and databinding and 3rd party controls (custom paint events for error icons and such plus hierarchical grids)...

 

99% of the time a user will notice 0 delay when tabbing from field to field. Our users our *amazed* at the amount of "stuff" that we do for them behind the scenes, such as re-running fee rules and the multitude of cascades that happen as they change a single field.

 

We use the term "cow path" to describe what 90% of the users do 80% of the time. We build special logic in those areas to make sure their experience is the fastest. The other 15-20% of the things they do they won't mind waiting for a quarter to half second to leave one field to the next. *Nothing* happens on a per-keystroke level.

 

As some more info: I've developed many, many front-ends for users that switched to a Windows app from a mainframe app. In every case the business analysts push hard to keep the system similar to what they have, to make each user's transition a little easier. In every case, we've found that the data entry people's requirements are far different than a clerk in front of a person and the UIs need to be designed differently. For example, Data Entry clerks do not care about a drop-down that lists all 40,000 procedure codes - they LOVE typing in the full value and when they tab out seeing the description so they know they got it right. Clerks with people in front of them seem to like a more robust UI - lots of grids and sortable data and lots of linking to other parts of the system (and almost *nothing* should be modal).

 

From that respect, our Data entry screens have been "cow pathed" to meet their needs and, from what I've heard, they've all been floored with our performance (in a good way). I can't wait til next week when we start our dedicated performance tuning!

 

I would make one other "If I had to do it over" wish: I wish we had investigated our 3rd party control options more before we went with who we went with. In many respects our controls are "good", but they still have unresolved bugs that are *really* annoying. Some have workarounds while others are more like "sorry, but on THIS screen only, you have to click the Pay button twice". Ugh, I HATE telling a user that...

 

I think the benefits of managed code are well worth it. If you're used to "normal" C++ (non-MFC or other "easy" frameworks) then managed will be quite rewarding.

 

If you have a large codebase to "convert", I'd strongly suggest buying some form of training videos or CDs. We tried both (ASP.NET videos and C# CDs). The videos were a lot nicer because you could fast-forward the dorky dialog, but you need a dedicate team to actually watch them. Also, ours were video tape and so you weren't next to a computer when you watched them. The C# ones were nice, but were a LOT of reading on the computer which, unless you have a nice tablet PC, is not a fun option. Paper is still the way to go in my opinion.

 

Ideally, pay the big $$ and have some Microsoft guys come and train a few key individuals - not on the language, which you can pick up pretty quick, but on a lot of the framework pieces. From past experience, the time spent hands-on with knowledgable MS staff is *always* worth the money.

 

Also, pick up a few books on Patterns and Practices (if you haven't already) and investigate the MS P&P site:

http://www.microsoft.com/resources/practices/default.mspx

 

Especially:

http://www.microsoft.com/resources/practices/patterns.mspx

and

http://www.microsoft.com/resources/practices/code.mspx

 

-ner

[VBAHole22]

I love the 'cow-path' analogy.

That's a great image to have in mind while designing an application. Think about the best good for the most people.

 

Let me ask you one small question. If I were to convert my web app to a win app could I have all users run it from a single exe on a network path rather than having to push out updated exes to each user when things change?

[Nerseus]

They wouldn't really be running "from the network" - the EXE would be sent to the client machine (via the network) for running. It's a better solution to have a "loader" application that they run locally that could download the EXE (and any extra required files). We used a custom "solution" to download files, though Chris Sells wrote an interesting article

 

I also remember reading this article a long time ago, but can't remember how much of that we used (if any).

 

I was only involved in the beginning and ending stages of our auto-download code so I don't know all the technical details of our current solution. I know we use an XML config file on a server to tell us current versions, file dependencies, etc. (flags for "always download" and more). A coworker did all the guts of the coding - figuring out versions, downloading and installing assemblies, etc. - so I can't offer much "real" advice on how it's working. My lack of knowledge on that component also means I don't have to debug it :)

 

Here's another article - Death of the Browser?, that describes the new way to USE the browser (or internet in general) to download "real" executables.

 

Using a browser for an app has two main advantages: easy deployment (practically zero) and access (get to the app from any machine). Microsoft's idea was to use the browser to get a Windows EXE on the machine without the normal hassles of an installation program. I'm sure MS would be happier if people stuck with code that HAD to run on a Microsoft platform vs. a browser app that could run anywhere, but it works out well for developers who just want an easier deployment solution and don't care about the "MS is evil" arguments.

 

-ner

 

PS Don't overlook this article by Chris Sells. When you follow the link, check out his other articles in the MSDN Library tree on the left. Also, do a google search for "don box site:http://msdn.microsoft.com" and plan to spend a week just reading and watching MSDN TV shows :)