inconsistent/diverging build outcome from API and dotnet build, msbuild, VS

[ltcmelo]

Version Used: 3.8.0

Steps to Reproduce:

Consider proj.sln with libX.csproj and libY.csproj, and with libY.csproj referencing libX as follows — in
a supposedly bogus .csproj, given that libX is referenced both as a project and as a binary/assembly.

# libY.csproj file
    …
    <ProjectReference Include="..\libX\libX.csproj" />
    …
    <Reference Include="libX">
      <HintPath>..\path\to\assembly\libX.dll</HintPath>
    </Reference>
    …

Despite the duplicity of references to libX from libY.csproj, building the solution proj.sln is successful in all of:

• dotnet build
• msbuild
• inside VS

However, if I have 2 Microsoft.CodeAnalysis.Project objects that mirror the setup I described above — with corresponding ProjectReference and MetadataReferences in "projLibY" for "projLibX" — and attempt to build them, I get a compilation error such as:

error CS1704: An assembly with the same simple name 'libX' has already been imported. Try removing one of the references …

While I'd acknowledge that the csproj file in question isn't really correct, for the sake of consistency with the other building mechanisms (which silently handle the duplication), I'd consider this behavior of the API a bug.

NOTE: In order to reproduce the issue, one might need to ensure that libX.dll is a different binary from that produced by the current build of libX.csproj.

[jasonmalinowski]

@ltcmelo: how did you end up with the Microsoft.CodeAnalysis.Projects that were set up in that way? The Roslyn Project/Compiler APIs are lower-level APIs that won't try to second-guess the inputs given to them: if there is bad data going in, then that should be addressed there. So the compilation error is "by design" in that sense. That said, if you got those projects from MSBuildWorkspace then this would absolutely be a bug since it should be executing the dedup logic that lives in MSBuild. So were these projects you created yourself or got from another API?

[ltcmelo]

@jasonmalinowski the project setup didn't come from MSBuildWorkspace, it came from Buildalyzer.

… if there is bad data going in, then that should be addressed there

Agreed; this could be checked by Buildalyzer (I've actually patched in my code), and the bogus .csproj doesn't make it simpler. Yet, the Project object is assembled with info from recorded log of a sucessfull msbuild invocation, so my argument is at a general level: there's an inconsistency/divergency of behaviour between Roslyn and MSBuild.

I understand that MSBuild is a thing in its own, but the current inability to mirror Roslyn-based builds with those from MSBuild/VS (even though I mentioned Buildalyzer, you can reproduce this specific "manually", filling a Project object with the input of a .csproj file) is a real challenge — under this same spirit, I've been just recently debating about another build-related issue see my NOTE there.

[jasonmalinowski]

Is the code available to look at that's doing the population? My worry is if the ProjectReferences are being populated directly from the in the project file, that isn't going to be correct unless you take a lot of care. (And this is a commonly written bug, see OmniSharp/omnisharp-roslyn#1956 for me fixing that in VS Code...)

[ltcmelo]

Our code isn't open source, but thanks for the pointer @jasonmalinowski ; it's good to know about that.

In any case, the check that I currently do is solely based on the AssemblyName. So it isn't accurate, but it should be OK from a static-analysis standpoint. This is a sort of check that I would expect — or like to see 😉 — to be done at some (build/compilation-related) layer of the API…

[jasonmalinowski]

I guess once we're handed a list of references, we don't know where they came from either due to how it's abstracted and all we could do is an AssemblyName filter. Basically, we can't work around bugs from higher layers without causing other regressions, so closing.