I have a VB6 Forms application and want to convert to .Net Core WinForms. I know conversion tools are available that make that claim. However, I'm looking for recommendations or first hand experience in doing this.
Manual may be best, but if you're looking for an automated route, I would suggest
VB6 to VB.NET WinForms (.NET Framework)
VB.NET to C# (.NET Framework)
Upgrade to .NET Core
I do not have any experience with #1, VB6 to VB.NET.
For #2 check out this project https://github.com/icsharpcode/CodeConverter. It works very well.
For #3, Microsoft has a try-convert project to upgrade .NET Framework projects to .NET Core. It has worked flawlessly for me. https://github.com/dotnet/try-convert
I just converted a decent sized app from VB6 to C#. The biggest challenge for me was the third party controls. Most tools can't manage those as most old controls are either discontinued or the interfaces are so wildly different it made no sense to use a tool.
I ended up just recreating all the forms using modern controls first. I would then just paste the old VB6 code where is made sense and worked my way through converting the logic to C#. In some cases I literally printed files to paper and read through them and typed in the C# code.
I wanted to take advantage of the .net programming model so I rewrote a lot and improved the function and readability of the code.
I have used tools and while they do help, I didn't feel it really saved me a lot of time. My "brute force" method helped me understand the application much better and helped me sort through errors and bugs easier.
In my experience it's worth the effort doing it manually. There really is no shortcut if you want to do a proper job.
Related
we have existing vb6 win application for gaming industry. There are mainly 3 big modules. For 1st module/part, I converted vb6 code to vb.net library. I used that vb.net library in wcf duplex service to use existing business logic and get/set data. And, this wcf service, I use in silverlight application. 1st part was dealing with much calculation, so I didn't convert vb6 code to c#, instead I converted to vb.net. Even, old vb6 code has hard-coded sql queries instead of calling pre-compiled stored procedures. I kept the same in vb.net library.
Now, client wants to convert entire system to silverlight web app. And, so I am thinking that for rest of the 2 modules, I should convert vb6 code to c# as there is less calculation and more db operations. Also, I will clean up code to use stored proc instead of hard-coded queries.
So, plz let me know
if my approach is correct or not. What can go wrong here? What things I should take into consideration before processing further ? should I manually convert vb6 to c# ? I know there is tool for vb.net to c# conversion, but don't know about vb6 to c#. Any advice on migrating code from win app to service oriented architecture ?
Thanks a lot :)
The tools that take VB.net to c# are far from perfect, so I highly doubt that going from VB6 to c# is going to be painless. One of the beautiful things about .NET is the fact that it allows easy integration of components regardless if their original programming language. So there shouldn't be any problem migrating your old code to VB.net (easy, cheap), componetizing it and writing new code in c#.
You need to ask yourself: What is the business value/benefit to your customers if the code happens to be in C# rather than VB.NET?
Performance, reusability, maintainability, etc. of a mature codebase is not likely to be significantly different with C# vs VB.net. I would bet that converting your mature code to c# rather than vb.net will introduce more problems than it will solve.
I would recommend using these tools http://www.artinsoft.com/visual-basic-6-or-csharp-to-the-web.aspx
They migrate from VB6 to Silverlight and WCF services
In PDC sessions i see only Framework 4.0, Azure and WPF.
My all applications is in windows forms and asp.net (codebehind) and framework 2.0 or 3.5. I see i'am obsolete, ok. But my questions is Windows Forms is dead, i need start migrate to WPF or Silverlight? or my Windows forms with Devexpress can leave more than 3 years?
It's not really dead or alive -- more like undead.
I don't think I'd say WinForms is dead... is DOS dead? Do you ever write a console app? There's way to many programs out there on Windows (really the majority of them) that use WinForms for it to just die. Remember Y2K and all those systems needing to be updated from Cobol (or was it Fortran?). Personally, I'm migrating to WPF, but there's still a time and place for WinForms I believe... C++ is still being used even though we all have C# now, kind of the same concept I think.
I've just installed VS2010 C# Express edition and there's still the option to create a WinForms project. I expect that the options still there in the full version too (I'm currently without an MSDN subscription so I can't get it at the moment).
So I think that there's still life in the technology.
By all means move to WPF or Silverlight, but do it because they offer you something you can't get from WinForms.
Windows Forms is no more dead than VBScript is dead. And I'm currently working with some fairly atrocious classic ASP VBSCript code, so I can assure you, it's not dead either (alas).
Win Forms will be around pretty much until Microsoft drops Win32 entirely, and even then it'll still be around in legacy systems for several more years.
Well, there are many differences between these two and probably it would be a good idea to establish some roadmap in order to migrate your application. There are many hundreds of websites for their comparison, but in order to answer your question, I suggest to start a new branch and start migrating while supporting your current models. With your current one you wouldn't have that much of problems either.
I am at the initial stage of designing a client application. However, being new to WPF and having already gained some experience in Win forms development, time pressures on the project means that there is a risk to going down the WPF route. If time were no pressure, then I would say forget forms and design with WPF. However, I am not lucky enough to have this luxury. Having spent a little time investigating the Composite Application Block for Forms, I have decided that I will definitely develop the application within this framework. However, there are 2 versions of the CAB, 1 for WinForms that targets the .Net 2.0 runtime which has now been retired, and then the WPF version which targets .Net 3.5. Not being a fan of 'retired' code libraries, I would prefer to use the WPF version of CAB. This may be a silly question, but is it possible to use the WPF version of CAB for Win forms application developement? I do envisage at some point in the future moving to towards WPF. If I could use the WPF version of CAB I am hoping that this would make it easier to migrate the forms application to WPF.
It looks like somebody had the same idea that you did.
I found it by reading this thread on the CompositeWPF codeplex forum, discussing this very issue.
You should be able to do this without too many issues. We are currently using CAB to enable us to display SQL Reporting Services reports in WPF (along with a couple other items). It's a pretty simple implementation, but our architecture is WPF-based, not WinForms. As far as we've been able to tell, there wouldn't be much of a problem were it the other way around, and displaying both types of forms is done the same way.
I have a small project that I will be working on shortly that collects employees time and what project the person was working on. Pretty straight forward. I was orginally going to work on it in WinForms but since im new to that I though maybe using Silverlight for the application since I will have a learning curve for each. Here is a couple of business requirements that i need to incorporate into the application.
-System will use an Access database hosted on a particular persons computer.
-Ability to generate and print reports
-Installed on the emploees desktop who will have access.
Would one technology be recommended over the other in terms of what I need to do. Here is a screen mockup of one of the pages I will need to create.
http://teewebco.com/images/main-copy.png
If you want access to the machine on which the application will run (e.g. to access a database, and to use printing), that pretty much rules out Silverlight, without jumping through a lot of hoops (e.g. having to install something on the user's machine anyway).
You say that WinForms will require a learning curve for you - well you might as well use WPF then, as it's a similar technology from the UI perspective as Silverlight. However, you can proably find a lot more resources online for WinForms though, and it's likely you'd be more productive in WinForms given its strong Visual Studio designer support.
Deployment with WinForms or WPF should be fairly easy with ClickOnce.
Since it's a local (desktop) app which needs to access a local resource (Access database), it's probably better to do winforms.
However, you might be better off doing this as WPF instead - it's more current than winforms.
Winforms and WPF are easier than Silverlight when you have to access a database because you can do it directly. If your install base uses only .net 2.0 then stick with WinForms, if you know they can install .NET 3.5 then try out WPF. Just be warned, there is more to learn with WPF and XAML but it's very rewarding especially if you want to get fancy.
Silverlight 3 lets your application to run on desktop as well.
So I'd write it on silverlight. Yet another technology to master.
I deal mostly with XBAP,
Q1.XBAP normally uses the PresentationHost.exe to get the work done,What does SilverLight use?
Q2.Are there considerable differences in moving from XBAP to SilverLight ? (Experience Based or fact based answers?)
Can somebody give me a rundown?
XBAP is the regular .NET framework exposed (as WPF/XAML) in the browser; Silverlight is a much reduced framework, focusing on things like UI/media/etc. But with the advantage of cross-patform support, and (with the next version) allowing the client to take it out-of-browser.
The XAML is similar, but is not a strict subset/superset; so you can't always translate "as is" in either direction; it will also be easier to go Silverlight-to-WPF/XBAP
With Silverlight 3 on the horizon, I'm not sure I'd bother looking too hard at XBAP myself... if I wanted the full .NET, I'd go WPF/ClickOnce.
And I'm pretty sure Silverlight doesn't use presentation host...