Do not use HintPath for added metadata references

[tmat]

Instead of

<Reference Include="Lib.dll">
  <HintPath>..\..\Lib.dll</HintPath>
</Reference>

generate

<Reference Include="..\..\Lib.dll" />

@jasonmalinowski:

I (at least, probably @jaredpar too) consider the IDE's form there to be a bug. Because in the simple case, HintPath is looked at fairly late; if the Reference Include simple name can be resolved, the HintPath often gets ignored. We've had plenty of "surprises" over the years, and honestly I wished the second was what we generated. For Roslyn, we just said the second is the only form because the first is a regret.

See full discussion on dotnet/arcade#428 (comment).

[KirillOsenkov]

Note that when you do that (at least in the old project system) the full file path is displayed in solution explorer, not the assembly name. Maybe the new project system will have better support for this case.

Also I believe the order of resolution is controlled by AssemblySearchPaths, e.g.

      {CandidateAssemblyFiles};
      ;
      {HintPathFromItem};
      {TargetFrameworkDirectory};
      {AssemblyFoldersFromConfig:C:\Program Files (x86)\Microsoft Visual Studio\master\Enterprise\MSBuild\15.0\Bin\AssemblyFolders.config,v4.6.1};
      {Registry:Software\Microsoft\.NETFramework,v4.6.1,AssemblyFoldersEx};
      {AssemblyFolders};
      {GAC};
      {RawFileName};
      E:\dd\WTE\Main\bin\dev16\Debug\

Of course the default value of this is terrifying.

If my reading of this is correct, then RawFileName comes after HintPathFromItem, which invalidates the "HintPath is looked at fairly late" statement.

[Pilchie]

This is not a change that we would consider for the old project system at this point, and for the new project system, @nguerrera already changed the default AssemblySearchPaths value in the SDK to be more reasonable.

[nguerrera]

If my reading of this is correct, then RawFileName comes after HintPathFromItem, which invalidates the "HintPath is looked at fairly late" statement.

IIRC, what happens is that RawFileName isn't actually matched by any of the resolvers before it because it's a path, not an assembly name.

@nguerrera already changed the default AssemblySearchPaths value in the SDK to be more reasonable.

CandidateAssemblyFiles are unfortunately still in the sdk default, and still before HintPath This will look for assemblies in your @(Content) and @(None). I originally kept it because my goal was to avoid machine dependence and the output directory race. CandidateAssemblyFiles doesn't have that problem. But, it turns out there are packages with Content files that are dlls and they are a pain. I want to remove CandidateAssemblyFiles from default (breaking change, but I feel it's worth it) in SDK 3.0+.

As I stated on dotnet/arcade#428, with nothing in front of it, I do not see the harm in leaving HintPath.

[inthemedium]

@nguerrera I have many nuget packages that bring DLLs in via None or Content only for the purposes of copying to the ouput folder.

Given the above, what is the ideal setting for AssemblySearchPaths? Should I just drop the {CandidateAssemblyFiles} from the default?

[nguerrera]

@inthemedium I've been away from .NET for a long time, but I would recommend that yes, if nothing has changed. I wish I had dropped it from the default when I had the chance.

[KirillOsenkov]

Yes, no need to include {CandidateAssemblyFiles} in the AssemblySearchPaths