From: NHibernate J. <mik...@us...> - 2006-10-24 07:04:33
|
[ http://jira.nhibernate.org/browse/NH-763?page=comments#action_14163 ] Sergey Koshcheyev commented on NH-763: -------------------------------------- Also, I don't think that looking into every resource to find out whether it contains "<hibernate-mapping" is a good thing to do... Looks too much like a hack to me so I'd suggest you only keep this in your application. > NHibernate Does Not Recognize Dependent Resources > ------------------------------------------------- > > Key: NH-763 > URL: http://jira.nhibernate.org/browse/NH-763 > Project: NHibernate > Type: Improvement > Components: Core > Versions: 1.2.0.Beta1 > Reporter: Chris Moore > Priority: Minor > Attachments: HbmResFinder.txt > > SUMMARY: NHibernate will not recognize mapping resource files that are dependent upon their associated domain classes. > DETAIL: Visual Studio/MSBuild uses a "dependency" scheme that can associate a resource file with a given class. This mechanism is used, for instance, to bind RESX files with their associated forms. Among other things, this allows the environment to display the dependent resource files as child nodes of the associated form classes. For example, to associate the hibernate resource "Person.hbm.xml" resource with the file "Person.cs" one would configure the MBBuild file thusly: > <Compile Include="Person.cs"/> > <EmbeddedResource Include="Person.hbm.xml"> > <DependentUpon>Person.cs</DependentUpon> > </EmbeddedResource> > In addition to cleaning up the tree in the project view, this approach also has the advantage of declaratively advertising the extant association between a map file and a domain class. > Now, here is the core of the problem: The compiler will embed the mapping resource with the name of the type with which it is associated "Person" instead of the full name of the file "Person.hbm.xml". In this case, NHibernate will not be able to find the "Person" resource is not found and the assembly registration process will fail because NHibernate currently discriminates mapping resources via the file extension "hbm.xml". > SOLUTION: The assumption that the resource will include the "hbm.xml" extension is made in two places: near line 627 in NHibernate.Cfg.Configuration and near line 55 in NHibernate.Cfg.AssemblyHbmOrderer. Replacing this logic to discriminate, instead, on the content of the file (e.g. determine with a given resource is an xml file with xmlns="urn:nhibernate-mapping-2.0"). > OTHER BENEFITS: Removing the requirment that mapping resource files must be named with the "hbm.xml" extension opens up Visual Studio integration possibilities. One could for example, integrate a custom tool that is designed to edit files of type "*.hbm". > REMARKS: If this fix is accepted, I would be willing to provide the code that would perform this content-based discrimination. Most likely, I would write a "MapResourceFinder" utility class that would do this work. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.nhibernate.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |