.Net Com+ DLL in VB6 - RegFree

[ThiagoPSanches]

I would like to hear your opinion/information about using a .Net Com+ DLL in VB6 without registration.

This would be the DLL:
https://www.easyxls.com/component-excel-library

This DLL requires registration with the "regsvcs" file.

I tried many things described here in the forum (Manifest / SxS) a while ago, but I was unsuccessful... I'm starting to see this again...

Thanks,
Thiago

[rjsnipe]

Just to clarify, is this a .net app and that dll is vb6?

[rjsnipe]

Looking on their site it looks like they have a .net version. Why can't you use that?

[Arnoutdv]

It's the other way around.
The application is VB6 and the DLL is .net

[ThiagoPSanches]

Exactly: The application is written in VB6, and the DLL is a .NET assembly.

The component we have is the COM+ version (not a regular .NET class library), and it was specifically designed for VB6 interoperability.

However, the issue we're facing with regfree usage seems to be related to the fact that this is a COM+ component, not a traditional COM DLL.

[wqweto]

> However, the issue we're facing with regfree usage seems to be related to the fact that this is a COM+ component, not a traditional COM DLL.

You have to explain these "issues" in depth. There is not that much difference between "COM+ component" and "traditional COM DLL" besides activation and transaction participation.

One is out-of-process (COM+) using a surrogate host process so regfree activation is out of the question. This sounds like an "insurmountable issue" but I might be missing something with COM+ activation you are using.

cheers,
</wqw>

[ThiagoPSanches]

Hi wqweto,

I'm trying to make it work using a manifest file, based on examples I found in forum and online.

I've tested a few variations like this one:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <assemblyIdentity type="win32" name="Project1" version="1.0.0.0" />

  <!-- Dependency on .NET CLR -->
  <dependency>
    <dependentAssembly>
      <assemblyIdentity
        name="clr"
        version="4.0.30319.0"
        publicKeyToken="b77a5c561934e089"
        processorArchitecture="x86" />
    </dependentAssembly>
  </dependency>

  <!-- Common controls -->
  <dependency>
    <dependentAssembly>
      <assemblyIdentity
        type="win32"
        name="Microsoft.Windows.Common-Controls"
        version="6.0.0.0"
        processorArchitecture="X86"
        publicKeyToken="6595b64144ccf1df"
        language="*" />
    </dependentAssembly>
  </dependency>

  <!-- EasyXLS .NET COM Interop -->
  <file name="EasyXLS.dll">
    <comClass
      clsid="{ED783240-17F3-3709-96DE-93DCA09DB1BF}"
      progid="EasyXLS.ExcelDocument"
      threadingModel="Apartment" />
  </file>
</assembly>

Also, here's the VB6 code I'm using to test the activation:

Private Type tagInitCommonControlsEx
   lngSize As Long
   lngICC As Long
End Type
Private Declare Function InitCommonControlsEx Lib "comctl32.dll" (iccex As tagInitCommonControlsEx) As Boolean

Public Sub Main()
   Dim iccex As tagInitCommonControlsEx

   With iccex
      .lngSize = LenB(iccex)
      .lngICC = &H200 ' ICC_USEREX_CLASSES
   End With

   On Error Resume Next
   InitCommonControlsEx iccex
   On Error GoTo 0

   ' Test
   Dim a As Object
   Set a = CreateObject("EasyXLS.ExcelDocument")
   MsgBox Not a Is Nothing
End Sub

But I get the following error messages when running the test:

The application has failed to start because its side-by-side configuration is incorrect.
OR
ActiveX component can't create object

[rjsnipe]

create a build output folder with Project.exe, EasyXLS.dll and this file

Project1.manifest

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly
    xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <assemblyIdentity type="win32" name="Project1" version="1.0.0.0" />
    <dependency>
        <dependentAssembly>
            <assemblyIdentity name="EasyXLS" publicKeyToken="632c31013494909a" version="9.1.0.0" processorArchitecture="msil" />
        </dependentAssembly>
    </dependency>
</assembly>

Then run this

& mt -nologo -manifest Project1.manifest -outputresource:Project1.exe;#1

