1

I have an old VB6 dll usen in a an asp.net website (not webproject) that use that DLL often, but not using the Interop but using CreateObject

objectToCreate = CreateObject("DLL.Class")

Now we have to register the dll anytime there is a new version of that, and also we have to register on the production server, with the risk of forgot that step

I try to do as explained here with:

<ItemGroup>
  <COMFileReference Include="MyComLibrary.dll">
    <EmbedInteropTypes>True</EmbedInteropTypes>
  </COMFileReference>
</ItemGroup>

I paste that in the .pubxml file of my site but nothing works, i try to unregister the dll in the server and i always get that i cant create ActiveX object

What can i try?

DrViente
  • 37
  • 1
  • 7
  • Do you have some installer (can be as simple as cmd/vbs/powershell script) for upgrading your app on server? If yes, then registering COM dll is task for installer. BTW, your excerpt form linked question helps build process, not run process. – Arvo Sep 21 '20 at 10:44
  • @Arvo unfortunatly no installer, I know that link helps for build, for me is ok to include in the build process, but still nothing happen – DrViente Sep 21 '20 at 11:50
  • Build process doesn't help you. You should look at the MS article (taken from linked question), step 6 and further: http://msdn.microsoft.com/en-us/library/ms973913.aspx – Arvo Sep 21 '20 at 13:11
  • @Arvo it can't work i'm in an asp.net website – DrViente Sep 21 '20 at 13:52
  • keep in mind you need to force your .net project to run as x32. You can't thus use ANY cpu, and will need to force and set project to x86. However, since the .dll does work (or did work), then I assume your process(s) are running as x32, since you can't use x32 or create x32 bit process or object when running as x64 bits. – Albert D. Kallal Sep 21 '20 at 16:20
  • Well, if asp.net doesn't create anything executable, then you can't use manifest also. I would suggest recreating your VB6 DLL with binary or at least project compatibilty - this way createobject() will work even after dll upgrade. Anyway some kind of setup/installer would be creatly prefrerred; you currently can't even create test environments correctly (not mentioning "the risk of forgot that step", what is absolute no-no for live installations). – Arvo Sep 21 '20 at 17:51
  • @AlbertD.Kallal my project already run on x32 because of the limitation of that dll – DrViente Sep 22 '20 at 07:14
  • ok, so the idea and goal (I assume) is to avoid having to do a regsvr32 (and make sure you run the x32 version if that is what you want to try). Now can you do this without requiring that COM object to be registered? From what I read, yes you can do this. I not done this, but a answer here suggests that this is possible: https://stackoverflow.com/questions/11088227/use-com-object-from-dll-without-register – Albert D. Kallal Sep 23 '20 at 01:09
  • @AlbertD.Kallal Unfortunately this doesn't help so much, because even use that c++ code i cant create object useing the interfaces and i can't use that dll manifest because i don't have any .exe – DrViente Sep 23 '20 at 06:51
  • As noted, using binary compatibility in this situation is probably essential - if you do that, then when you update the DLL you would generally not need to re-register it. – StayOnTarget Sep 23 '20 at 11:21
  • Also, I would consider something like https://stackoverflow.com/questions/11088227/use-com-object-from-dll-without-register as a last resort. It might be made to work, but its a pretty big hack. You're better off expending effort getting it to work the way VB6 was designed (as limited as that may be in this case) – StayOnTarget Sep 23 '20 at 11:22
  • @UuDdLrLrSs what do you intend for "binary combability?" ps: I alredy check that link and nothing is good – DrViente Sep 23 '20 at 12:18
  • From what I see, one should be able to use loadlib API. That api is to load external unmanged dll's (not activeX or COM as you have). However, from that loadlib, you can get a handle to the COM create information, and then create a instance of the object based on that. I done this in reverse a tons of times in VBA (to load + consume .net assemblies that been compiled and exposed as COM objects but NEVER registered). Swamped right now, will try and see if I can use loadlib api, and then get/create a com handle from that. Many examples are COM free registration for .net assemblies, not your case – Albert D. Kallal Sep 23 '20 at 22:21
  • Binary compatibility is a standard VB6 compilation setting. If your project is compiled that way, then the DLL will always be compatible with prior versions. I don't know of a perfect stack overflow question on that (there must be) but its readily googled. – StayOnTarget Sep 24 '20 at 19:45
  • As I understand, if I select this option when i compile the DLL, i need to register only first time and then i only need to copy the new file without compile, correct? – DrViente Sep 25 '20 at 07:48

0 Answers0