Runtime error after obfuscating: "Unable to cast COM object of type 'System.__ComObject' to interface type..".

[tazzme]

Hi yck1509

thank you a lot for ConfuserEx. I've already used ConfuserEx 3.0 successfully in my .NET 4.5 project which I compiled under Visual Studio 2013. Now I've switched to Visual Studio 2015 but after obfuscation either with 3.0 nor 5.0 a runtime error is produced in my dll: "Unable to cast COM object of type 'System.__ComObject' to interface type 'Microsoft.Office...'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{xxx}' failed due to the following error: No such interface supported (Exception from HRESULT: 0x80004002 (E_NOINTERFACE))".

Do you have any idea why this error comes up?

Thanks a lot.

[sbolofsson]

Are you embedding interop types? If yes, have you tried not to?

[tazzme]

Hi sbolofsson,

Thanks for this hint. I was embedding interop types. Now after setting Embed Interop Types = False (also Copy Local = False, Specific Version = False) I get an Exception when obfuscating:

[ERROR] Failed to resolve a member, check if all dependencies are present in the correct version. Exception: dnlib.DotNet.MemberRefResolveException: Could not resolve method

What can I do? I played around for some while without success.

Thanks again.

[tazzme]

I figured out that this problem was already reported in issue #254 and seemed to be caused by 0xd4d/dnlib#38.

So I checked out the current master of ConfuserEx together with the mentioned dnlib @ b224f70 sources and run the build command.

This build also raised the dnlib.DotNet.MemberRefResolveException...

[sbolofsson]

Hi @tazzme,

I recently experienced the same error message. Basically as far as I can see, there can be 3 causes to this problem:

1. You are missing a dll in the folder containing the dll files, you're trying to obfuscate. Visual Studio is not always so good at copying all references to the output folder (e.g. indirect references, such as libraries referenced by a referenced project).
2. You are referencing libraries that contain duplicate type declarations. If you develop a VSTO addin or something else that uses the PIAs for Office (as your stack trace indicates), you're referencing a lot of COM interop libraries. These libraries contain some duplicate COM interface declarations in the same namespaces. As an example, Microsoft.Office.Core.IRibbonUI is defined in both Microsoft.Office.Tools.Common.v4.0.Utilities.dll, Microsoft.Office.Tools.Common.dll and Office.dll. This is normally not an issue, as the duplicate declarations are ComImports, which means that the "real" interface declarations (and implementations) exist in another assembly. ComImport is usually used for interop with unmanaged code, and as such it is alright that the duplicates exist. The CLR will handle calls to these "proxy" interfaces and does not care in which assembly they are defined. However, the duplicate declarations seem to be a problem for ConfuserEx/dnlib's method resolution. I am not sure whether it is a bug in ConfuserEx or dnlib. A workaround for this problem is described in issue #315. Basically, you have to modify the way dnlib resolves types, such that it ignores assembly comparisons. I guess this should be fine as long as you don't reference any other assemblies with duplicate type declarations that are not ComImports (e.g. different versions of the same assembly) and where the assembly version matters. I guess the best solution would be to use the "extern alias" keyword and explicitly reference the correct namespace from the correct assembly based on the context.
3. Something else :-)

Good luck!

[tazzme]

Hi @sbolofsson

thanks for this hint again. You're right, I am developing an office addin and I think the cause is a duplicate declaration in the office libraries just as you said. I probably referenced them wrongly. When I switched to VS 2015 I did also a refactoring of my code structure and libraries. I hope I solve this soon and can obfuscate the code as I could before with ConfuserEx. This was really cool, after a little bit of research of how to use it, it was easily integrated in the build and deployment process. Thank you guys for your work here.

[yck1509]

Related to #315.