Add the below the the manifest only if you want it to be able to pick up modern windows themes

<!-- Common controls -->
    <dependency>
        <dependentAssembly>
            <assemblyIdentity
        type="win32"
        name="Microsoft.Windows.Common-Controls"
        version="6.0.0.0"
        processorArchitecture="X86"
        publicKeyToken="6595b64144ccf1df"
        language="*" />
        </dependentAssembly>
    </dependency>

[wqweto]

I was suspecting there is no COM+ in sight, neither in manifest nor in code.

Try dependentAssembly tag as already suggested. This is the way to "reference" the manifest embedded in the .Net DLL.

Btw, I'm not sure if these DLL manifests are automatically generated on build for COM interop classes but there is a way to recreate and embed these with mt.exe

cheers,
</wqw>

[ThiagoPSanches]

Hi rjsnipe and wqweto,

Thank you both for your input.

I generated the Project1.manifest as follows:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly
    xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <assemblyIdentity type="win32" name="Project1" version="1.0.0.0" />
    <dependency>
        <dependentAssembly>
            <assemblyIdentity name="EasyXLS" publicKeyToken="632c31013494909a" version="9.0.0.0" processorArchitecture="msil" />
        </dependentAssembly>
    </dependency>
</assembly>

VB6 App (Project1.exe):

Public Sub Main()
   Dim a As Object
   
   MsgBox "Start"
   
   Set a = CreateObject("EasyXLS.ExcelDocument")
   MsgBox Not a Is Nothing
End Sub

I then ran:

mt -nologo -manifest Project1.manifest -outputresource:Project1.exe;#1

