This means that multi-targeting .net core projects cannot be referenced by VSIX projects, which invoke this target to discover what to include in the VSIX. All is well when using a single
here's a workaround for anyone else in this situation: set <Private>False</Private> on the ProjectReference and then add it manually to VSIXSourceItem
@gulbanana - can you link to an example of the workaround? I've been hit by this as well
not open source, but here are the key changes:
<ProjectReference Include="..\ReferencedNetCoreProject\ReferencedNetCoreProject.csproj">
<Project>{d859ea0b-aa17-4d49-8e30-c18a03625116}</Project>
<Name>ReferencedNetCoreProject</Name>
+ <Private>False</Private>
</ProjectReference>
+ <Target Name="BeforeBuild">
+ <ItemGroup>
+ <VSIXSourceItem Include="..\ReferencedNetCoreProject\bin\$(Configuration)\DependencyOfTheReferencedProject.dll" />
+ </ItemGroup>
+ </Target>
After applying this workaround, I was still seeing the same error message.
The issue was the lines like:
<Asset Type="Microsoft.VisualStudio.MefComponent" d:Source="Project" d:ProjectName="Some.Other.Project" Path="|Some.Other.Project|" />
in the vsixmanifest.
I changed these to include the outputs of the other projects as content, and then just referenced them as files in the vsixmanifest.
The "right" fix here would be for the VSIX targets to respect the new metadata we define to specify what TargetFramework to build references for (dependent on the solution to https://github.com/Microsoft/msbuild/issues/1276).
Right now you can manually specify that in a way that the VSIX collect-reference-outputs mechanism does respect, by specifying AdditionalProperties
on the ProjectReference
items:
<ProjectReference Include="..\Other\Project.csproj">
<AdditionalProperties>TargetFramework=net452</AdditionalProperties>
</ProjectReference>
If you want the outputs of multiple TFs, you must specify the ProjectReference multiple times with different metadata.
FWIW: In practice I found that @sharwell work around in #1580 is more correct here than @rainersigwald. The Reference often needs both the AdditionalProperties and Name elements in order to succeed. In some cases just AdditionalProperties is enough but have run into cases where both were indeed needed.
Most helpful comment
The "right" fix here would be for the VSIX targets to respect the new metadata we define to specify what TargetFramework to build references for (dependent on the solution to https://github.com/Microsoft/msbuild/issues/1276).
Workaround
Right now you can manually specify that in a way that the VSIX collect-reference-outputs mechanism does respect, by specifying
AdditionalProperties
on theProjectReference
items:If you want the outputs of multiple TFs, you must specify the ProjectReference multiple times with different metadata.