I am developing a VB6 legacy application. I have started writing all new code in VB.NET essentially creating what I am calling an interoperability layer. I could approach this in two ways:
Write all new code in VB.NET using this interoperability layer and use a phased approach to upgrading.
Continue writing VB6 code and then convert it all at a later date (use a big bang approach). I do not have time to convert the entire application at the moment.
My question is, which is the better approach?
UPDATE
The reason I favour option 1 is because there is an ASP.NET application. The previous developer would effectively duplicate code in both apps i.e. VB6 and ASP.NET. Therefore some of the code in the ASP.NET app can be shared with VB6 and vice versa. That is why I believe option 1 is better, but I cannot find any literature to suggest that developers actually do this
In a previous life I was involved in the same type of project. The original application was written with Access as it's framework. Then came VB6 which seemed to work nicely and allowed for more features without having to alter much of what was written originally in Access.
Along came .Net ...
...as much as I disliked the developmental staging to .Net and being forced to work with an interoperability layer it was necessary.
That said, I will answer the question as subjectively as possible:
If you know that the application is to be converted fully to .Net, then do as much of your new development with .Net as you can. There is no reason I can think of to put it off other than the perceptions (and truths) about interoperability - e.g. more overhead, performance, etc.
sidebar - at least you don't have interoperability issues with Access ...when it crashes, it brings down everything. It was my first experience with interop (with Access) and it wasn't pretty.
Advantages to waiting on .Net development:
shorter time to deliverable (no interoperability layer)
more stable app (no interoperability layer)
Disadvantages to waiting on .Net development:
Long (and likely unprofitable) release cycle while the entire app is re-written
Lots of new bugs introduced
Learning to write unit tests when that will be the last thing on your mind
Beginning .Net development now will increase your chances of success in the long run. I don't believe an interop layer is going to cause you the headaches it did for me - and any degradation in performance should be minimal.
I don't know if you are involved with a team of developers on this project, but if you are, make sure everyone is on board with the move to .Net. I've seen a few VB6 developers strike a dear in the headlights pose over VB.Net. The nature is to continue writing in the same style they're used to.
Concentrate on giving the users what they want.
If it's easier to accomplish this in vb6, then do that.
Worry about converting to vb.net when it's necessary to convert to vb.net.
The tools to convert vb6 to .net are now pretty
good, are under constant development and so can be expected to improve further.
I personally would use your first option(since you already have your interoperability layer implemented), that way it will make the rewrite when you do it less painfull.. if you design you class structures correctly. The second option would be my preferred way to go but since you are under time constraints, use the first. Eventually the VB6 runtimes are not going to be part of newer versions of Windows, see this SO question. I myself have a VB6 application that is going to need to converted.
Related
Which one would you prefer to extract a sub-string from the given string and why?
I am thinking that since Left and Right are VB functions and not .NET functions, they may cause problems in the future in terms of compatibility.
Please clarify my thoughts on that.
Use whichever makes most sense i.e. makes that piece of code easier to read.
I don't know why you'd think that they'd cause problems in the future, they're functions, they're provided as part of the VB.Net Language set, there is no earthly reason why they would be removed, and even if they were, they would be trivial to re-implement.
Use 'em, cause you ain't gonna lose 'em
When given the choice between a feature that is from Microsoft.VisualBasic vs a comparable feature that is provided in the core framework assembiles, I tend to stick with the latter in most cases.
I do this for various reasons:
It tends to be understood by more developers. (e.g. C# guy looking at my VB.NET code).
You're more likely to find online help (message boards, stackoverflow, etc) for the core framework version than you are for the VB-ized version.
Using them gives your code a "legacy" feeling to it. It's like making use of the Call statement.
Makes it easier for another person to "copy and paste" VB.Net code into their C# (or other .NET language) project and have it be one less language translation point/hangup. (Unlikely this is a real concern/reason, but I know I've many-a-time "copy and pasted" example C# code into my VB.Net project and anything that doesn't cause road blocks in the translation process (e.g. usage of yield) makes my life easier.)
While completely inconceivable they are going away (as most of these keywords/statements are a BASIC language construct), they do feel more likely to become marked obsolete than any of their core framework counterparts. Especially as VB6 is becoming more and more of a distant memory and the VB.NET language takes on a life of its own in conjunction with the core .NET framework advancing.
One notable exception to this, I tend to make use of the My namespace proxies offered; My.FileSystem.ReadAllText(...) is just sexy. :P
Do you work alone?
If no, the decision is simple.
If your team members have C# background, use Substring.
If your devs have some VB6 background, use Left and Right.
If you ain't sure, ask them.
.net SubString will throw if start + length is > than the string length where VB Left() will return the entire string if a length greater than the string length is provided. That's a substantial behavioral difference.
Also, given .Net Standard, avoid Microsoft.VisualBasic.
Yes, I know this is > 10 years old, but ended up here when trying to port some really old code. So, thought I'd share the difference.
I have come to know that there is a code migration wizard, that heps migrate from vb6 to vb.net.
How I can access that in vb2008?
Thanks
Furqan
There seems to be some tool support available.
Still, I would be skeptical to the use of the word migrate if you are making the technology monster-leap from VB 6 to .NET 4.0.
If your VB 6 application is really well designed with core business logic nicely isolated in separate classes, then those parts could perhaps be suited for migration.
But, if someone intends to support and maintain this app for another 10 years, you should consider whether a rewrite is a better option. That way it will be easier to start taking advantage of the efficiency gains provided by the new technology. I don't think there is any migration tool that will convert VB 6 code into e.g. anonymous methods, lambda expressions, linq, reflection and generics.
The need to consider a rewrite is particularly important if your long-lived application has suffered increases in code entropy and complexity over the years causing it to be hard to understand and difficult to maintain.
In 2002 I did a pretty large VB6 app for a client. It used a lot of UserControls and a 3rd party menu control (for putting icons next to menu names). It had dynamically "splittable" panels, TreeViews with multi-state checkboxes, etc. A very rich UI. My total time on the project was about 500 hours, which the client graciously let me spread over a whole month. (Yeah, it was that kind of job.) They were very happy, though, and they paid the bill on time with no argument.
So after having no contact with them for years, they suddenly call and wonder if I can update the app to .Net for them. My initial reaction is just to decline, since I don't use VB.Net. And having read a bunch of posts on SO about the difficulties of porting, etc., etc., I'm even more inclined to decline, so to speak.
Still, before I tell them no I am interested in roughly quantifying the effort it would take. I would love to hear from anyone who has done this kind of thing and has a feel for how much work it is. Was it:
Significantly less than the effort you used on the original?
Somewhat less than the effort you used on the original?
The same as the effort you used on the original?
More?
A lot more?
Please only respond if you have actually done this kind of port. And the answer doesn't have to be exact, since I really am only trying to ballpark this. My feeling is that the effort will be at least as much as it took for the original, if not more. But I could be wrong. Thanks for any help.
I have done what you've been asked. In my case it was an (amateur) bowling tournament mgmt system: Member database mgmt (personal info, IRS/Winnings info, mailing lists etc etc etc) , tournament mgmt (player assignments, scoring, lane ticket generation, check register for winnings and side-pots, etc etc etc) as well as IRS EDI generation for all winners in a given year. Plus about a billion little items scattered across ~ 50 screens/sub-screens.
The key is CLIENT UNDERSTANDING -- You must be clear that they understand that this is not trivial; this is a new adventure for BOTH of you (particularly if you are a new-comer to VB.Net) If they liked your work before then they may very well give you the leeway/freedom to learn VB.Net on their nickel.
Reading some of the previous answers let me make a few suggestions (based upon 30 years experience as a software developer, the last 20 of which as a consultant....)
TAKE THEIR MONEY IF THEY OFFER IT. You need to bring your skillset into the 20th century; let them pay for it (again, if they agree.) They may be Magazine surfing and want "the latest stuff" for NO GOOD REASON -- but maybe they realize that they can extend the life of (your) application by this port. In essence they may have all kinds of goofy reasons for doing it... if they are NOT hiring you to DECIDE whether or not this port is a good idea. Then you may express any dismay you have about the decision PROCESS out of good client relationship building; BUT if they want to do this then it might as well be your job.
Take all this mumbo-jumbo re: C# vs VB.Net with a grain of salt. I have worked EXCLUSIVELY in VB.Net / ASPX.net (vs C#) since its inception and have yet to come across ANY functionality NOT attainable in VB.Net. There are some 'purists' out there that just view VB.Net as a toy. Well, I came from the days of writing in Assembler, then C, then C++ (And you can throw in Fortran, PL1 for good measure) then VB5, then 6, then VB.Net ... and NOW JAVA for Android. Its ALL GOOD FUN... and each has it merits and drawbacks. Remember that C# and VB.Net are essentially just GUIs to achieve a meta-language intermediate. You can write a TERRIBLE (as measured by efficiency or memory use or whatever metric you choose!) Program in C# and a great one in VB.Net (and vice-versa.) DO NOT EQUATE GOOD PROGRAMMING WITH LANGUAGE SYNTAX. (... C# is "superior" ???? Gimme a break.)
I chose to allow the Visual Studio do most of the heavy lifting for the first pass. Then you go through the gazzillion errors and clean it up. It goes pretty fast.
BUT you need to decide whether or not to take advantage of any framework benefits that you had hand-coded in VB6. E.G. looping through a string to locate a specific character(s) is now as simple as The_String.IndexOf("c") I found that in my case I went through the code several times and took better and better advantage of the Class (i.e. object orientation) as well as framework goodies as I became comfortable... this adds to your development time (see CLIENT UNDERSTANDING mantra) BUT your code WILL BE MORE Efficient then it ever could have been in VB6. You could simply port to get the errors out and not take ANY advantage necessarily from the framework.
I have not found any issue with 3rd party active-x controls. You can add a reference to FRAMEWORK objects, COM objects, etc. It may even be likely that the control vendor has a .Net (managed code) version... OR there may be suitable alternatives since you wrote the thing in VB6. (See CLIENT UNDERSTANDING mantra)
So if your still reading, then now I will finally tell you that the second attempt at my application in VB.Net CONVERTED/PORTED from VB6 was ~ 1/3 of the original time to get to a working model... and I was learning the framework as well. (If your confident in your skill set, have learned a few languages through the years you will get the gist of VB.Net quickly --- its the SUBTLETIES that take awhile.)
I must caution you that the thing that can REALLY kill you if you do not preach the CLIENT UNDERSTANDING well enough is if they want to make changes WHILE you're porting (and this is VERY LIKELY since they've been using it for awhile... I was very true in my case as well.
There is no hard and fast rule here. It could be that changes will actually HELP YOU get to a better understanding the framework faster OR changes could be a real pain. Only you can determine which flavor they might be. AND if they look to be the PAINFUL type -- you might ask to do the conversion first so that you have reliably reproduced the functionality -- THEN go back and review the code to make changes and take advantage of the framework as necessary. But, as I said, there is NO Hard and Fast rules here -- and don't let the purists tell you differently --- remember they are probably the same guys that said that PASCAL was going to take over the world!
So after having no contact with them for years, they suddenly call and wonder if I can update the app to .Net for them.
You need to ask why they want this done.
It's a Bad Plan(tm) for clients to be making technical decisions on a whim. Before applying any solution, thoroughly understand their needs and their problem. Only after you understand the problem as they do should you make recommendations.
It could be that they're infatuated with a buzzword and want to be using the latest thing, or it could be any of a million other things. The solution to their problem could be something really easy, but if you don't find out what their problem is, you will never know the best way to solve that problem.
I would plan on it taking about 50% of the time and effort it took to create it in the first place.
I have done EXACTLY what you are asking about for a commercial software product that consisted of roughly 500 kloc. We balanced the desire for refactoring with the desire to get something working and released as quickly as possible.
It took nearly the entire team about 1 full year to get it done...for a product that took 4 years to create in the first place. It was a gigantic undertaking..not to be underestimated.
We are doing that exact thing right now, however it's slightly different. Instead of one huge application, there are many smaller ones. However, there are a few bigger ones in the list. What we found out is that it was significantly less work than we originally thought. BUT...the biggest unknowns had to do with third-party controls we had. If you have a lot of those to basically redesign, you will probably be looking at more work.
The one good suggestion I have is to use Visual Studio 2008 for the conversion (not VS 2005). There were far less problems when using the built-in converter in VS 2008 than there was with VS 2005. Not sure why, it just was that way.
So, I can't say that you won't spend 500 hours again, but most likely not. Most of your time should be spent on testing to verify no functionality was lost.
In my opinion,
Visual Basic 6 and Visual Basic .NET are so different that you should forget about their coincidence in their name, and treat this as a migration to .NET =P
I think that you have one big advantage and one disadvantage:
Advantage: you allready know what the application has to do. Probably you´ll have some meetings with your clients, in order to add some modifications or new features, but you have the major part of the requirements very clear. You´ll even have the old working application to see while you, or your team, are coding.
Disadvantage: you´ll have to learn a new language. Saying how much time is going to take, is very subjective. I´ve allways thought that learning a new language is not the problem, the big problem would be if you have to learn to program!. But you do know to program. You´ll know what you want to do, and you´ll have only to search how to do it in the new languaje.
Since you have to learn .NET, If you have to estimate, I think that you should suppose that it will take you at least the same as the previous application, even more.
My advice is too take the chance to learn this new language. And if you are more inclined to decline the project, let me give you another idea... Maybe you could estimate a little module of your application, and tell the client that you´ll try to do that module, to see how much it takes to you. The client should pay this little module, even if you decide not to continue.
You can´t tell the client that you know all the requirements, so they are saving money with you, in some way. And that they should take this little risk (we are talking about a little module), because who better than you to make the project, you know the old application perfectly!
If the client is right with this, you´ll can take the decision with more arguments. And If finally you decide to continue, with this little module done, you can estimate the whole project better than before.
Sorry, my English isn´t very good, and probably I´ve made many gramatical errors.
EDIT grammar mistakes... =P
This is a huge topic.
You should take a look at MS' Free Book - Upgrading Microsoft Visual Basic 6.0 to Microsoft Visual Basic .NET.
Were you to rewrite from scratch, rather than simply try and port the previous application, it shouldn't take too long. VB.Net has some features that will make the new application build take shorter. As it seems that you don't know VB.Net already, what will take you the most time is learn how to do things the new way(tm).
I'd go for two months this time.
But seriously, that's probably not far off — or even low — because the client will have some reason for needing the port done. It won't be just a straight port - they'll want some "small little enhancement" that will blow the whole project up.
Additionally, I'd worry a bit about the third party controls. Most of the rest of it should convert okay, but there's sometimes an issue finding a good analog to a 3rd party control in .Net.
I'm also concerned that you don't use vb.net. If you're a c# user and wanted to re-implement that way you'd be fine, but otherwise this is a non-starter. VB.Net is just different enough from vb6 for you to get yourself into trouble.
Aside from all that, I would expect it to be less work this time than last, because you have a very explicit design laid out in front of you that you merely need to follow.
We are migrating our applications to VB.Net 2008 from Classic VB and I need to create a base namespace and business layer. My method of approach is going to be to visit our top BA and identify the common areas of our (Fixed Income) company and try to form a decent inheritence model with as much of the code in generics as possible.
What's everyone's experience of doing this and also as a second part of the question, we are looking at incorporating Web Focus into the OLAP side, how would this affect the design of the corporate namespace and it's derivatives?
I think the best way to begin to create a corporate .NET framework is to begin by harvesting existing code out of current corporate projects. Building a framework from scratch by talking to a BA without writing code for a specific, concrete project might lead you to over design the framework in some areas and totally miss some necessary features in others (as well, it might place artificial constraints on your framework clients for no good reason).
See Fowler's entry on Harvested Framework and this blog post for a more complete explanation.
I'm not familiar with Web Focus but I'm guessing it would affect it in some way, however, if you go with a Harvested Framework, your usage of it in the first few applications you build will shape how you use Web Focus within the framework.
Jereme has it right on the framework. I'll briefly mention something obvious about namespaces.
Always remember what a namespace is for - it's to provide a "space" in which names will live. In particular, it's meant to provide a space small enough that the people creating names within that space will be less likely to produce duplicate or confusing names.
This can only work if the namespaces are organized along patterns of organization, or of domain knowledge. A simple example often used is a pattern of Company.BusinessUnit.Application. The theory is that within the set of developers working on a given application, there is less chance for name duplication. This will not be true for a large application, where you would want to break it further based on layer or area. Similarly, of the business unit is too large, you'll want to break that down.
But in all cases, you're really trying to partition sets of brains, as it's the brains that create the names.
If your application is under VB6 (not VB3) then I strongly recommend that do the redesign to a class hierarchy in VB6 first. The reason for this is that in any conversion you try to preserve the behavior of the old application. Is stretches out the project time to do this and do a redesign at the same time.
By making the design changes in the applications original language first then you are assured that any bugs that result are due to the design not the conversion.
I done three major conversions of our software in the past 20 years; (DOS to VB3) (VB3 to object oriented design in VB6) and (VB6 to VB.NET).
Finally it is straight forward to make a design in VB6 that is ports over to VB.NET readily. The trick is to hide the specific VB6 APIs and constructs behind a interface (graphics, printing, etc)>
When do the conversion I recommend working from the top down. Change over your forms first to .NET which calls the VB6 COM DLLs. Then convert each layer over until you reach the bottom DLLs.
Again, if you try to change the design AND convert to another language for any complex application you will double the conversion time.
I work for a large state government agency that is a tad behind the times. Our skill sets are outdated and budgetary freezes prevent any training or hiring of new employees/consultants (firing people is also impossible). Designing business objects, implementing design patterns, establishing code libraries and services, unit testing, source control, etc. are all things that you will not find being done here. We are as much of a 0 on the Joel Test as you can possibly get. The good news is that we can only go up from here!
We develop desktop CRUD applications (in C++, C#, or Java) that hit the Oracle database directly through an ODBC connection. We basically have GUI's littered with SQL statements and patchwork code. We have been told to move towards a service-oriented n-tier architecture to prevent direct access to the database and remove the Oracle Client need on user machines.
Is WCF the path we should be headed down? We've done a few of the n-tier application walkthroughs (like this one) and they seem easy to implement, but we just don't know enough to understand if we are even considering the right technologies. Utilizing the .NET generated typed DataSets seems like a nice stopgap to save us month/years of work (as opposed to creating new business objects from the ground up for numerous projects). Is this canned approach viable for a first step?
I recently started using WCF services for my Data Layer in some web applications and I must say, it's frustrating at the beginning (the first week or so), but it is totally worth it once the code is deployed.
You should first try it out with a small existing app, or maybe a proof of concept to make sure it will fit your needs.
From the description of the environment you are in, I'm sure you'll realize the benefit almost immediately.
The last company I worked for chose WCF for almost the exact reason you describe above. There is lots of good documentation and books for WCF, its relatively easy to get working, and WCF supports a lot of configuration options.
There can be some headaches when you start trying to bend WCF to work in a way not specifically designed out of the box. These are generally configuration issues. But sites like this or IDesign can help you through those.
First of all, I would definitely not (sorry for the emphasis) worry about the time you'll save using typed DataSet's versus creating your own business objects. That is usually not where you will spend most of your development time. I prefer using business objects myself.
In you're situation I would want to implement a proof-of-concept first. One that addresses all issues you may encounter. This proof-of-concept should implement an entire use case, starting on the client, retrieving data from the database and returning it to the client. You should feel confident about your implementation before continuing.
Then about choice of technology. WCF is definitely a good choice for communication between your client applications and the service layer. I suppose that both your clients as well as your service layer will become C# applications? That makes things a lot easier since interoperability between different platforms (Java/C# for example) is still not trivial although it should work in most cases.
Take a look at Entity Framework (as there are a couple Oracle providers available for it already) in conjunction with .NET 3.5 SP1 which enables built-in WCF serialization of your EF generated classes.
Here is a good blog to get started: http://blogs.msdn.com/dsimmons
CSLA might be a good fit for your N-Tier desktop apps. It supports WCF, has a large dev community, and is well documented. It is very object oriented.