Related
I've got a contract where I have to continue the development of and old application suite that was programmed in VB5 back in the days.
I've bug to fix and new feature to develop.
So I have a few choices:
Keep programming in VB5
(NOOOOOOOOOOOOOOO!!!!)
Convert VB5 to C# (How??? Is it
possible without going insane?)
Rewrite the whole application suite
(Very time consuming)
Is there any other choices? What should I do?
EDIT: Ah and also, it relies on an ACCESS database which I'd like to move to SQL EXPRESS. Because it's a crazy database made illogically by a stupid programmer from the '90s lol.
Thanks
The choice I've made every time is to just re-write, or purchase a suitable replacement if I could find one.
I have tried doing incremental upgrades from VB6 to VB.NET, but I don't like that approach because it leaves around ActiveX controls that I'd rather not use. Re-writing is cleaner.
I don't think there is a converter from VB5 to C#. You might be able to go from VB5 to VB.NET and then convert to C#, but in my experience it's less time-consuming to re-write than it is to try to upgrade and fiddle around with the broken code.
There is no reliable way to do 2) so it's 1) or 3).
And I don't think your customer wants to pay for 3). But maybe you can sell it on reliability, support etc.
Otherwise you're stuck with 1)
One approach would be to tactically rewrite sections of the code in C# - you could start with the areas you are likely to be bugfixing the most, create C# assemblies to mirror the functionality, and then expose these to the VB5 code through COM interop.
A good suite of Unit Tests would be highly recommended for this approach!
I've heard that Working Effectively With Legacy Code by Michael Feathers is the best book around for understanding how best to chop up a problem like this.
The answer definitely depends on a lot of factors. I recently had a similar project (a 10-year plus old VB6 Windows app with a large, spaghetti codebase), and addressed it with a "hybrid" approach:
Bugs were fixed in VB6
New features were developed in .NET 4, using COM interop
We developed some WPF dialogs and styled them to go with the old interface to handle new UI.
This option only works when the new features are fairly independent of the main app, but it has the advantage of at least taking advantage of the productivity of new technologies and also paving the way for future conversion.
I've recently finished working on a project where we converted a lot of legacy VB6 applications to C# using Artinsoft's VB Upgrade Companion.
It's a tough call to decide which approach is the best. In a lot of cases, converting the code can end up being very painful, especially if there is a lot of logic based around features which are significantly different between the two platforms (e.g. one-indexed arrays, or handling errors via the Information.Err object instead of through exceptions).
On the other hand, if you try to write it from scratch, there is a good chance that you'll accidentally change some subtle behaviour that isn't immediately obvious when reviewing the original VB5 code. Things like this can be difficult to track down.
A good compromise is to use a converter to port the code over, then use this as a guide for writing things from scratch, as there will hopefully be places where you can just lift converted code across straight into the new code base. At the same time though, you get the benefit of writing more maintainable code everywhere else.
With all that said, if the original VB5 is well written and (relatively) well architected, then I would recommend against any sort of upgrade. You will spend far more time trying to match the existing behaviour of the old application than you would just working on the old code.
Good luck with whatever you decide to do - you'll need it :)
Maybe you should first convert to vb.net, and then to C#?
If you just need to fix a bug, and it's a reasonably simple bug, and you don't anticipate much more work beyond that - stick with VB5. Anything else will introduce far more work.
However, if this is really a "live" product which you expect to work on a lot in the future, I would probably start from scratch. My guess is that you've learned a lot about design and architecture since writing the app - so you might as well take the opportunity to write a more maintainable app. (You'll also probably have learned which design decisions in the original app ended up being mistakes.)
I want very specific answer from the developers who did this and want to know how you resolved the problems you faced.
We have very big MFC (VC6) 32 bit application existing for 10 years. Now we would like to migrate it to .NET unmanaged 64-bit application. Here we have some problems, our UI should not change, we may need some managed .NET class for easier development, without affecting architecture how to add managed code with unmanaged code, lots win32 APIs might get changed to new APIs, should be run in XP, Vista, Windows 7 OS machine without any change, these activities should not be time consuming, new technologies analysis should be done as we are MFC programmers...
Pls share your experience and if you have any clear documents will be very helpful...
Note:
For the clear understanding, I am re-phrasing some points again. We want to migrate our VC6 native code 32-bit application to VS2008 (or VS2010) native code (unmanaged C++) with 64-bit support. The primary requirement is there should not be any change in existing UI. In Addition, if .NET supports the combination of managed code with unmanaged code, we can try using some features like .NET remoting in unmanaged C++ environment. And one more important thing I would like to convey to all is that we are not going to start any coding in C# or from scratch.
We've done this is steps (VC6 -> VS2005 -> VS2008 -> (soon) VS2010 ) and most issues were related to changes in the API.
unsafe string operations (strcpy vs. strcpy_s ) that give out a TON of warning messages (use the _CRT_SECURE_NO_WARNINGS preprocessor define to remove them if you do not want to fix them all )
Changed in prototypes for message handlers (returns LRESULT, changes in WPARAM and LPARAM, ... )
Deprecated API (you'll find them out soon enough, I think there's a page on msdn about that)
Compiler might be a bit more strict in regards to standard C++ .
It's hard to go to specifics...
but have a look at this blog entry for some more info : http://insidercoding.com/post/2008/08/20/Migrating-from-VC6-to-VC9.aspx
Good luck.
Max.
What you're asking for isn't really a migration -- it's a nearly complete rewrite, at least of the entire UI. Unless your "very big ... application" has a very small, simple UI, I'd sit back and think hard. Read Joel's Things You Should Never Do.
Bottom line: this is almost certainly a really bad idea. If you do it anyway, you need to start out aware that it will be quite time consuming.
If you decide to go ahead with this, you nearly need to do it incrementally. To do that, I'd probably start by finding discrete "pieces" of functionality in your existing code, and turning those pieces into ActiveX controls. Once you've gotten that to the point that your main program is basically a fairly minimal framework that most instantiates and uses ActiveX controls, it becomes fairly easy to create a new framework in managed code that does roughly the same thing, delegating most of the real work to the existing ActiveX controls. Once you've done that, you can start to migrate individual controls to managed code as you see fit.
The point of doing things this way is to avoid having a long interval during which you're just writing new code that duplicates the old code, but can't do any updates for your customers. Nearly the only reasonable alternative I've seen work reasonably well is to have two separate development teams: one continues to work on and update the old code base at the same time as the second team starts the total rewrite from the ground up. If you have enough money, that approach can work out quite well.
Microsoft, for one example, has done things like this a number of times. Just for a couple of examples, years ago when there were rumors that Borland (then Microsoft's biggest competitor in programming language tools) was going to produce a TurboBASIC, Microsoft decided QuickBASIC (V2 at the time) really couldn't compete. They responded by setting up two teams: one to do as much upgrading as reasonable to QuickBASIC 2 to produce QuickBASIC 3. The second team did a total rewrite from the ground up, producing what became QuickBASIC 4.
Another example is Windows 95/98/... vs. Windows NT. They continued development of the existing Windows code base at the same time as they did a total rewrite from the ground up to produce Windows NT. Though they kept the two teams synchronized so UIs looked similar and such, the two were developed almost entirely separately from each other. Only after years of overlap between the two did they finally quit working on the old code base (and I sometimes wonder whether the crappiness of Windows Me wasn't at least partly intentional, to more or less force users to migrate to the NT code base).
Unless you can do that, however, nearly your only chance of success is to use an incremental approach.
As Jerry has mentioned Joel talks about this in his blog Things You Should Never Do.
Moreover there are other things to be considered with this conversion.
What would you do with existing VC++ 6.0 code base.
Qualification time( different OS, SQL etc) needed to test the entire product after the changes are made.
How do you manage 2 code bases with and without 64 bit support.
PS: Most importantly by the time you fix and qualify your product in VS2010 i guess VS 2012 would have released :)
I intend to write a small application to scratch a personal itch and probably make the life of some colleagues easier. Here is what I have:
10+ years of experience in C
Plenty of experience in programming against the Win16/32 API in C from the Win3.1 to 2000 days.
C library written by myself already doing about 75% of what the application shall do.
What the application shall do:
open a binary, feed it into the mentioned library.
take the resulting text output and feed it into a new Excel Workbook.
apply some formating.
integrate nicely with the Windows environment (availability in "Open With...", remember some stuff using the registry etc.)
(maybe later) before giving the CSV data to Excel, parse it by looking up the meaning of some values in an XML file.
Except for the XML parsing part I have done all of that stuff before including COM / Office Automation in C/Win32. There is a lot of boilerplate code involved, but it is doable and the result will be a pretty small application without the need for an installer.
So why even think about C# / .Net?
no experience with parsing XML
the promise of less boilerplate code for the Windows and Excel stuff (yes, I have done C++ with OWL, MFC, ATL etc. but I am not going there anymore - not for free/fun)
Since I have also experience with C++, VB(not .Net) and a little Java / Objective-C I suppose learning C# will all be about the .Net libraries and not actually about the language.
My considerations so far:
Learning .NET might be fun and might result in less code / first steps in a more modern environment.
Sticking with what I know will lead to a predictable outcome in terms of effort and function (except for the optional XML stuff)
VB looked great at the beginning until the projects where about 80% done, then the pain started and the DLL coding in C. I am concerned history could repeat itself if I choose .Net.
My primary objective is the functionality. Effort is a concern. The XML parsing is optional.
Please advice.
Update: one thing I forgot to mention explicitly is that I am also worried about easy deployment of the tool to my co-workers. With Win32 I am pretty sure I can come up with an EXE file < 1Mb that can be easily emailed and does not require installation. With .Net not so much. Can I create the necessary MSI or whatever in Visual Studio Express (free) or do I need 3rd party tools?
as others have your question mostly covered, I'd just like to quickly comment on your considerations:
Learning .NET might be fun and might result in less code / first steps in a more modern environment.
Totally agreed. It is definitely fun and usually it does result in less code. The investment you make now will certainly benefit you in future projects. It is way faster to program in .Net than in C. Not only it is easier, but it is also safer. You are isolated from many programming errors common in C mostly related to memory mismanagement. You also get a very complete managed API to do stuff you would usually need to build your own framework.
Sticking with what I know will lead to a predictable outcome in terms of effort and function (except for the optional XML stuff)
Hence your indecision. :-)
VB looked great at the beginning until the projects where about 80% done, then the pain started and the DLL coding in C. I am concerned history could repeat itself if I choose .Net. My primary objective is the functionality. Effort is a concern. The XML parsing is optional.
.Net is an entirely different beast from VB. Most of the things you wouldn't be able to do in VB, or at least do them easily, are supported by .Net. For instance, Windows Services are a snap to build in .Net. Socket programming is also supported, but there are very few reasons to do it yourself, as you've got loads of communication APIs with .Net. You've got web-services, .Net Remoting, MSMQ management, and more recently WCF. Proper multithreading is supported by .Net, unlike the idiotic apartment model in VB. In case you really need to go low level, you can also actually use pointers in C#, inside of unsafe code blocks, even though I would never advise to do so.
If you really need to do things in C, then integrating is also relatively easy. You can create COM objects and use interop to work with them from .Net. You can also interact directly with plain ol' dlls using DllImport. Using www.pinvoke.net makes it easier.
When I developed in VB, sometimes I also had to go back to C++ to do stuff that I wasn't able of doing in VB. Since I began programming in .Net, the only extremely rare scenarios I would need to go back to C++ were when I needed to use legacy COM components that used types I was having a hard time to marshal via interop. I wouldn't worry about history repeating itself.
If you're using COM, you may be interested in using C# 4.0 instead of earlier versions - the downside being that it's only in beta. But basically it makes COM stuff somewhat less ugly for various reasons.
I'd expect there to be plenty of good C libraries for XML parsing by now. I would expect the main benefit to actually be the knowledge gained. I doubt that you'll actually produce the code faster for this project, but the next one may well be a lot quicker.
How much do you care about learning new stuff?
It sounds like an ideal project for learning C# & .NET.
You know most of what you need to do so you can use that to gain a base level of understanding of C# & .NET which you can then apply to the stuff you need to learn.
As Rune says though, a key driver could be the timescales. If this is something you need in a hurry then coding it in C & using win32 directly might be the answer.
Sorry I couldn't be more definite.
I think you should use C#. With your experience the learning curve won't be too steep. The code will ultimately be cleaner (and less of it) than you probably could with C/Win32.
There is probably going to be no problem using your existing C-library with the [DllImport] attribute.
It depends. :-) It depends on whether you want to do this quickly or if you want to learn something new. It depends on whether you will be the only maintainer of the code or if others will maintain it in the future. It depends on how complex your xml handling will be and on how complex the COM automation is.
You will probably get a working application quicker if you do it in C than in C#. Both since you have much of the stuff needed already in place and since you know C well.
But this project sounds like a good match for C# and .Net. .Net has great support for XML and COM interop is easy but clumsy in C# (much better in the next version!). So if you are interested in learning C# and .Net this would be a good project to do so.
I would definitely do this in .Net and probably C# (but I am biased). Using .Net would probably result in code that is easier to read and maintain and most probably easier to write. So if you are interested in learning C# I would suggest you go for it!
Edit:
You worry about the size of the executable if you write it in .Net. I doubt that will be a problem, for most if not all of the libraries you will use for a project like this will already be installed on your computer. 1 Mb is rather large for a .Net executable, event for a big project.
a short notice on the installation. .NET is as default xcopy-able so you wouldn't need an installer for the exe to be usable. Mail it around (or with the next release of the .NET framework optionaly leave it on a network share)
You could look at building a hybrid system that uses C++/CLI and C#. C++/CLI provides a nice bridge between the two and lets you easily split different parts of the system between the managed and unmanaged worlds.
Not sure if the setup projects are included in the free versions of visual studio. But you could use clickonce (included with the framework) or WIX (open source XML based msi creation tool).
learning C# will all be about the .Net libraries and not actually about the language
No there are many things you need to learn about the language (delegates , events , generics ...) and also it is object oriented and it manages the memory by itself and yes no pointers :)
anyway C# and .NET are great all you need is some effort to get up to speed
I have some old C 32 Bit DLLs that are using Oracle's Pro C precompiler library (proc.exe) to expose a hundred or so sproc/func calls to an even older VB6 GUI which references these functions through explicit Declare statements like so:
Declare Function ConnectToDB Lib "C:\windows\system32\EXTRACT32.DLL" (CXN As CXNdets, ERR As ERRdets) As Long
All the structures in the C header files are painstakingly replicated in the VB6 front end. At least the SQL is precompiled.
My question is, is it worth trying to impose a .Net interface (by conversion to an assembly) onto the the C code and upgrade the VB6 to C# or do you think I should just abandon the whole thing and start from scratch. As always, time is of the essence hence my appeal for prior experience. I know that if I keep the Declares in .Net I will have to add lots of complicated marshalling decorations which I'd like to avoid.
I've never had to Convert C to .Net before so my main question if everything else is ignored is are there any porting limitations that make this inadvisable?
... At least the SQL is precompiled.
Is this the only reason you've got code in C? If so, my advice is to abandon that and simply rewrite the entire thing in C# (or even VB6 if that's what your app is written in) ... unless you've profiled it and can prove a measurable difference, you won't be getting any perf benefits from having sql/sproc calls in C. You will only get increased maintenance costs due to the complexity of having to maintain this interop bridge.
You should continue to use the DLL in .NET by creating an assembly around the Declares. That one assembly probably would go a little quicker in VB.NET than C#. Then have your new UI reference that assembly. Once you have that going then you have bought yourself time to convert the C code into .NET. You do this by initially keeping the assembly and replacing the the declares with new .NET code. Soon you will have replaced everything and can refactor it to a different design.
The time killer is breaking behavior. The closer you can preserve the behavior of the original application the faster the conversion will be. Remember there nothing wrong with referencing a traditional DLL. .NET is built on many layers of APIs which ultimately drill down to the traditional DLLs that continue to be used by Windows. Again once you have the .NET UI working then you have more time to work on the core and bring everything into .NET.
I always advise extreme caution before setting out to rewrite anything. If you use a decent tool to upgrade the VB6 to .NET, it will convert the Declare statements automatically, so don't stress about them too much!
It's a common pitfall to start out optimistically rewriting a large piece of software, make good early progress fixing some of the well-known flaws in the old architecture, and then get bogged down in the functionality that you've just been taking for granted for years. At this point your management begin to get twitchy and everything can get very uncomfortable. I have been there and it's no fun. Sounds like your users are already twitchy, which is a bad sign.
...and here's a blog post by a Microsofty that agrees with me:
Many companies I worked with in the early days of .NET looked first at rewriting driven in part by a strong desire to improve the underlying architecture and code structures at the same time as they moved to .NET. Unfortunately many of those projects ran into difficulty and several were never completed. The problem they were trying to solve was too large
...and some official advice from Microsoft UK regarding migrating from VB6 to .NET
Performing a complete rewrite to .NET is far more costly and difficult to do well [than converting] ... we would only recommend this approach for a small number of situations.
Maybe your program is small, and you have a great understanding of the problems it solves, and you are great at estimating accurately and keeping your projects on track, and it will all be fine.
If you move from VB6 to VB.net or C#, throw away the C code and use the appropriate ODP.net classes or LINQ to access those stored procedures. Since the C layer (as I understand it) has no logic other than exposing the stored procedures, it's not useful anymore after the switch. By doing that, you get (at least) much better exception handling (i.e. exceptions at all instead of magic return codes), maintainability etc.
See also: Automatically create C# wrapper classes around stored procedures
I learned Java in college, and then I was hired by a C# shop and have used that ever since. I spent my first week realizing that the two languages were almost identical, and the next two months figuring out the little differences. For the most part, was I noticing the things that Java had that C# doesn't, and thus was mostly frustrated. (example: enum types which are full-fledged classes, not just integers with a fresh coat of paint) I have since come to appreciate the C# world, but I can't say I knew Java well enough to really contrast the two so I'm curious to get a community cross-section.
What are the relative merits and weaknesses of C# and Java? This includes everything from language structure to available IDEs and server software.
Comparing and contrasting the languages between the two can be quite difficult, as in many ways it is the associated libraries that you use in association with the language that best showcases the various advantages of one of another.
So I'll try to list out as many things I can remember or that have already been posted and note who I think has the advantage:
GUI development (thick or thin). C# combined with .NET is currently the better choice.
Automated data source binding. C# has a strong lead with LINQ, also a wealth of 3rd part libraries also gives the edge
SQL connections. Java
Auto-boxing. Both languages provide it, but C# Properties provides a better design for it in regards to setters and getters
Annotation/Attributes. C# attributes are a stronger and clear implementation
Memory management - Java VM in all the testing I have done is far superior to CLR
Garbage collection - Java is another clear winner here. Unmanaged code with the C#/.NET framework makes this a nightmare, especially when working with GUI's.
Generics - I believe the two languages are basically tied here... I've seen good points showing either side being better. My gut feeling is that Java is better, but nothing logic to base it on. Also I've used C# generics ALLOT and Java generics only a few times...
Enumerations. Java all the way, C# implementation is borked as far as I'm concerned.
XML - Toss up here. The XML and serialization capabilities you get with .NET natively beats what you get with eclipse/Java out of the box. But there are lots of libraries for both products to help with XML... I've tried a few and was never really happy with any of them. I've stuck with native C# XML combined with some custom libraries I made on my own and I'm used to it, so hard to give this a far comparison at this point...
IDE - Eclipse is better than Visual Studio for non-GUI work. So Java wins for non-GUI and Visual Studio wins for GUI...
Those are all the items I can't think off for the moment... I'm sure you can literally pick hundreds of items to compare and contrasting the two. Hopefully this lists is a cross section of the more commonly used features...
One difference is that C# can work with Windows better. The downside of this is that it doesn't work well with anything but Windows (except maybe with Mono, which I haven't tried).
Another thing to keep in mind, you may also want to compare their respective VMs.
Comparing the CLR and Java VM will give you another way to differentiate between the two.
For example, if doing heavy multithreading, the Java VM has a stronger memory model than the CLR (.NET's equivalent).
C# has a better GUI with WPF, something that Java has traditionally been poor at.
C# has LINQ which is quite good.
Otherwise the 2 are practically the same - how do you think they created such a large class library so quickly when .NET first came out? Things have changed slightly since then, but fundamentally, C# could be called MS-Java.
Don't take this as anything more than an opinion, but personally I can't stand Java's GUI. It's just close enough to Windows but not quite, so it gets into an uncanny valley area where it's just really upsetting to me.
C# (and other .Net languages, I suppose) allow me to make programs that perfectly blend into Windows, and that makes me happy.
Of course, it's moot if we're not talking about developing a desktop application...
Java:
Enums in Java kick so much ass, its not even funny.
Java supports generic variance
C#:
C# is no longer limited to Windows (Mono).
The lack of the keyword internal in Java is rather disappointing.
You said:
enum types which are full-fledged classes, not just integers with a fresh coat of paint
Have you actually looked at the output? If you compile an application with enums in in then read the CIL you'll see that an enum is actually a sealed class deriving from System.Enum.
Tools such as Red-Gate (formerly Lutz Roeder's) Reflector will disassemble it as close to the orginal C# as possible so it may not be easily visible what is actually happening under the hood.
As Elizabeth Barrett Browning said: How do I love thee? Let me count the ways.
Please excuse the qualitative (vs. quantitative) aspect of this post.
Comparing these 2 languages (and their associated run-times) is very difficult. Comparisons can be at many levels and focus on many different aspects (such as GUI development mentioned in earlier posts). Preference between them is often personal and not just technical.
C# was originally based on Java (and the CLR on the JRE) but, IMHO, has, in general, gone beyond Java in its features, expressiveness and possibly utility. Being controlled by one company (vs. a committee), C# can move forward faster than Java can. The differences ebb and flow across releases with Java often playing catch up (such as the recent addition of lambdas to Java which C# has had for a long time). Neither language is a super-set of the other in all aspects as both have features (and foibles) the other lacks.
A detailed side-by-side comparison would likely take several 100s of pages. But my net is that for most modern business related programming tasks they are similar in power and utility. The most critical difference is probably in portability. Java runs on nearly all popular platforms, which C# runs mostly only on Windows-based platforms (ignoring Mono, which has not been widely successful). Java, because of its portability, arguably has a larger developer community and thus more third party library and framework support.
If you feel the need to select between them, your best criteria is your platform of interest. If all your work will run only on Windows systems, IMHO, C#/CLR, with its richer language and its ability to directly interact with Windows' native APIs, is a clear winner. If you need cross system portability then Java/JRE is a clear winner.
PS. If you need more portable jobs skills, then IMHO Java is also a winner.