Make sure our assembly resolver always run #272
Conversation
Fixes #267 For some reason, the xaml loader fails miserably when trying to resolve where to load our DLLs from if they're not yet in the process. The directories it's scanning don't include the extension installation path, so it can't find any assemblies that are referenced directly from xaml (using types from other assemblies in code works fine, using them in xaml doesn't). We have an assembly resolver code path as part of our ResourceDictionary implementation (SharedDictionaryManager), so every xaml user control needs to have at least one include that uses SharedDictionaryManager in order to trigger the assembly resolver hook up and ensure that libraries are found.
|
@haacked @grokys @paladique for 👀 and perhaps a commiserating chuckle at the weird bugs we get. |
|
Could adding the assembly resolution to a base class of |
Most of our user controls are subclasses, but not this one haha. But you know, maaaybe I should just add the resolver to the package entry point class instead, that one will always run. :P |
Instead of relying on the xaml controls to include the class that hooks up the resolver, just hook it up on package initialization so it always runs. Also, remove useless base package class, it's not really doing anything useful.
shana
force-pushed
the
fixes/267-property-page-not-loading
branch
from
567105c to
7a88701
Compare
|
There, this will make sure the resolver is always hooked up. |
Yeah, let's get our friends over there to look at it. Perhaps start with @acangialosi and @artl93 to help us find the right person to look at it. |
shana
changed the title
|
@haacked I've created a separate issue for doing the repro of this bug. Is this good to merge? I think I want to do a release with this and some other bugfixes next week. |
|
|
Fixes #267
For some reason, the xaml loader fails miserably when trying to resolve where to load our DLLs from if they're not yet in the process. The directories it's scanning don't include the extension installation path,
so it can't find any assemblies that are referenced directly from xaml (using types from other assemblies in code works fine, using them in xaml doesn't).
The way to repro bug #267 is to set Solution Explorer as the focused pane and then restart VS, so that the next time it starts up it doesn't load Team Explorer by default (which means our assemblies won't get loaded beyond just the package initialization). Then go to Tools / Options and try to load the GitHub property page. It fails miserably.
We have an assembly resolver code path as part of our ResourceDictionary implementation (SharedDictionaryManager), so every xaml user control needs to have at least one include that uses SharedDictionaryManager in order to trigger the assembly resolver hook up and ensure that libraries
are found.
I just moved the styles declarations to a separate file so that we have a good reason to use the
SharedDictionaryManagerhere.This feels like a weird VS bug, probably a good idea to do a small repro for Microsoft.