none
Updates to EDMX file into dll in Production, without rebuilding dll RRS feed

  • Question

  • Hello Team,

    I would be interested to know how edmx file can be updated w.r.t db changes, without designer in visual studio.

    Problem is that for every db change I need to halt the production and regenerate the edmx and deploy updated dll.

    I have  a following scenario.

    Production abc.dll contains xyz.edmx.

    Developer create own pqr.dll and it has reference to abc.dll.

    Developer can create their own application specific tables into db referred by xyz.edmx.

    Developer uses context of xyz.edmx to perform CRUD on database.

    Observed Result:

    If Developer creates new table,or some change then edmx in abc.dll needs to be updated which is the core application.

    so for just one change in database I have to rebuild production core application dll.

    Expected Result:

    Automatically update production dll's edmx file, so each time no rebuild of abc.dll is required.

    Or please suggest any other alternative, because edmx is tightly bound to dll on which it is created.

    Notes:

    I tried to replace csdl,msl,ssdl files externally but it doesn't work.

    Thank you !

    Best Regards

    Sachin Erande

    +91-7709862546






    Sunday, December 23, 2018 6:33 AM

Answers

  • Hi Sachin Erande,

    >>Automatically update production dll's edmx file, so each time no rebuild of abc.dll is required.

    As far I know, if you update Edmx file, it will be change related entity class, so that you need to rebuild abc.ddl to package related changes into dll. 

    I would suggest that you could create an abc library project with edmx, and in pqr project you could add reference of the abc library project, when you build pdr project, abc project will be rebuild automatically.

    Best regards,

    Zhanglong


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Monday, December 24, 2018 5:50 AM
    Moderator
  • Hi Zhanglong Wu,

    Thanks for your solution.

    Approach suggested seems has limitations when there are multiple developers working on their individual copies of databases, where in they updates central edmx dll, at different times, or accidental creation/deletion of their own pieces of data in database. so faulty central edmx dll, will affect core + all custom dlls.

    have solved, the problem using following approach.

    1. Unique ID for each custom dll + custom edmx's metadata part of connection string will be stored in core database.

    2. Each custom dll will contain an edmx file, which developers updates during development and the edmx's metadata must be stored in separate folder and not embedded in dll.

    (this modifies connection string's metadata property, relative to the folder)

    3. All context instance in custom module to access databases will be created by constructor accepting connection string.

    4. at runtime, when core dll launches custom dll, connection string specific to custom dll will be generated by modifying metadata property of core db's connection string. modified connection string specific to custom module is used while accessing custom modules context.

    This works great !

    Thank you very much for your proposed solution, that could also solve my problem. Marking as answer.

    • Marked as answer by Sachin Erande Thursday, December 27, 2018 1:01 PM
    Thursday, December 27, 2018 1:01 PM

All replies

  • Well, you can go to EF Code first to eliminate the EDMX file that is only used to build the conceptual virtual object model, which are the classes derived from the EDMX that EF DB first uses, and the EDMX is used for the graphical view of the model in the VS project..

    And besides,  EF Core DB first doesn't use an EDMX anymore, which is the future of EF usage. So you might as well get use to not using an EDMX.

    Also, the EF wizard used in EF 6 using the Code first approach can build the virtual object model from an existing DB and not use an EDMX.

    https://docs.microsoft.com/en-us/ef/ef6/modeling/code-first/workflows/existing-database

    However the classes get changed by using EF Code first or DB first, you have to redeploy the executable the project creates that is using EF.

     

     
    Sunday, December 23, 2018 7:23 AM
  • Hi Sachin Erande,

    >>Automatically update production dll's edmx file, so each time no rebuild of abc.dll is required.

    As far I know, if you update Edmx file, it will be change related entity class, so that you need to rebuild abc.ddl to package related changes into dll. 

    I would suggest that you could create an abc library project with edmx, and in pqr project you could add reference of the abc library project, when you build pdr project, abc project will be rebuild automatically.

    Best regards,

    Zhanglong


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Monday, December 24, 2018 5:50 AM
    Moderator
  • Hi Zhanglong Wu,

    Thanks for your solution.

    Approach suggested seems has limitations when there are multiple developers working on their individual copies of databases, where in they updates central edmx dll, at different times, or accidental creation/deletion of their own pieces of data in database. so faulty central edmx dll, will affect core + all custom dlls.

    have solved, the problem using following approach.

    1. Unique ID for each custom dll + custom edmx's metadata part of connection string will be stored in core database.

    2. Each custom dll will contain an edmx file, which developers updates during development and the edmx's metadata must be stored in separate folder and not embedded in dll.

    (this modifies connection string's metadata property, relative to the folder)

    3. All context instance in custom module to access databases will be created by constructor accepting connection string.

    4. at runtime, when core dll launches custom dll, connection string specific to custom dll will be generated by modifying metadata property of core db's connection string. modified connection string specific to custom module is used while accessing custom modules context.

    This works great !

    Thank you very much for your proposed solution, that could also solve my problem. Marking as answer.

    • Marked as answer by Sachin Erande Thursday, December 27, 2018 1:01 PM
    Thursday, December 27, 2018 1:01 PM