Duplicate symbols for the same types across a solution

[ygra]

We have a Roslyn-based application that for various (stupid in hindsight) reasons used a home-grown parser for .csproj and .sln files. I'm currently trying to use MSBuildWorkspace to replace that part. I made some tests in a separate application and determined that symbols appeared to be unique in the workspace. If I have the following projects

A
B depends on A
C depends on A
... (+ a few more projects with varying dependencies)

and ask each project's compilation for a type defined in A, I get back the same symbol instance every time.

However, in a second solution I have projects arranged similarly, just way fewer of them:

A
B depends on A
C depends on A
D depends on B and C

and here I get different symbols for some types, depending on which compilation I ask in. This also manifests when using SemanticModel to obtain symbol information for various parts of the source code where an IParameterSymbol in project D may have a Type whose symbol is different from the "same" ITypeSymbol in project A.

The projects all target .NET Framework 4.8. With the second solution I have a separate set of projects targeting .NET 6 and there I didn't see duplicate symbols for the same types (or perhaps there were, just not for types that affected program behaviour).

I've been trying around with various ways of loading the projects/solutions, various variants of the project files (also created from scratch twice), to no avail. Is this something to be aware of in general or does that only manifest in certain circumstances that I can somehow avoid?

(I can provide a few more details tomorrow, if needed; today I'm already home.)

[jasonmalinowski]

There is never a guarantee that symbols have the same object identity across projects due to multi-targeting concerns, like where you have some projects targeting different frameworks. This is expected, since from the perspective of a consuming project, the other assemblies being referenced can have type forwards or different members. For example, consider if a type in A inherits from a framework type, and B depends on a newer version of the framework that has additional members, from the perspective of project B, your has additional members which aren't visible if you viewed that same type from project A. So the "base types" are different.

If you look under a debugger at the concrete type of the symbol objects you'll likely see "RetargetingSymbol" in it's name.

Fundamentally ISymbols are not comparable identity-wise, and you should be doing other equality checks or APIs to map types from one project to another. You should update your question explaining what you're trying to do and we can give more concrete advice for what you should be doing here.

[ygra]

That makes sense, but still confuses me a bit that with two different (but similar code) solutions it happens for one but not the other, where all projects target the same framework version.

We already deal with symbols in many places by fully-qualified metadata names, mostly for historic reasons, but this ends up working fine for this case and also for another that has been introduced a few years ago where we react to file-system changes and go over a few syntax trees again (in a changed compilation, thus with different symbols). We also have a custom EqualityComparer for symbols that ends up doing a very similar job, just without converting everything to strings.

We do cache a lot of symbols here and there and probably have to adjust comparing them in most/all places,

The original code (with the custom project parser) also ended up placing everything in a single compilation, which never felt "right" and also ended up having different behaviour from the normal compiler (picking internal method overloads, duplicate assembly attributes, and, helpfully, being able to resolve documentation crefs across unrelated projects). But it probably ended up cementing the current codebase where symbols never changed (because there was only a single compilation). Now I'm thinking whether the change is actually worth it with far-reaching changes just to be more "correct" in how we use Roslyn. All things the change enables are currently unused (obviously) and may remain so in the future ...