Hello, until version 25.11 the integration into a COM object was seamless. Since version 25.12, with the integration of the embedded fonts, using Value Tuple, it is no more possible to integrate into COM as it leads to loading issues (linked to value tuple). Can you make one release that is always COM compatible ?
Based on your description, here is a likely technical approach for Aspose.Conversion.
The break‑age is caused by the new System.ValueTuple dependency that the 25.12 build pulls in for the embedded‑font feature; the runtime that COM loads does not automatically resolve that assembly, so the COM registration fails with a “Could not load file or assembly ‘System.ValueTuple…’” error. A quick workaround is to ship a COM‑only wrapper assembly that does not reference the font‑related code (or that removes the ValueTuple reference) and expose only the types you need via [ComVisible(true)], then register that wrapper with regasm. Alternatively, if you can target .NET Framework 4.7 or later, the ValueTuple type is baked into the framework and you can drop the external NuGet, which restores COM compatibility.
// Example wrapper (COM‑visible) without ValueTuple usage
using System.Runtime.InteropServices;
[assembly: ComVisible(true)]
namespace MyConversionComWrapper
{
[ComVisible(true)]
[Guid("D3A1B2C4-5E6F-7A89-0B1C-2D3E4F567890")]
public class Converter
{
public string Convert(string input) =>
ConversionLibrary.Converter.Convert(input); // call into the main lib
}
}
- Could you confirm the exact .NET Framework version you are building the COM object against?
- What is the full error text you see when the COM registration or loading fails (e.g., the “Could not load file or assembly …” message)?
This is not a solution. Using .NET Framework 4.6.2
Hello @CyrusDaVirus ,
This behavior appears unusual on the side of our library. As far as I can see from the release notes for version 25.12, there were no changes related to COM objects.
I have asked our team to double-check your use case. However, to help us speed up the investigation, could you please share a small test project that reproduces the issue?
I look forward to your feedback.
Hello @evgen.efimov
I cannot really share much as it is when you are calling the COM object from Classic ASP (Using CreateObject). But should be reproducible from VB Script as the behavior has to be the same.
The converter class is declared with [ComVisible(true)], a ProgId and a GUID.
Thank you for the clarification.
We have forwarded this information to our development team. As soon as we receive the results of their investigation, we will inform you immediately.
Could you please confirm whether the System.ValueTuple library is referenced in your project?
Our developers recommend adding it, as this may resolve the issue.
If it is not currently included, please try adding it and let us know whether it helps.
Alright, I will pass this information on to our development team.
I will get back to you as soon as I receive their feedback.
Hello @evgen.efimov
Do you have any news on this topic, as my other issue (CONVERSIONNET-8218) seems to be fixed with 26.3, but if this one is not solved, it is unfortunately not useable for me.
Thanks
Hello @CyrusDaVirus ,
Unfortunately, according to our developers, they have not yet been able to fully reproduce and investigate this issue. However, they suggested trying a temporary workaround: explicitly adding a reference to the NuGet package System.ValueTuple to your project.
In .NET Framework 4.6.2, this often helps resolve assembly binding conflicts when ValueTuple is included as a dependency.
You may have already tried this approach, but if not, please give it a try and share your feedback.
The following is referenced, but without success, using v26.3
"
"
Hello @CyrusDaVirus ,
Thank you for the clarification. I have forwarded it to our developers. As soon as I receive feedback from them, I will let you know.
Hello @CyrusDaVirus,
Thank you for the follow-up. The issue is still under active investigation — we have not yet been able to reproduce the COM loading failure on our side, which is what is slowing things down.
To help us close that gap, could you enable the Fusion log (assembly binding log) on the affected machine and share the entry produced when CreateObject fails? That would give us the exact assembly, version, and probing path the loader is failing on.
I’ll update you as soon as I have something concrete.
Hi @nikola.yankov,
My organization prohibits the upload, would you have an email on which I can send you the Fusion Logs ?
Hi @CyrusDaVirus,
Sorry for the long wait on this one. I’ll be straight with you: we still haven’t managed to reproduce the loading failure here, so I want to lay out what we’ve done and ask for one thing that should help us finally pin it down.
We put together a small COM-visible wrapper around GroupDocs.Conversion (ComVisible + ProgId + Guid) and called it with CreateObject from cscript, which goes through the same COM activation as Classic ASP. On 4.7.2 and 4.8 it loads and converts fine every time. That actually fits our current theory, because System.ValueTuple only became part of the .NET Framework itself in 4.7.1 — before that it lives in a separate System.ValueTuple.dll.
We also grabbed the official “4.6.2” .NET Framework Docker image hoping for a clean 4.6.2 box to test on, but that image turned out to be running 4.7.2 under the hood (the Windows Server 2016 base it’s built on has been patched up over the years, and since 4.x updates in place, it can’t go back down to 4.6.2). So no luck there either. The short version is we haven’t been able to get our hands on a real, unpatched 4.6.2 machine like yours, and that’s probably the whole reason this has been so hard for us to hit.
So the thing that seems to matter most is the .NET Framework version actually installed on the machine, not what the project targets. Could you run this on the affected server and paste back what it prints?
$ndp = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full'
[PSCustomObject]@{
DotNetVersion = $ndp.Version
DotNetRelease = $ndp.Release
Windows = (Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion').ProductName
WindowsBuild = [System.Environment]::OSVersion.Version.ToString()
} | Format-List
Once we see the installed release number and the Windows version, we can point you at the exact fix for your setup. Thanks again for bearing with us.
Hi @boris.katin ,
This is very interesting that you cannot reproduce this. On my side, simply on a Windows 11, Windows Server 2016 and Windows Server 2019, all of them present the same issue.
I have tried to convert the project to .NET 4.8, reinstall the packages (v26.3), but, unfortunately, the same behavior happens.
For example on a 2019 Server, these are the versions :
DotNetVersion : 4.8.03761
DotNetRelease : 528049
Windows : Windows Server 2019 Standard
WindowsBuild : 10.0.17763.0