I just got an enhancement request for some VB6 components I wrote way back in 2001.
It just another reminder of the awkward reality that rip out and replace is not always that easy.
When I wrote these components VB6 was the tool of choice for business apps. By the time we were finished integrating all the bits from different suppliers Microsoft had moved on to .net. At that point multiple factories in multiple countries were running our VB6 code – not that easy to rip out!
The system is moving slowly to .net, but with no obvious business benefit, and a whole heap of compatibility testing it is likely to stay a back boiler project.
Luckily as I still do a lot of VBA, the VB6 IDE feels positively space age. I suspect it would be like a bad dream if I worked in VS2008 all day everyday!
Anyone else still writing/maintaining commerical VB6 apps?
cheers
Simon
Smurf on Spreadsheets 
Monday, 27th July, 2009 at 4:21 pm |
We have an app written in VB6, which is getting deployed more and more – I’m not sure if we will upgrade it to .Net.
Part of the project that I’m working on right now has an existing VB6 code base, which is getting maintain/changed in light of project demands, the new bits are getting written in .Net. (having said that this project still pulls heavyweight on Cobol, so VB6 looks like a glint in the milkman’s eye next to that!)
I think VB6 is still out there working hard! I don’t know what will happen when/if MS remove support for it from windows? I guess companies are already writing emulators for it! lol!
Monday, 27th July, 2009 at 7:26 pm |
VB6 still looks good with Excel compared to .NET: better performance, security, integration and distribution, although .Net is narrowing the gaps, particularly with 3rd-party products like Excel DNA, Addin Express, Managed XLL etc.
But the writing is on the wall for VB6: no support, no 64 bit VB6 DLLs and sooner or later Excel and .Net will get together in a satisfactory way – maybe Office 15?
Tuesday, 28th July, 2009 at 7:53 am |
My understanding though is that there is a restriction on the number of .Net versions which may be loaded for add-ins within a single Excel session – namely 1. Is this still the case?
While the writing is definitely on the wall, there is a limited number of ways of adding secure (compiled), GUI functionality to Excel (sans C++). VB6 and Delphi are the only two I can think of. What other practical choices are there?
Cheers – Marcus
Tuesday, 28th July, 2009 at 2:34 pm |
>My understanding though is that there is a restriction on the number of >.Net versions which may be loaded for add-ins within a single Excel >session – namely 1. Is this still the case?
Yeah, but what it is is that the last addin installed, gets the claim for which version to use, and all the other addin them have to use this.
I think this might in practice be a bit of a theoretical issue, I’ve written a few simple VSTO addins and thrown them about and never had an issue. Also, you should be able to test your adding and check that it works with all frame work versions.
>What other practical choices are there?
well .net is the road ahead, and I would say that VSTO is there or thereabouts now. but any com language could be used, I guess it’s that VB6 was such a simple choice that no other langs really bothered to compete.
Tuesday, 28th July, 2009 at 6:48 pm |
> VB6 and Delphi are the only two I can think of.
> What other practical choices are there?
I’m still using VB6 for this (and no other) reason. I’ve analyzed my server logs, and only 2/3 of my site’s visitors have .NET 2.0 or later installed. That’s a pretty big payload to deliver plus anti-piracy protection is a weak point w/ .NET.
Wednesday, 29th July, 2009 at 9:36 am |
> VB6 and Delphi are the only two I can think of.
> What other practical choices are there?
Delphi does not have 64-bit support either. They keep talking about 64-bit but it keeps sliding down their priorities.
Friday, 8th January, 2010 at 4:03 pm |
go to http://vb6stuff.blogspot.com for more source code.