Shadow copying analyzer assembly loader.

[savpek]

To resolve #1465

Stripped down version from roslyn code base.

[savpek]

Ready for review @rchande @filipw @david-driscoll @mholo65

[filipw]

do we have any known repro steps for a case that could be included as a test?
perhaps something like trying to use an analyzer from a given path and then deleting that path from the test?

[savpek]

Only thing comes to mind is to configure nuget restore folder to local folder next of project and test that it can remove/move nuget packages after startup. That should fail if analyzer dll:s are not shadow copies. Probably RestorePackagesPath will do the trick in csproj.

@filipw can you check pr #1440 because it contains test-assets/test-projects/ProjectWithRulesets/, which could be renamed -> test-assets/test-projects/ProjectWithAnalyzers/ -> can be used part of this test + other thing related analyzers when full e2e is needed.

[filipw]

yes the test infra there looks good there, and is very welcome.

I'd personally prefer the order of merging - first this PR, and only then the other.
Would it be a problem for you to pluck that test infra from that other PR and use it here with a custom RestorePackagesPath as discussed? thanks a lot

[savpek]

Started to implement tests, there's definetly something that i don't understand about analyzer loading from package references yet 😄 They are not loaded as analyzers (item property type doesn't match) but they magically appears anyway. This escalates in tests because they implement something differently and project scoped analyzers doesn't get loaded. It's likely that something has been implemented incorrectly in current version and it's pure luck that it works. I will debug deeper later this week ...

[savpek]

Test idea seems legit (poc made without shadow copying loader).

Problem behind tests was #1458 -> restore must currently be done before host is started on tests, it should reload analyzers when ever restore is done but currently it doesn't behave that way. I will fix that in another pr and write bit dummier version of test in this where restore is made beforehand.

[savpek]

Review fixes ready @filipw

[filipw]

great work - LGTM!

[filipw]

Any pending thoughts @mholo65 @rchande @david-driscoll?

[bjorkstromm]

Why was CachingCodeFixProviderForProjects removed from Project System and Manager? Is it used anywhere else? Reviewing on mobile so I’m probably not getting the whole picture.

[savpek]

@mholo65 i noticed that project has analyzer refecenes available at workspace -> made it lazy. This was refactoring, way it originally should be done if i had better knowledge at that time. By making it lazy with cache it moves loading from startup which makes startup faster and makes startup more robust. Original version failed fatally (and silently, i think few of current issues at load up may be even caused by this) if there was something wrong with project analyzers like locked or missing dll. Noticed that behavior when i tried to replicate locked / invalid dlls for assembly loader.

[bjorkstromm]

@savpek thanks for the response! Checked the earlier PR and saw it was added there. This is great. Thank you!