RegFree COM for .Net core(net6.0) is looking for wrong dll versions of dependent libraries

[srikrishnagu]

Describe the bug

We are migrating Reg free COM project (server.dll) from .Net framework to .Net core, as per the documentation given here, able to build project successful and also see that COM call reaching to server, how ever the call is failing eventually because of "Could not load file or assembly 'A.b.c, Version=15.0.0.0",

Below are some observations which could help in investigation :-

1. The autogenerated manifest for .Net Core have version 15.0.0.0 (same as what .Net frame work used to have!)
2. During execution all the dependences of Reg free COM project (server.dll) are expecting library with Version=15.0.0.0", thus failing, though valid version of dependent libraries/dll are present in the same binary location.
3. deps.json file has dependent dll/projection version as "0.0.0"

Looks like something is missing or some issue in SDK ? .

To Reproduce

1. Create COM server project having library dependencies within it
2. Have the version mentioned in manifest file autogenerated by .net core
3. Run example E2E and we can see exception on the lines of version not found for dependent libraries

Exceptions (if any)

Further technical details

• Include the output of dotnet --info

.NET SDK: Version: 7.0.400

Runtime Environment:
OS Name: Windows
OS Version: x.y.z
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\7.0.400\

Host:
Version: 8.0.4
Architecture: x64

.NET SDKs installed:
7.0.400 [C:\Program Files\dotnet\sdk]

- The IDE (VS / VS Code/ VS4Mac) you're running on, and its version

[vitek-karas]

Have the version mentioned in manifest file autogenerated by .net core

What exact file are you talking about? .NET Core doesn't really use manifest files for assembly resolution, so things like binding redirects which were common in .NET Framework don't work the same anymore.

[vitek-karas]

/cc @elinor-fung

[elinor-fung]

Looping back here with results of some offline investigation:

• The issue was with a third-level project dependency: A depends on B which depends on C
  • when loadingA, B was successfully loaded, but C was not
• The .deps.json for A did not have the C project listed as a library or have any runtime assets (it was only listed as a dependency of B, not as a library itself)

The build had DisableTransitiveProjectReferences=true, so C was not included in A's deps.json and then could not be found when loading A. @srikrishnagu is looking at their build system to see what changing that looks like.