Mixing different .net versions in a monolith .net application RRS feed

  • Question

  • User-1688449107 posted


    I have a question concerning mixing different .net versions in a single solution. Let's explain from this very simplified high-level design:

    So, we plan to have asp.net core 3.0 mvc based front-end which "talks" to an application services layer in .net standard 2.0. These layers communicate be means of as Shared Layer which contains DTO objects (data transfer objects, simple data objects, in fact view models for the UI) in .net standard 2.0.

    Next, we have a domain model in .net standard 2.0 which is both used by the Application Layer and the Infrastructure Layer which is (and currently should stay) in .net framework 4.8.

    We use Oracle ODP data provider in the infrastructure layer, which maps to the full .net framework (EF6).

    So before proceding and have detailed testing on the ODP Data Provider my questions is : will we possibly have compatibility issues using this proposed architecture, because front is .net core, so main technology is .net core but at a certain level it will have to rely on EF6 which is hosted in the full .net framework ... what kind of troubles may we expect here ?

    Important to note is that we do not use a (decoupled) rest-api in between here, so there are no call's over rest between the core web app and the appservices and infra layer, though we have separate logical layers, all will (currently) be running in a single process on a single machine, so you can see this design as a monolith.

    Thx for any response ! :)

    Kr, Emmanuel Nuyttens

    Sunday, December 8, 2019 12:10 PM

All replies

  • User1120430333 posted

    All you have really is a layered architectural styled solution.


    I don't know what the application layer is about. You could be using the Models folder in th3 MVC project for domain/business logic, view models  and calling a service layer that sits between the presentation layer and the backend layers.  The DTO is used to populate view model objects and visa versa for CRUD with the backend database.




    An MVC model contains all of your application logic that is not contained in a view or a controller. The model should contain all of your application business logic, validation logic, and database access logic. For example, if you are using the Microsoft Entity Framework to access your database, then you would create your Entity Framework classes (your .edmx file) in the Models folder.

    A view should contain only logic related to generating the user interface. A controller should only contain the bare minimum of logic required to return the right view or redirect the user to another action (flow control). Everything else should be contained in the model.

    In general, you should strive for fat models and skinny controllers. Your controller methods should contain only a few lines of code. If a controller action gets too fat, then you should consider moving the logic out to a new class in the Models folder.


    You can use .NET Standard classlib projects  as a conduit between the .NET Framework project and the .NET Core project. 


    The DTO(s) should be traveling through the layers all the way from the persistence layer to presentation layer and visa versa, which are for CRUD operation with the database and to be used at the presentation layer. But the DTO can be acted upon by the domain layer, the business layer, which means that all projects should have refernce to the DTO classlib project so that all projects know about the DTO(s).

    My take on it is that I would take the whole thing to .NET Core 3 and not the mixture of various .NET frameworks. It's not optimal programming and  architecting IMHO.

    Sunday, December 8, 2019 2:55 PM
  • User765422875 posted


    So before proceding and have detailed testing on the ODP Data Provider my questions is : will we possibly have compatibility issues using this proposed architecture, because front is .net core, so main technology is .net core but at a certain level it will have to rely on EF6 which is hosted in the full .net framework ... what kind of troubles may we expect here ?

    .NET Standard is a formal specification of .NET APIs that are intended to be available on all .NET implementations. Your architecture diagram does not make sense in terms of references. For example you have a .NET Standard Application layer referencing a .NET Framework 4.8 Infrastructure layer.

    I see no reason why you do not use .NET Core 3.0 throughout the application and ODP.NET Core

    Also have a look at the implementation support.


    Sunday, December 8, 2019 6:21 PM
  • User-474980206 posted

    this will not work unless you drop back to core 2.1

    core 3.* does not support the 4.8 runtime, so you can not mix core 3.* and 4.8 libraries in the same application. if you must use a 4.8 framework library, then you are limited to using core 2.1, which is the last version of core that will support the 4.8 runtime.

    Sunday, December 8, 2019 6:50 PM
  • User-1688449107 posted

    Yes i also know that this is not ideal in terms of references, but maybe i have to give some more details. This is a proposal that a team member came up with to use a .NET Framework 4.8 in combination with .NET Standard and ultimately with a .NET Core front-end. Apparently Visual studio let you do that, but also in my opinion this looks awkward, but it has to be seen as a temporary "fix", because next Oracle ODP EF Core release which will support EF Core 3 will ship in first production release only by the end of the year (see comment made by Alex Keh - Product Manager at Oracle, link is here: https://community.oracle.com/thread/4286326). So you could see this as a legacy issue we have to currently cope with. My idea was to keep everything in .NET Full 4.8 (Front-App-Infra) (or some in .NET Standard if possible -> e.g. domain layer) and migrate when appropriate, which means after stable release of  Oracle EF Core for .NET Core 3. Wouldn't that make more sense ? Our main concern is the Oracle ODP EF component running in a .NET Full Framework context and used within a .NET Core 3 front-end context. So before we go in the details ourselves the question is if this makes sense and could potentially do more harm then good, or not ? 

    Monday, December 9, 2019 3:42 PM
  • User1120430333 posted

    It might work if a service layer a Standard classlib project sits between the presentation layer and the persistence layer, and the DTO(s) travel through the layers for CRUD operations. The DTO(s) in their Standard classlib project is referenced by all other projects. The usage of the DTO(s) in this manner is an abstraction layer away from the persistence layer,  and it wouldn't matter if the persistence layer was using EF6, EF Core or, Oracle Command object using PL-SQL and packages, becuase all the other projects/layers only see the DTO(s). 

    Tuesday, December 10, 2019 9:28 AM
  • User-474980206 posted

    core 3.* dropped support of running on the 4.8 runtime, so there is no way to call any 4.* library from a version of core greater than core 2.1 LTS

    .netstandard is an api spec. a .netstandard library can run on multiple frameworks. if the .netstandard library calls a 4.8 library, it must be hosted by a 4.8 application. While older versions of Visual Studio may allow core 3.1 calling a .netstandard 2.0 library that references a 4.8 library, it won't run.  

    it would make sense to use .netstandard for all you projects for migration. You should check if your upcoming Oracle core support is EF core only or also EF 6 on core. The migration from EF 6 to EF core is complicated. You probably want to use some repository pattern to make the migration easier.

    your other option is to use tiers. have a core 2.1 webapi that hosts the 4.8 database code, an 3.1 site that hosts the UI. This would be in keeping with modern security, where the UI server does not have direct access to the database. This would allow use of the current razor pages.

    Tuesday, December 10, 2019 2:48 PM
  • User-1688449107 posted

    Yes, this is the ultimate goal to have the application in .net core 3 with support for ODP.NET core, but due to legacy reasons and the fact that ODP.NET Core support for .NET Core 3 is not production ready at this moment we will provide a phased migration, check:

    Juiste antwoorddoor Alex Keh - Product Manager-Oracle op 15-nov-2019 18:58


    Right now, we're planning for an Oracle EF Core 3 beta early in 2020. The production release will depend on the beta feedback and testing results as we proceed.

    Our original beta and production plans got delayed as the dev team assessed the work needed. It's more work than anticipated. Additionally, we made changes in the current Oracle EF Core provider such that the 19.5 version is certified with EF Core 2.1. EF Core 2.1 is the long term MS support release, while EF Core 2.2 is short term. This Oracle EF Core 19.3 version was certified for EF 2.2 only.

    If you would like to be informed of when the beta and production dates occur, you can send an email to dotnet_us(at)oracle.com or subscribe to the Twitter handle @OracleDotNet.




    Emmanuel Nuyttens.

    Wednesday, January 1, 2020 9:19 AM