Open vatsan-madhavan opened 5 years ago
who're working on the project system support for C++/CLI for .NET Core.
/cc @olgaark, @nguerrera
Is this a project system issue? The code in question is part of Roslyn:
What's the expectation here? Clearly we should do better than a crash - but a reference to a module isn't valid.
What's the expectation here? Clearly we should do better than a crash - but a reference to a module isn't valid.
The attached repro project contains a ProjectReference
to a project that produces a module, but it doesn't reference module. i.e., there is no (illegal) reference to the module.
Maybe the issue is that VS is is unable to see the the distinction that a ProjectReference
doesn't always imply that there will be a reference to the projects's outputs?
Note that reference is marked as:
<ProjectReference Include="..\module\module.csproj">
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
<OutputItemType>AddModules</OutputItemType>
</ProjectReference>
Which should mean that it isn't passed as reference, so we have a couple of bugs:
1) We shouldn't crash if someone doesn't specify ReferenceOutputAssembly
2) We shouldn't be passing this module to Roslyn when ReferenceOutputAssembly
is specified.
Probably a combination of Roslyn, Project and MSBuild bugs.
TargetType=module
ProjectReference
it from another projectObserved: VS will crash.
This is what I'm seeing in
CompilationReference.cs
:dotnet/wpf repo is planning on using netmodules it as part of product-binaries, and this would imply that the solution in the repo can not be used/built in VS. It would be great if netmodule-references can be supported in Dev16.4.
module-crash-repro.zip
/cc @rladuca /cc @tgani-msft, @dotnet/wpf-developers