make project system to automatically refresh reference if missing dll shows up once solution is opened

[davkean]

From @heejaechang on February 23, 2016 20:4

Current project system doesn't track missing metadata dlls (I mean real metadata dll, not cross-language p2p dll). since it doesnt know where the dll is (msbuild doesnt give back resolved path), it won't register file change tracker nor let us know about the dll.

right now, we have 2 workarounds for it. one is doing rebuild inside of VS or clicking reference node in solution explorer.

both of action tells VS to refresh all references which will make VS to go thorough those missing dlls to see whether they exist now.

it would be nice if VS can detect situation where missing dlls are available now, and do reference refresh automatically rather than waiting for explicit user action such as "build" as long as we have some way to guess missing dlls location (since we dont have resolved path). ex, hint path, reference name in path format.

Copied from original issue: dotnet/roslyn#9067

[davkean]

From @Pilchie on May 27, 2016 20:26

Didn't you merge a change for this?

[davkean]

From @heejaechang on May 27, 2016 20:37

no, csproj doesn't have this ability. CPS probably should.

[davkean]

From @jasonmalinowski on May 27, 2016 20:39

The project system was previously not passing DLL paths that didn't exist that it did resolve, and yes, we've fixed that. But at this point the decision to not give us file paths for non-existent DLLs that otherwise had a resolvable path is an MSBuild decision in ResolveAssemblyReferences.

[davkean]

From @Pilchie on May 27, 2016 20:40

So, this should be closed?

[davkean]

From @heejaechang on May 27, 2016 21:4

I think this SHOULD NOT be closed. this was one of issues customers explicitly complained while @morrisjoe talked to them.

basically, they want (however the implementation is) all unresolved references to be resolved (in VS) as soon as those missing dlls get resolved in all context and all cases.

right now, it works for nuget package I believe, also it works when dlls somehow can be resolved by msbuild to certain path even if dll does not exist at this moment.

but when msbuild can't resolve it, those dll will not be resolved automatically until user explicit action such as build, clicking reference node in VS and etc.

this bug is about making sure project system to always work (however it does it) when dlls missing are showed up.

[davkean]

From @Pilchie on May 27, 2016 21:6

I think @jasonmalinowski's point is that if msbuild doesn't resolve them, then there is no way by which the project system can. It doesn't own the logic of how entries in the file are mapped to paths, msbuild does.

[davkean]

From @jasonmalinowski on May 27, 2016 21:15

When RAR runs, it's given two lists; one is our familiar list of Reference items (that can be paths, strong names, all sorts of fun), and one that is an explicit list of paths. When it spits out ReferencePaths, it drops missing files from the first group, but not the second group. I could imagine during design time builds (or whatever CPS calls those) we should still could collect those missing paths, just so that way we know to re-trigger if those paths change.

But this cannot solve the general issue; if I write that's looking in endless numbers of places that we'd all have to watch and track; essentially duplicating the behavior of RAR in the project system.

I agree with @heejaechang that this shouldn't be closed, at least to fix the one specific scenario I've described. It may also require a MSBuild fix, but I don't imagine that being that difficult to do. That would be helpful in various NuGet scenarios and we should pursue that. We should still move this to the project system repo since that's where the work is going to get done anyways.