nhibernate
Use Type as PropertyPart CustomType instead of only name
Currently, Fluent NHibernate uses only the case-insensitive name of the type in PropertyPart.CustomType<T>() because it uses the constructor TypeReference(string) instead of TypeReference(Type). This leads to problems if there are two types in the same namespace which only differ in upper case or lower case, e.g. MyProject.Abc and MyProject.AbC. CustomType<Abc>() may result into a wrong mapping which uses AbC instead of Abc (or vice versa). The result depends on the order of the types in the assembly.
My commits fix that problem.
It looks like that the other classes of Fluent NHibernate already use the correct constructor of TypeReference.
I don't know if there are further places in the Fluent NHibernate code which use only case-insensitive names although a concrete Type was passed.
I didn't change the constructor TypeReference(string) to work case-sensitively because someone could depend on its case-insensitive behaviour.
Could you please pull my changes?
TeamCity verified this for 4.0, but I still need to figure out if this is 3.5 compatible
WIll take a look this week. Got lots of stuff on my plate ATM
2017-04-25 15:45 GMT+03:00 visubesy [email protected]:
Any news on this?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jagregory/fluent-nhibernate/pull/347#issuecomment-297018240, or mute the thread https://github.com/notifications/unsubscribe-auth/AALnfLAh6yMbtD4sEYYvfhseuOY10RdLks5rzerbgaJpZM4JE-U3 .
-- Yours faithfully, Gleb
@chester89 or @hazzik: Could you please merge this fix I provided on July 2016?
Could you please merge the pull request? The bugfix of Fluent NHibernate works nicely with one of our products since 2016. It would be nice to have the fix in an official version of Fluent NHibernate. Or do newer versions of Fluent NHibernate support case-sensitive class names? Such class names are caused by obfuscation tools.