{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.
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.
          
@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?
    Feature-Project-File-Editing
  Editing the project either while open in Visual Studio, or via other mechanism.
    Triage-Approved
  Reviewed and prioritized