|
Appropriate, sure. I am one that totally agrees with you as I once had to deal with a pile of VB6 and it is no fun at all.
As for getting signoff or access to resources or getting people to actually want to be forward thinking that are the final decision makers? This is a completely different issue and the bigger the company, expect the least ideal option being selected. And no it won't make sense. And yes, you will be frustrated greatly.
|
|
|
|
|
There is no doubt that C# is a solid move, provided that is in your skillset. If not vb.net is not going away as fast as everyone says. It was supposed to be gone in 2010,2015, 2019, 2022 and there are still MANY that use it. I have a friend who converted all of his work to C# and started his own business and nearly all the work he does is vb.net, not conversions. just vb. So until everyone makes the switch it will exist and probably till the end of my lifetime.
|
|
|
|
|
Is VB.NET the target? The OP isn't clear regarding that, although his statement can be taken that way. The wording indicates .NET Framework, not a newer version.
That said, I agree, C# is a better choice for the reasons you stated. At the time, VB.NET was a panacea for the extensive VB community, but as time has passed, so has the need for VB.NET, and MS has done less and less with it.
I'd target Framework 4.8.1 instead of a CORE release.
Why? Lifecycle. Framework has a lifespan as long as Windows contains it, which is 2029 for Win10, and I'm haven't checked for Win11.
Even versions (v6, v8) of CORE have a 3 year lifespan, while odd versions (v7) have an 18 month lifespan. That places an excessive burden on IT to update applications for which there is no business reason to update.
|
|
|
|
|
Agreed. I've got a bunch of tools I've written over the last 15 years and I'm torn on either using 4.8.1 or .NET 8.0 for the lifetime. It's entirely possible that .NET is going to outlast .NET Framework and the tools I'm involved with can be used for 20+ years, some of them are over 15 years old now.
It would be nice if MS slowed the pace down a bit so the real word can catch up.
|
|
|
|
|
Yeah, my preference is .NET web application if possible.
For desktop apps either Uno or .NET MAUI.
All in C#, of course.
I used to be fluent in VB.NET, but use it or lose it, and I'm not using it a lot anymore.
Of course the client gets to have a say in this too 
|
|
|
|
|
The belief that MS is eventually going to kill off VB.Net is incorrect - but only because one person in MS said something incredibly misleading like, "We are no longer going to co-evolve VB.Net and C#."
The reality is that wherever VB.Net and C# are both language choices, MS will update both languages if a new substantive feature is added (except for .NET Framework 4.8). But if MS introduces something completely new, then C# will be the only language available. My thinking is that MS decided that, long term, they don't want to spend resources supporting two languages in every new 'platform' going forward forever. Minimizing duplicate work is a good business decision, and I think that C# was the 'winner' only due to perceived popularity. That decision would have been made several years ago.
The March 2023 TIOBE score rated VB.Net as the 6th most popular language, where C# is ranked 5th. In 2018 VB.Net was ranked 15th and C# was ranked 5th. C# has not moved in rank but VB.Net has moved up by 10 ranks. Hmmm - did MS really make the right choice? I think not.
See this site: TIOBE Index - TIOBE[^] Also, they use 'Visual Basic' for 'VB.Net' - you can read TIOBE's description of why they do this.
I am a VB.Net developer in WinForms. From what I can see - VB.Net is a better language. Not because one language allows for a better user experience - but because it allows for a better developer experience. The syntax is simpler, there's no need to type a semicolon at the end of every line of code, and there are no braces. Also, VB.Net does respect character capitalization in variables - a possible opportunity for error in C#. Does everyone remember KISS? VB.Net = KISS. All other things being equal you can finish an application faster using VB.Net than using C#. Anyone have customers? Customers will call you back for their next project if you can deliver faster. Have wallet? - Need customers!
Both languages compile to the .NET Runtime. They are actually so similar 'under the covers' that you can get an extension in Visual Studio to quickly convert from one language to the other. So why keep using the more difficult and time-consuming language?
Also, using .NET Framework 4.8 is a good choice for a long-term business app that needs solid stability and little maintenance. MS has stated, "As long as there is a Windows OS, there will be a .NET Framework 4.8." The Framework will receive Quality Updates and Security Updates, but not (or probably won't receive) Feature Updates. Winforms already has a long list of features that should satisfy most internal business applications. .NET Framework 4.8 might become the most stable platform available anywhere.
|
|
|
|
|
I came from a huge background in BASIC, from weird varieties in 1979 all the way through modern day VB.NET. The switch to C# wasn't difficult at all. The only thing I hate about VB compared to C# is the verbosity. Less typing in C#, even with the semi-colons, to me, equals more readable, and a quicker read of code.
The point you made in your post as a VB.NET guy, to me anyway, is the MS flip-flopping on the future of VB.NET over the years has put a slightly darker cloud over it, even if it is supported 'til the end of my lifetime. I don't hear any of that kind of talk coming from anyone as MS at all when it comes to C#.
You may find C# more difficult, but not everyone does. I guess it depends on your background. Alongside the VB background, I also dig around in various flavors of assembly, C/C++, COBOL, javascript (yuk!), and others, so curly braces and sparce or esoteric syntax doesn't bother me at all. I get paid by the app, not the character count, and I can bang out an app just as fast.
|
|
|
|
|
DanW52 wrote: The belief that MS is eventually going to kill off VB.Net is incorrect - but only because one person in MS said something incredibly misleading like, "We are no longer going to co-evolve VB.Net and C#."
Nope. "Co-evolution" ceased in 2017, and numerous statements by MS indicate that VB.NET is being maintained, but not "evolved" as C# is.
I suspect MS learned a harsh lesson from the way it killed VB6. Alienating users of the most popular programming tool was amazingly foolish. So VB.NET is being maintained, but no effort is put into it.
It may be that VB.NET has a long lifespan, and it's great for Windows-only applications, but the handwriting is on the wall.
Granted, the list of tools I learned that faded into obscurity or were outright terminated is a long one. Anyone who's been in the industry long enough can probably say the same. It's the nature of the beast.
|
|
|
|
|
Back in 2003, when I was first learning C#, an instructor said that Microsoft was going with VB.net for future improvements and that C# would not last long.
Similarly:
In 2012, Microsoft said that OLEDB was dead and there would not be future versions. Then in 2018 they admitted that OLEDB was too important die and they released a new version -- as I knew they would.
I find it best to ignore any prognostication.
|
|
|
|
|
I migrate VB6 to VB.net and C#. It isn't as difficult as you think. Feel free to contact me by email.
ed
|
|
|
|
|
Slow Eddie wrote: Feel free to contact me by email.
How?
|
|
|
|
|
Sander,
I am incredibly sorry for not replying sooner.
My email is edaymami@outlook.com
ed
|
|
|
|
|
Here is a step-by-step instruction how to install VB6 on Win10. The instructions actually work. And you can find the two CDs with VB in MSDN. It took me a while to get to this information:
Visual Basic Discussion Boards[^][^]
In MSDN search for: "Visual Basic 6.0 Enterprise "
The Visual Basic forum was more aggressive than helpful on the subject, but here is the link: Visual Basic Discussion Boards[^]
Advertise here – minimum three posts per day are guaranteed.
|
|
|
|
|
Sander Rossel wrote: I know there used to be converter tools around, but I've heard bad things about them.
They're usually not worth the effort.
You don't want a converter. There were tools that let yuo integrate .NET into a VB6 app.
Interop Forms Toolkit 2.0 Tutorial[^]
A company I worked for tried a rewrite, and I was specifically told not to go the "slow transition route" by the software lead because it might kill the rewrite. That decision killed the company.
You rewrite critical parts. In a year, the VB6 crap will merely exist to display .NET modules. Then you start a new .NET host for those modules.
Before you do that, you'd want to migrate the database to something that makes more sense.
Yup, been there, got the TShirt. Go slow and steady. DB first, then VB a small victory at a time.
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: Before you do that, you'd want to migrate the database to something that makes more sens
That would have been my suggestion also.
|
|
|
|
|
Having done exactly what you are asking about, here is how I approached the problem.
0: Strip all the code from your forms.
1: Use the converter from VB 2008 to upgrade the forms. (UI only)
2: Paste back in the code, proc by proc, fixing it as you go.
It's a long, slow, boring process.
There's also a company called mobilize.net that I've looked into that seem to do a really good job at migrating VB6 to .Net. Good luck! 
"Go forth into the source" - Neal Morse
"Hope is contagious"
|
|
|
|
|
Sounds like a good time to also review the overall design, make more modular, do some TDD/unit tests, etc.
Sell them on positives....
|
|
|
|
|
My experience is to create the new dotNet VB application from scratch. Use the VB6 source as a guide to what needs to be done. In some cases, I discovered that if I copy/paste the VB6 source into the project and then fix that source it worked wonders.
Gotchas:
- File IO - classic VB file handling is there, but using the new StreamReader and StreamWriter classes are far more efficient
- Event handlers, but at least VB.Net makes these explicit in the code. The order of event firing is different from VB6.
- Error handling: You can leave in the VB6 error handling but I strongly recommend you switch to the Try Catch Finally End Try constructs. I have a few short Subs and Functions where I legitimately use On Error Resume Next, but I document why I'm using this construct.
|
|
|
|
|
look at this post, it may give your ideas...
diligent hands rule....
|
|
|
|
|
You are better off leaving the existing application as VB6 and just do the change to the database layer, VB6 still works perfectly and will continue to do so for a long time.
Then just develop new features in .net when required.
We spent about 5 man years converting one of our applications to VB.Net and now its just as (not)supported by Microsoft as VB6.
|
|
|
|
|
Interesting answer. Really depends on a system analysis but you could be right. That said, VB6 is slated to possibly bite the dust in 10 or so years. Better long-term planning might be to gradually move it to some other platform. It's pretty easy to maintain DB compatibility with multiple platforms.
I don't see VB.net "just as not supported by MS" at all. I'm not saying I wouldn't choose something different, but VB support in VS22 seems to be pretty solid.
|
|
|
|
|
Member 15966771 wrote: VB6 still works perfectly and will continue to do so for a long time.
It works, but that's all you can say about it.
Development and installation are a pain compared to modern solutions.
There also aren't too many developers who are willing to maintain and develop old VB6 applications, especially this one.
Besides, it works because it works for as long as it works.
If Microsoft pulls the plug, which they officially did in 2008, 15(!) years ago, this company can file for bankruptcy.
|
|
|
|
|
My company in a migration process from VB6 right now.
First things first. I don't know anything about you application so anything said down here may not be relevant.
My company have many million lines of code in VB6 and VBA compatible scripting language in the 3 main application. All of the are using the same core written in VB6.
We started the migration 2.5 years ago.
The process is like this.
1. Write a server side C# code and connect old UI to the new (C#, .NET Core 3.1, now upgraded to .NET 6).
1.1. Create core for "migrateable" components.
1.1.1. Connect server-side components to the old UI.
1.2. Migrate those components.
2. Create the new UI (C#, .NET 6, WPF).
2.1. Create core client-side components to show server-side components.
2.2. Migrate client-side UI components.
2.3. Create the tooling.
Many processes are parallel.
The smallest of the 3 main projects will be fully migrated at the end of this year.
The second one is planned to be ready at the end of next year.
Biggest biggest project is planned to be ready in 3 years (likely it will be 5 years).
The good news is that whatever is migrated is used by the customers already.
|
|
|
|
|
We had to do what you have to do big time. But with todays knowledge, I would like to encourage you questioning not only VB.Net vs C#. Depending on the charactor of the application, having a Web Application might be worth thinking about. You may want to have a look at JMIX which is a Java Framework on top of Spring Boot which gives you almost the easy of good old VB6. It gifts you with all the typical features of a modern application and the sample apps they offer could be a good starting point for modifying them to cover the functionality you need. No, I am not getting paid by those folks  ... and I am still a strong supporter of VB (adopted it starting at Version 1.0). But now I heavily rely on JMIX and Windows getting independent from operating systems.
|
|
|
|
|
It's not going to be Java.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
