Click here to Skip to main content
15,312,009 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
I need to move a large 32-bit ActiveX DLL created with VB6 that works fine in IIS7, but a new requirement is that the functions inside need to be 64-bit. Since VB6 does not do 64bit, does anyone know of a path to take? The component uses ASPTypeLibrary and COM+ for getting querystrings, forms elements, and eventually response, and this can be changed if needed.

Thanks
Posted

VB6? 64-bit instruction-set support? Just forget it.

See, for example: http://stackoverflow.com/questions/1167102/can-a-vb6-component-be-compiled-to-64-bit[^].

Of course, you can use it on 64-bit systems, bit only with x86 (32-bit) processes which are supported by WoW64: http://en.wikipedia.org/wiki/WOW64[^].

And, generally, VB6… (sigh)… please see this recent thread: my question is about visual basic 6[^] :-).

[EDIT]

I'm sure the most viable solution would be to migrate to, for example, VB.NET.

—SA
   
v3
Comments
CHill60 23-Aug-13 11:48am
   
The OP is asking for a conversion path from VB6
Sergey Alexandrovich Kryukov 23-Aug-13 12:01pm
   
Ah, thank you for this note. I answered in an updated question, please see see after [EDIT].
Besides, I added a comment to point out that the limitation is only for in-process components.
—SA
onemorecoke 23-Aug-13 11:53am
   
Hi Sergey, I am not trying to stay with VB6 and is why I am asking the question to see what path people have taken. I have this project given me that I need to create a solution to it. I have this code in VB6, and the website uses classic ASP, that is the reality I am dealing with. I cannot re-write the webpages, so I have to be able to do a CreateObject in ASP to get at the public functions in the ActiveX or some other object that I am trying to discover being out there.
Sergey Alexandrovich Kryukov 23-Aug-13 11:59am
   
My thing here is just to advise, and you think by yourself.

However, I answered your question about 64-bit in full. No 64-bit, period.
By this is for in-proc components. If you can use server COM component (not in-proc), the processes of different incompatible instruction-set architectures can work together.

Will you accept this answer formally (green button)?

—SA
onemorecoke 23-Aug-13 12:18pm
   
If I marked your answer to accept, it would not be a benefit to the community. I always appreciate your input Sergey, but I think in this case there is more to be discovered :)
Sergey Alexandrovich Kryukov 23-Aug-13 16:54pm
   
I don't know what benefit do you mean, but it's not a problem at all, it's up to you. However, I'm telling you: you should migrate to .NET, if you need anything resembling VB, this is the only real option.
However, if you migrate everything to .NET, you won't need COM at all.
—SA
Ron Beyer 23-Aug-13 12:08pm
   
(Note to the questioner (questionee?)): You can expose .NET to COM operations just like they were ActiveX objects, see:

Exposing .NET To COM (pay attention to the very last answer)
MSDN .NET COM Operations
Another good tutorial

But be aware, the transition from a "large vb6" library to .NET will be very painful, you will have to rewrite a lot of it. Try not to do a 1->1 conversion, .NET has some features that weren't available in VB6 that may make your life a lot easier.
Sergey Alexandrovich Kryukov 23-Aug-13 12:11pm
   
Yes, good links. I think you better put it as a formal answer.
—SA
onemorecoke 23-Aug-13 12:23pm
   
Thanks Ron, good stuff. I was able to convert the VB6 functions to vb.net 2012 at one point, and then make the DLL COM visible. There were two issues though: The problems I ran into was getting at the RESPONSE, REQUEST, and SESSION objects as I did in the VB6 ActiveX DLL. Though it did work it failed sometimes so I was thinking I was trying to use OLD technology in a new environment. The other was that I was not certain if the COM visible vb.net DLL was actually working in 64 bit mode. So at the time I abandoned it but now I have to deal with it hard so that is why I was asking if someone had a good path.
Ron Beyer 23-Aug-13 12:08pm
   
Oh, and +5'd.
Sergey Alexandrovich Kryukov 23-Aug-13 12:10pm
   
Thank you, Ron.
—SA
(My comment to Sergey's post as an answer)

You can expose .NET to COM operations just like they were ActiveX objects, see:

Exposing .NET To COM (pay attention to the very last answer)
MSDN .NET COM Operations
Another good tutorial

But be aware, the transition from a "large vb6" library to .NET will be very painful, you will have to rewrite a lot of it. Try not to do a 1->1 conversion, .NET has some features that weren't available in VB6 that may make your life a lot easier.
   
Comments
onemorecoke 23-Aug-13 12:30pm
   
Ron, have you ever dealt with exposing the response, request, and session objects from classic ASP in the VB.NET environment? I tried using the ASP type library and the COM+ component which work in some ways but seemed like a duct-tape solution. I may have to abandon having those three objects available in the .NET environment, which I am thinking might be the case, and that I would just pass the webpage elements I need in the function calls to the new DLL. It would be more work but it might be what I need to avoid completely rewiring the classic ASP webpages right now.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900