R
RobertGustafson
Guest
WHAT I HAVE:
Visual Basic 2019, .NET 4.6.1, Entity Framework 6.4
MY PROBLEM:
I have been trying to write a tool to programmatically take conceptual-model info on an EF model (say, entity-name/property-name-expression) and return the equivalent store-model info (say, table-name/column-name) at run-time--on projects targeted at .NET 4.6.1. I can do the conversion when the MSL mapping file is copied to an external directory (say, the output path), but not when it's embedded in the assembly's resources. My host project has an EF model created model-first, but ideally, a conversion tool should work with any model and be independent of the way the model is set up. I've gotten the following recommendation below, but it doesn't seem to work as yet:
The following code sample (in a class project) was done against EF 6 for getting all models and (meta data) several properties e.g. columns, is primary key etc. Don't remember which version of the Framework I've targeted but most likely 4.6.1 and should work 4.5 looking back at the code. Any ways I've only tested this with code first.
tip provided by
When I make a point of incorporating EntityFramework.dll (Entity Framework 6.4) into References for the EntityCrawler.vb code I pasted, it recognizes the System.Data.Entity.Core namespace and its sub-namespaces (good), but it still gives me 6 compile-time errors: It doesn't recognize the Imports EntityFrameworkHelper.Classes nor anything dependent on that. The project features other files, but I don't know how to download the entire project from Code Developer; what's more, none of those files contain the "missing" information that the compiler is looking for. (BTW, It makes no difference at all whether the targeted platform is .NET 4.6.1 or lower, or .NET 4.7.2 or higher, so far as the sample is concerned--I've tried it at both compiler settings. In any case, I desire a solution that works on the lower platform, as some components in my project don't work correctly on the higher platform [don't ask why]. But the "code sample" above doesn't seem to have "platform versionitis"--so that's good. [Is it?])
(BTW, is the above project actually designed to programmatically return "store equivalents" of the conceptual info? 'Cause that's what I'm after.)
I've looked around the various EF-related namespaces; I've noted that System.Data.Entity.Core.Mappings seems to have methods and classes that may be related to getting store info from conceptual entities and properties, but it's hard to say, since online (web) documentation is scant, and I can't seem to find out where to obtain instances of these classes from an existing currently-executing EF model. I've noted the System.Data.Entity.Core.Metadata.Edm has CsdlSerialization and SsdlSerialization methods for getting XML for the CSDL (conceptual-only) and SSDL (store-only) metafiles, but no MslSerialization method for getting the XML for the conceptual-to-store mapping--which is what I want!! System.Data.Entity.Core.Common has methods for getting the DbProviderManifest/DbXmlEnabledProviderManifest info and exporting it into an XmlReader using the GetInformation method, but neither StoreSchemaMapping or StoreSchemaMappingVersion3 seem to get the conceptual-to-store XML of the MSL metafile! (It's more like XML for very rudimentary stuff instead; the use of the term "mapping" in the enums is deceptive here!)
I know there must be a way to get the mapping data at run-time when it's stored as a resource (rather than a separate file); I just can't seem to figure out how. I know that many programs don't need to do this, but my program is different, since I need to create supplementary indexes on the store, and would prefer to stick with conceptual names so that the programmer-generated source code doesn't need to keep track of the mapping manually.
Finally, I know this has been posted before multiple times with different wording, but I haven't gotten any recent responses to the earlier posts, so I want to be sure this--with my updated perspective--is noticed. Forgive me for being redundant, but I'm trying to put this part of my project behind me, and I know squeaky wheels are more likely to get greased.
Robert Gustafson
Continue reading...
Visual Basic 2019, .NET 4.6.1, Entity Framework 6.4
MY PROBLEM:
I have been trying to write a tool to programmatically take conceptual-model info on an EF model (say, entity-name/property-name-expression) and return the equivalent store-model info (say, table-name/column-name) at run-time--on projects targeted at .NET 4.6.1. I can do the conversion when the MSL mapping file is copied to an external directory (say, the output path), but not when it's embedded in the assembly's resources. My host project has an EF model created model-first, but ideally, a conversion tool should work with any model and be independent of the way the model is set up. I've gotten the following recommendation below, but it doesn't seem to work as yet:
The following code sample (in a class project) was done against EF 6 for getting all models and (meta data) several properties e.g. columns, is primary key etc. Don't remember which version of the Framework I've targeted but most likely 4.6.1 and should work 4.5 looking back at the code. Any ways I've only tested this with code first.
tip provided by
When I make a point of incorporating EntityFramework.dll (Entity Framework 6.4) into References for the EntityCrawler.vb code I pasted, it recognizes the System.Data.Entity.Core namespace and its sub-namespaces (good), but it still gives me 6 compile-time errors: It doesn't recognize the Imports EntityFrameworkHelper.Classes nor anything dependent on that. The project features other files, but I don't know how to download the entire project from Code Developer; what's more, none of those files contain the "missing" information that the compiler is looking for. (BTW, It makes no difference at all whether the targeted platform is .NET 4.6.1 or lower, or .NET 4.7.2 or higher, so far as the sample is concerned--I've tried it at both compiler settings. In any case, I desire a solution that works on the lower platform, as some components in my project don't work correctly on the higher platform [don't ask why]. But the "code sample" above doesn't seem to have "platform versionitis"--so that's good. [Is it?])
(BTW, is the above project actually designed to programmatically return "store equivalents" of the conceptual info? 'Cause that's what I'm after.)
I've looked around the various EF-related namespaces; I've noted that System.Data.Entity.Core.Mappings seems to have methods and classes that may be related to getting store info from conceptual entities and properties, but it's hard to say, since online (web) documentation is scant, and I can't seem to find out where to obtain instances of these classes from an existing currently-executing EF model. I've noted the System.Data.Entity.Core.Metadata.Edm has CsdlSerialization and SsdlSerialization methods for getting XML for the CSDL (conceptual-only) and SSDL (store-only) metafiles, but no MslSerialization method for getting the XML for the conceptual-to-store mapping--which is what I want!! System.Data.Entity.Core.Common has methods for getting the DbProviderManifest/DbXmlEnabledProviderManifest info and exporting it into an XmlReader using the GetInformation method, but neither StoreSchemaMapping or StoreSchemaMappingVersion3 seem to get the conceptual-to-store XML of the MSL metafile! (It's more like XML for very rudimentary stuff instead; the use of the term "mapping" in the enums is deceptive here!)
I know there must be a way to get the mapping data at run-time when it's stored as a resource (rather than a separate file); I just can't seem to figure out how. I know that many programs don't need to do this, but my program is different, since I need to create supplementary indexes on the store, and would prefer to stick with conceptual names so that the programmer-generated source code doesn't need to keep track of the mapping manually.
Finally, I know this has been posted before multiple times with different wording, but I haven't gotten any recent responses to the earlier posts, so I want to be sure this--with my updated perspective--is noticed. Forgive me for being redundant, but I'm trying to put this part of my project behind me, and I know squeaky wheels are more likely to get greased.
Robert Gustafson
Continue reading...