However, when executing the app, I get the following error:
“The application has failed to start because its side-by-side configuration is incorrect.”
( The error occurs immediately — the initial "Start" message box doesn't even appear )

I was suspecting there is no COM+ in sight, neither in manifest nor in code.

Try dependentAssembly tag as already suggested. This is the way to "reference" the manifest embedded in the .Net DLL.

Btw, I'm not sure if these DLL manifests are automatically generated on build for COM interop classes but there is a way to recreate and embed these with mt.exe

cheers,
</wqw>

Just to clarify, the company behind EasyXLS refers to this version of the DLL as “COM+”:
https://www.easyxls.com/component-excel-library

And we use regsvcs.exe to register the assembly, as described here:
https://www.easyxls.com/manual/troub...ct-failed.html
( I’ve always registered components using regsvr32 )

[ThiagoPSanches]

Adding type="win32" to the manifest fixed the side-by-side activation issue.
Here's the updated Project1.manifest:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <assemblyIdentity type="win32" name="Project1" version="1.0.0.0" />
    
    <dependency>
        <dependentAssembly>
            <assemblyIdentity 
                name="EasyXLS" 
                publicKeyToken="632c31013494909a" 
                version="9.0.0.0" 
                processorArchitecture="msil"
                type="win32" />
        </dependentAssembly>
    </dependency>
</assembly>

Now the application starts, but I'm getting this error:

"Run-time error '429': ActiveX component can't create object"

[wqweto]

> And we use regsvcs.exe to register the assembly, as described here:

Oh, so it's some .Net development I'm not qualified to comment on.

I highly doubt you'll be able to use regfree activation with this component if it's registered under COM+. I would first try running it as normal in-proc COM server as it's hard to fathom what gains using it under COM+ from a *single* threaded evironment like VB6 are expected.

Btw, another remote option is that you might be able to manually simulate what COM+ does by (manually) running dllhost.exe (or whatever) with just the right parameters so that it hosts your DLL and registers it's class factories in ROT but I've never done this or heard anyone here doing it.

cheers,
</wqw>

[ThiagoPSanches]

> And we use regsvcs.exe to register the assembly, as described here:

Oh, so it's some .Net development I'm not qualified to comment on.

I highly doubt you'll be able to use regfree activation with this component if it's registered under COM+. I would first try running it as normal in-proc COM server as it's hard to fathom what gains using it under COM+ from a *single* threaded evironment like VB6 are expected.

Btw, another remote option is that you might be able to manually simulate what COM+ does by (manually) running dllhost.exe (or whatever) with just the right parameters so that it hosts your DLL and registers it's class factories in ROT but I've never done this or heard anyone here doing it.

cheers,
</wqw>

Thanks anyway, wqweto — I really appreciate your time and input.

[rjsnipe]

It looks like just a normal .net com dll.

Can you confirm the line in your code that throws the error?

[rjsnipe]

When i say looks like, what i mean is, it is a normal .net framework com dll. It does not use regsvr32 to register, it uses regasm, that supplied RegSvcs.exe must be made by them to do the registration and likely just calls regasm. Which is totally confusing.

You might need to generate a manifest as wqweto said. run this

& mt -nologo -managedassemblyname:EasyXLS.dll -nodependency -out:EasyXLS.manifest

which is likely enough if it's all deployed in the same folder, you could embed it but it's a signed assembly and it will complain. So in the deployment you would need
Project1.exe
EasyXLS.dll
EasyXLS.manifest

[rjsnipe]

also i notice you use CreateObject. Add the supplied tlb to the project references and then you can strongly type the usage

[Joe Caverly]

that supplied RegSvcs.exe must be made by them to do the registration and likely just calls regasm.

RegSvcs.exe is a Microsoft utility.

C:\...\v4.0.30319>regsvcs.exe
Microsoft (R) .NET Framework Services Installation Utility Version 4.8.9037.0
Copyright (C) Microsoft Corporation.  All rights reserved.

USAGE: regsvcs.exe [options] AssemblyName
Options:
    /? or /help     Display this usage message.
    /fc             Find or create target application (default).
    /c              Create target application, error if it already exists.
    /exapp          Expect an existing application.
    /tlb:<tlbfile>  Filename for the exported type library.
    /appname:<name> Use the specified name for the target application.
    /parname:<name> Use the specified name or id for the target partition.
    /extlb          Use an existing type library.
    /reconfig       Reconfigure existing target application (default).
    /noreconfig     Don't reconfigure existing target application.
    /u              Uninstall target application.
    /nologo         Suppress logo output.
    /quiet          Suppress logo output and success output.
    /componly       Configure components only, no methods or interfaces.
    /appdir:<path>  Set application root directory to specified path.

Joe

[rjsnipe]

ah i see, my bad. I didn't realise there was a separate .net exe for registering but see now it's for com+ .net.

If the classes you want to use are deigned to be used in process you should be fine but that depends how they have written it. Can you give an example of the usage of the library?

[rjsnipe]

Just to bring it all together.
If you do the 2 things i detail above it will work with registration free com (I've tested it), however depending on the implementation details of the dll it might not actually do what you need it to if it needs some com+ infrastructure but as wqweto said "it's hard to fathom what gains using it under COM+" so your chances are good. They also have a non com+ dll so if you were really commited to the goal and this does not work, then you could wrap that with your own vanilla com classes for just the bits you need, or more likely just minimise the calls you actually need to do in vb6 and do most of it in .net

[rjsnipe]

Just to bring it all together.
If you do the 2 things i detail above it will work with registration free com (I've tested it), however depending on the implementation details of the dll it might not actually do what you need it to if it needs some com+ infrastructure but as wqweto said "it's hard to fathom what gains using it under COM+" so your chances are good. They also have a non com+ dll so if you were really commited to the goal and this does not work, then you could wrap that with your own vanilla com classes for just the bits you need, or more likely just minimise the calls you actually need to do in vb6 and do most of it in .net

[ThiagoPSanches]

Hi rjsnipe,

Thanks so much for your support!

I’m very keen to get this working.

How did you get it to run without any registration?

I’ve tried everything you suggested:

Using the real type instead of CreateObject

Dim a As EasyXLS.ExcelDocument
MsgBox "Start"
Set a = New EasyXLS.ExcelDocument
MsgBox Not a Is Nothing

Compiled on a machine where the DLL is registered, but I get:

Run-time error '-2147221164 (80040154)': Class not registered
This error occurs on the line Set a = New EasyXLS.ExcelDocument.

Embedding a manifest in EasyXLS.dll

EasyXLS.manifest:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <assemblyIdentity name="EasyXLS"
                      publicKeyToken="632c31013494909a"
                      version="9.0.0.0"
                      processorArchitecture="msil"
                      type="win32" />
</assembly>

Command:

 mt.exe -nologo -manifest EasyXLS.manifest -outputresource:EasyXLS.dll;#2

Result:
mt.exe : general warning 810100b3: EasyXLS.dll is a strong-name signed assembly and embedding a manifest invalidates the signature. You will need to re-sign this file to make it a valid assembly.

[xiaoyao]

MAYBE YOUR .NET DLL NEED b.dll,c.dll
you can use vb.net make a new com dll(activex dll) com2.dll,and load you COM++ DLL,so you can free reg,
try

[ThiagoPSanches]

I’m exploring other Excel generation alternatives (there are several great ones mentioned here on the forum, but none as flexible for editing an existing template).

I also considered using the EasyXLS .NET DLL, but we don’t have a license for that version.

[ThiagoPSanches]

MAYBE YOUR .NET DLL NEED b.dll,c.dll
you can use vb.net make a new com dll(activex dll) com2.dll,and load you COM++ DLL,so you can free reg,
try

But that’s not possible, is it? Because to use this COM DLL in .NET I’d still need to register it as well.

[rjsnipe]

try this
https://github.com/rrs/EasyXLS_MRE
clone that, and copy just EasyXLS.dll into the folder.
Uninstall easyxls from your system so that we can reduce possible registry conflicts and also prove that it works with sxs.
run build.ps1 in that folder as admin.

What it does
registers the dll as a com dll, and tell it that it lives here (not the GAC) with /codebase and generate a .tlb for it.
In the vbp you will see it just references the local tlb
Reference=*\G{26DA9604-B96A-464E-959E-2CF1C5D06B5A}#9.1#0#EasyXLS.tlb#EasyXLS v9.1 - library to import, export and convert Excel files
the script then builds the vb6 project
then it patches the manifest (provided)
then it generates a manifest for EasyXLS.dll (but doesn't embed it, it does not need to, although if you want to in the end it will probably be fine to ignore the warning)
then it unregisters the dll.
Now you can copy Project1.exe, EasyXLS.dll and EasyXLS.manifest to some other location or computer and it will work.

Re the com wrapper approach, the point with that fallback (and it's only worth considering if you can't make this work) is if the com+ version uses some com+ specific implementation that means it won't work outside of com+. The fact they have a separate non com+ lib means there is a high chance it will be ok. COM is incredibly pooly documented and they might have implemented it as COM+ just because whoever did it had always done it like that, because that was what they were taught.

What you would do is create your own com library which just wraps the class you need from plain .net easyxls.dll and exposes them over com with your own com classes, you would need to register it for development yes but you would use the same side by side methods above so that you can deploy it registration free, the difference would be their vanilla .net dll does not have anything to do with com+

[ThiagoPSanches]

Thanks for the detailed steps.
I cloned the EasyXLS_MRE repo, copied just EasyXLS.dll into the folder, uninstalled EasyXLS, and ran build.ps1 as admin. I’ve tried:

- Early binding and late binding

- Embedded and separate manifests

- Adding [ComClass] attributes

- /codebase registration and TLB generation

- Unregistering the DLL afterward

- Copying Project1.exe, EasyXLS.dll and EasyXLS.manifest to a clean folder


Unfortunately, I still end up with:

Class not registered / ActiveX component can't create object

[rjsnipe]

do you have another system you can test the build on?

I have tested it on a system that has never seen EasyXLS.

When you run build.ps1, what is the output? in the console?

[rjsnipe]

oh one more thing, do you have their latest version? and x86?
has to be this one

[ThiagoPSanches]

I followed exactly those steps, and the error returned was:

Run-time error '-2146234341 (8013101b)': Automation error
(Tested on multiple environments — Windows 7 and Windows 11)

The output from build.ps1 was all OK, with just a few adjustments needed to correctly point to .\mt.exe.

If you got a different result, please provide all the final files you used — the EXE, DLL and manifest's — so I can test it on my side and compare.

[rjsnipe]

and you confirm it's that version 9.1 and x86?

[ThiagoPSanches]

I'm currently using version 9.0, but just to be sure, I also downloaded and tested with version 9.1, as you suggested.
The CLSIDs are the same in both versions, and I'm always using the 32-bit (x86) version.

[rjsnipe]

Ok, it's just very important it all matches exactly for this test. Making it work for your project can come after.
So to confirm, you did.
Cloned that repo.
Copied that version 9.1 x86 to the same folder
ran build.ps1 as admin.
it all ran fine except you had to add the path to mt.exe? (I have it on my path environment variable)
it didn't complain about not being able to write the manifest to project1.exe? (because it was open by another process, which happened to me, but running again it was fine, the vb6 build must just still have a hold on it sometimes)
what path to mt.exe did you use?
also open EasyXLS.manifest and pluck out the second tag which should look like this
<assemblyIdentity name="EasyXLS" version="9.1.0.0" publicKeyToken="632c31013494909a" processorArchitecture="msil">
and confirm it is the same

[ThiagoPSanches]

I'm currently using Windows 7 - 32-bit.

Here is the modified build.ps1 I used:

& C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe .\EasyXLS.dll /tlb /codebase
& "C:\Program Files\Microsoft Visual Studio\VB98\VB6.exe" /make Project1.vbp /outdir ./ /out build.log | Out-Null
& "C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\mt.exe" -nologo -manifest Project1.manifest -outputresource:Project1.exe;#1
& "C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\mt.exe" -nologo -managedassemblyname:EasyXLS.dll -nodependency -out:EasyXLS.manifest
& C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe .\EasyXLS.dll /u

To run the script, I had to enable:

Set-ExecutionPolicy RemoteSigned

Everything executed without errors. Here is the output:

Microsoft .NET Framework Assembly Registration Utility version 4.8.3761.0
for Microsoft .NET Framework version 4.8.3761.0
Copyright (C) Microsoft Corporation. All rights reserved.

Types registered successfully
The assembly was exported to '...EasyXLS.tlb' and the type library was registered successfully

Microsoft .NET Framework Assembly Registration Utility version 4.8.3761.0
for Microsoft .NET Framework version 4.8.3761.0
Copyright (C) Microsoft Corporation. All rights reserved.

Types unregistered successfully

EasyXLS.manifest generated:
(I removed unused classes to keep it more readable here)

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <assemblyIdentity name="EasyXLS" version="9.1.0.0" publicKeyToken="632c31013494909a" processorArchitecture="msil"/>
    <clrClass clsid="{dc78dbd1-2a45-3bf3-ae4d-e1952358aaaa}" progid="EasyXLS.ExcelChartSheet" threadingModel="Both" name="EasyXLS.ExcelChartSheet" runtimeVersion=""/>
    <clrClass clsid="{ed783240-17f3-3709-96de-93dca09db1bf}" progid="EasyXLS.ExcelDocument" threadingModel="Both" name="EasyXLS.ExcelDocument" runtimeVersion=""/>
    <file name="EasyXLS.dll" hashalg="SHA1"/>
</assembly>

Project1.manifest generated:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
	<assemblyIdentity type="win32" name="Project1" version="1.0.0.0" />
	<dependency>
		<dependentAssembly>
			<assemblyIdentity name="EasyXLS" publicKeyToken="632c31013494909a" version="9.1.0.0" processorArchitecture="msil"/>
		</dependentAssembly>
	</dependency>
</assembly>

Then, I tested running Project1.exe in a folder containing Project1.exe, EasyXLS.dll, and EasyXLS.manifest.
Result:

Run-time error '-2146234341 (8013101b)':
Automation error

[rjsnipe]

That error is suggesting something is off with the .net framework version it's trying to use, or it's not happy about loading the dll for some other reason. Has the virus checker made it readonly or locked the file?

This isn't a copy of the dll where you have emdedded the manifest in it already is it?

If you run
& C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe .\EasyXLS.dll /tlb /codebase
and then open project1 in vb6 ide, will it run?

[rjsnipe]

You need to update your windows 7