Add Reference 'Extensions' is empty in new NET SDK projects

[vsfeedback]

Create C# project targeting NET 4.6.1. Invoke Add Reference Go to Assemblies - Extensions

Observed: long list with MSXML/MSHTML

Create C# project in new .NET SDK format targeting net461 Invoke Add Reference Go to Assemblies - Extensions

Observed: The list is empty

Expected: list propulated since it the same .NET 4.6.1 target.

Basically makes it impossible to add MSXML or MSHTML via UI.

This issue has been moved from https://developercommunity.visualstudio.com/content/problem/135298/add-reference-extensions-is-empty-in-new-net-sdk-p.html VSTS ticketId: 512696 These are the original issue comments:

Mikhail Arkhipov [MSFT] on 10/20/2017, 11:54 AM (3 days ago):

Also, manually adding <Reference> tag to the project does not work either (build breaks still). Only direct referencing assembly via Browse... works.

These are the original issue solutions: (no solutions)

[AdamDotNet]

As far as terrible work-arounds go, I'm thinking this one isn't the worst possible solution until MSBuild with .Net SDK projects works better:

<Reference Include="Microsoft.mshtml">
    <HintPath>$(MSBuildExtensionsPath)\..\Common7\IDE\PublicAssemblies\Microsoft.mshtml.dll</HintPath>
    <EmbedInteropTypes>True</EmbedInteropTypes>
</Reference>

On my PC, that expands to C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\..\Common7\IDE\PublicAssemblies\Microsoft.mshtml.dll

Simply adding

<Reference Include="Microsoft.mshtml">
    <EmbedInteropTypes>True</EmbedInteropTypes>
</Reference>

And you'll get a warning that the DLL could not be found, along with build errors for missing types.

Although if you are trying to dotnet pack this project, then you won't get the requisite

<frameworkAssembly assemblyName="Microsoft.mshtml" targetFramework="" />

in the resulting nupkg file's nuspec. So that's still a problem...

[BlinD-HuNTeR]

As far as terrible work-arounds go, I'm thinking this one isn't the worst possible solution until MSBuild with .Net SDK projects works better:

<Reference Include="Microsoft.mshtml">
    <HintPath>$(MSBuildExtensionsPath)\..\Common7\IDE\PublicAssemblies\Microsoft.mshtml.dll</HintPath>
    <EmbedInteropTypes>True</EmbedInteropTypes>
</Reference>

The true reason why it doesn't work out-of-the-box in SDK projects, is because .Net SDK explicitly sets the AssemblySearchPaths to ignore it (at Microsoft.NET.Sdk.props):

<PropertyGroup Condition=" '$(AssemblySearchPaths)' == '' ">
<!-- By default exclude GAC, registry, output directory from search paths. -->
<AssemblySearchPaths Condition="'$(AssemblySearchPath_UseCandidateAssemblyFiles)' != 'false'">{CandidateAssemblyFiles}</AssemblySearchPaths>
<AssemblySearchPaths Condition="'$(AssemblySearchPath_UseHintPathFromItem)' != 'false'">$(AssemblySearchPaths);{HintPathFromItem}</AssemblySearchPaths>
<AssemblySearchPaths Condition="'$(AssemblySearchPath_UseTargetFrameworkDirectory)' != 'false'">$(AssemblySearchPaths);{TargetFrameworkDirectory}</AssemblySearchPaths>
<AssemblySearchPaths Condition="'$(AssemblySearchPath_UseRawFileName)' != 'false'">$(AssemblySearchPaths);{RawFileName}</AssemblySearchPaths>
</PropertyGroup>

Then later, at Microsoft.Common.CurrentVersion.targets, it won't try to define AssemblySearchPaths because it's already defined:

<PropertyGroup Condition="$(AssemblySearchPaths) == ''">
...

Because of that, however, we have a better workaround: just restore AssemblySearchPaths to an empty string in your project:

Anywhere in your project:
<PropertyGroup>
<AssemblySearchPaths></AssemblySearchPaths>
</PropertyGroup>

Since Microsoft.NET.Sdk.props is imported at the top, and Microsoft.Common.CurrentVersion.targets is imported at the bottom, this will restore the empty string, and then the AssemblySearchPaths will be recreated with the same logic as old-style projects.

This still doesn't make the "Extensions" section appear in the "Add Reference" dialog, but it will allow you to add those references to your project without a HintPath

[drewnoakes]

@BlinD-HuNTeR thanks for sharing your analysis here. Could you file a bug against https://github.com/dotnet/sdk about the AssemblySearchPath/HintPath issue? That should be looked at separately, and by a different team.