Hi @CyrusDaVirus,
Thanks, that’s really helpful - and interesting, since on 4.8 System.ValueTuple is already part of the framework, so the failure there points somewhere other than what we’d assumed.
To get us both on the same page, I’ve attached a small COM sample (GroupDocsComRepro-Sample.zip) - a minimal [ComVisible(true)] class called via CreateObject, with both a test.vbs and a test.asp. On our side it works fine, so could you build it and run it on the machine where it fails? The README has the steps.
If it fails for you too, please let us know whether it’s test.vbs, test.asp, or both, and the exact error text. There’s also an enable-fusion-log.reg in the zip that captures the failing assembly load if you can grab it.
Thanks!
GroupDocsComRepro-Sample.zip (7.1 KB)
Hi @boris.katin , yes it works with a .DOCX into .PDF, but not with a .MSG into .PDF
Hi @CyrusDaVirus,
Good news - we reproduced it and worked out what’s going on.
It isn’t COM itself or a particular Windows/.NET version. The MSG (email) conversion path pulls in a set of helper assemblies (System.Numerics.Vectors, System.Drawing.Common, SkiaSharp, System.Text.Json and a few more) that the DOCX path never touches - which is why DOCX works and MSG doesn’t. Two things break those loads when the library runs inside a COM object:
- They get resolved from the GAC or the host process folder, not from your application’s bin folder. A COM object is loaded by an unmanaged host (w3wp.exe for Classic ASP), so the copies sitting next to your component aren’t on the search path.
- Some are also version-shifted - for example the code asks for System.Numerics.Vectors 4.1.4.0 but the package ships 4.1.6.0. In a normal .NET app that’s smoothed over by the binding redirects in app.config/web.config, but under COM that config isn’t read.
Workaround. I’ve attached a small sample (GroupDocsComRepro-Sample.zip) that reproduces the MSG case and applies the fix with two scripts. On the affected machine (as Administrator):
- gac-install.ps1 - puts the dependency assemblies in the GAC so the COM host can find them.
- machineconfig-install.ps1 - generates the binding redirects from the actual assembly versions and adds them to machine.config (which the COM host reads, unlike app.config). It backs machine.config up first and there’s a machineconfig-uninstall.ps1 to revert.
Both scripts take an optional -BinDir so you can point them straight at your deployed application folder:
gac-install.ps1 -BinDir C:\path\to\your\app\bin
machineconfig-install.ps1 -BinDir C:\path\to\your\app\bin
Since the GAC and machine.config are machine-wide, once applied your Classic ASP app picks them up too. The README walks through it step by step.
Could you try the workaround on your setup and let us know how it goes?
GroupDocsComRepro-Sample.zip (12.4 KB)