Allow configuring current UI framework to avoid exceptions during dependency registrations #2396
Conversation
…lass in platforms that aren't being used.
| /// <summary> | ||
| /// Platforms or other registration namespaces for the dependency resolver to consider when initializing. | ||
| /// </summary> | ||
| public enum RegistrationNamespace |
There was a problem hiding this comment.
Would prefer this to be a separate non-nested enum.
There was a problem hiding this comment.
I considered that and didn't know in which file it would live - is a neighboring file okay or should it live in some other folder?
| { | ||
| "ReactiveUI.XamForms", |
There was a problem hiding this comment.
The order we previously looked was used as part of our previous tests. It may be best to instead of using a dictionary to use a List. It's only 6 entries so a dictionary probably wouldn't perform better anyway.
|
It looks like I'll have to continue this in a bit. The full build and therefore the test don't run on my machine because I'm missing a lot of the frameworks, and the test did do something other than what I was expecting, so I have some more work to do before this is ready. |
|
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
What kind of change does this PR introduce?
A small feature: A configuration knob to cull the list of registration classes that dependency registration attempts to find, so as to avoid exceptions that are thrown and then caught in the background on every application launch, which has visible effects sometimes if first-chance exceptions are being caught. See #2395 for related discussion.
This is a short-term feature, and the problem will hopefully be addressed in greater detail by construction as part of init being improved (#1737).
What is the current behavior?
Speculatively load all registration classes in all assemblies.
What is the new behavior?
Have a list of "registration namespaces" which can be overridden by the user. The API is not ideal because the API in reality ends up being called from RxApp's static constructor. In real application usage, any parameters has to be passed out-of-band in some way by a method called before the RxApp static constructor and separate from the method where they are used, and so that is what the code does.
What might this PR break?
If setting the registration namespaces was mandatory it would break every app. The list defaults to all of them, which is backwards compatible with the current behavior.
Please check if the PR fulfills these requirements
Other information:
I have added a test which verifies that specifying WPF and running the DependencyResolverMixin will work just the same. It does not check that other registration classes are excluded.