Implicitly injected netstandard.dll facade is not packaged by a vsix project

[srivatsn]

I have a netstandard 2.0 library and I’m referencing that from a regular net461 VSIX project (non-sdk based). When I build the vsix project I see that netstandard.dll gets copied to the output directory because of the injection magic. However, when the VSIX is produced it doesn’t have the netstandard.dll causing the blow up at runtime because it can’t find netstandard.dll.

Looking at the packaging logic, it has some metadata on a ProjectReference about what targets to run to get the set of dlls to package and it runs BuiltProjectOutputGroup;BuiltProjectOutputGroupDependencies;GetCopyToOutputDirectoryItems;SatelliteDllsProjectOutputGroup; by default.

It sounds like the .NET Standard 2.0 facades that are injected by the ImplicitlyExpandNETStandardFacades need to get added to BuiltProjectOutputGroupOutput.

[nguerrera]

I don't think there should be any expectation of netstandard.dll in the output groups of the netstandard library ProjectReference. They are outputs of the consuming net46 project, not the netstandard library.

[srivatsn]

I'm fine with that too - is there an easy way to identify the injected facades so that we can somehow point the vsix tooling to package those into the vsix?

[nguerrera]

Did this work for VSIX -> netstandard1.x refs (deploy system.runtime et al when necessary)? I would think it would already be in at least GetCopyToOutputDirectoryItems of the referring project, but it seems the VSIX project checking its own outputs. Not sure if that is configurable.

[wli3]

I get a repo, bin\Debug does have netstandard.dll in it. However, unzip .vsix file, there is no netstandard.dll and if I copy paste netstandard.dll into it and zip it back, the extension can run successfully.

[wli3]

#433

[wli3]

For some reason the dll has metadata CopyLocal = false as well as Private = false. VSIX target will check for CopyLocal=true to package it.

_ReferencePath_Names
    netstandard
        CopyLocal = false
        FusionName = netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51
        ImageRuntime = v4.0.30319
        OriginalIdentity = C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\\net461\ref\netstandard.dll
        OriginalItemSpec = C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\\net461\ref\netstandard.dll
        Private = false
        ReferenceSourceTarget = ResolveAssemblyReference
        ResolvedFrom = {RawFileName}
        Version = 2.0.0.0

[wli3]

This has already been fixed in master. I validate it with latest VS val(dev test) build since the code is in MSBuild extension.

bc7b4b9 seems to be the fix. however, this is a pretty old and big check in. @dsplaisted Am I pointing at the right code?

From my trace, netstandard.dll does not have the correct meta (private = false) in "ReferencesWithoutConflicts"

We can close it for now, however I do want to dig more about how we fixed it

[dsplaisted]

@wli3 If this was fixed in the build you tested, then it was probably fixed by #1582.

Note that fix is not actually in master yet. It was merged into the 2.0-vs branch and will release in the 2.0.2 SDK along with VS 15.4.