-
Notifications
You must be signed in to change notification settings - Fork 780
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TypeNameCache does not handle type duplicates #539
Comments
@gpomykala there is an Type.AssemblyQualifiedName However, this would create conflicts, when looking up a view for AppNamespace.Views.PersonView, Lib1, Version=1.0.0.0, Culture=neutral, PublikeyToken=5c5619...
AppNamespace.Views.PersonView, Lib2, Version=1.0.0.0, Culture=neutral, PublikeyToken=13cefg... ? |
I am evaluating an assembly aware cache along with an update LocateTypeForModelType ` static IDictionary<Assembly, IDictionary<string, Type>> _assemblyScopedTypeNameCaches = new Dictionary<Assembly, IDictionary<string, Type>>();
|
I have some concerns with adding this capability in much the same way @popcatalin81 does. All of the conventions in CM work off the |
@nigel-sampson i recognize that the scope of changing it properly for all scenarios supported by the framework is much wider than an example I submitted above. Answering your question: ideally it should return Project.Feature.ViewModels.SampleViewModel from an assembly Project.Feature.Views.SampleView was defined in. Just my 2 cents... |
@gpomykala Yes that would work from an application developer perspective. If you're a library author, building a componentized UI library you would want it the other way around, you'd want users to be able to selectively override UI components imported from your library in their applications. The problem is there's no universal best choice here, so there are only two universal solutions in my opinion:
Option 2) Is allot more complicated to support and implement and therefore really needs a compelling use case to make it worthwhile. (One such use case would be reusable View libraries, but this pattern is not really common, even thouhg I've encountered and was pretty neat) |
This is certainly an extreme example, if nothing else I'll probably do an audit to make sure the assembly cache is extensible in the right way such that if someone wants to build a "tie breaking cache" it could be wired in correctly. |
Pushed change to make |
Scenario:
Result: boostrapping fails due to type duplicates being added to TypeNameCache
Although it may not be the best practice to use same types from multiple assemblies within an app it does happen and TypeNameCache should not rely on Type.FullName only as it is not uniquely identtifying information (FullName + assembly is). It would not be too hard to define aggregated dictionary key consisting of assembly name + type name
AssemblySource.Instance.CollectionChanged += (s, e) => { switch (e.Action) { case NotifyCollectionChangedAction.Add: e.NewItems.OfType<Assembly>() .SelectMany(a => ExtractTypes(a)) .Apply(t => TypeNameCache.Add(t.FullName, t)); break; case NotifyCollectionChangedAction.Remove: case NotifyCollectionChangedAction.Replace: case NotifyCollectionChangedAction.Reset: TypeNameCache.Clear(); AssemblySource.Instance .SelectMany(a => ExtractTypes(a)) .Apply(t => TypeNameCache.Add(t.FullName, t)); break; } };
The text was updated successfully, but these errors were encountered: