Multiple independently distributed external modules and shared dependencies? #1241
-
|
Hello! I have a general question about Oqtane modules which are independently built/distributed and dealing with shared dependencies across them. I looked in the documentation and the existing discussions and issues and did not see anything, so I thought I would start a discussion here. I'm going to ignore the mono-repo/mono-deploy vs. many-repo/many-deploy discussion as that is something each team (set of teams) will have to decide on... BUT... If you opt to go the many-repo/many-deploy model and have say A.dll B.dll and C.dll Oqtane module assemblies. Each of which can have its own set of dependencies (underlying framework/BCL bits, third party bits, other shared assemblies you create and manage). So imagine we have a shared assembly Shared.dll (naming is my forte) which contains some business logic you want to share in those modules (for whatever reason). What I'm wondering is how/if Oqtane has methods for dealing with differing versions of the dependent assemblies. E.g. A.dll depends on version 1.0.0 of Shared.dll, B.dll depends on version 1.1.0 of Shared.dll, and C.dll depends on version 2.0.0 of Shared.dll. From what I understand (which is not a strong understanding) Blazor does not use full assembly names for identity of the assemblies and just relies on the filename (e.g. Shared.dll). Which has led me to believe that the shared dependencies can't be different versions once in the browser unless you were to include the version in the file name. I'm hoping that perhaps the above understanding is wrong, or maybe Oqtane has a fix/work-around, or maybe it is just another aspect of juggling multiple external modules which has to be known and planned for? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
|
Oqtane is a .NET Core application and therefore has all of the standard challenges when it comes to multiple versions of shared assemblies. It is up to each developer to manage their dependencies based on their development approach ( ie. whether they create a consolidated project that contains multiple modules and libraries, or if they create a single project per module or library ). |
Beta Was this translation helpful? Give feedback.
-
|
Thanks Shaun. I did not realize that this extended all the way into the .NET ecosystem. Somehow I had convinced myself (incorrectly) that a lot of this had gotten sorted out in .NET Core :( Here is a good Jon Skeet writeup of the situation: https://codeblog.jonskeet.uk/2019/06/30/versioning-limitations-in-net/ |
Beta Was this translation helpful? Give feedback.
Oqtane is a .NET Core application and therefore has all of the standard challenges when it comes to multiple versions of shared assemblies. It is up to each developer to manage their dependencies based on their development approach ( ie. whether they create a consolidated project that contains multiple modules and libraries, or if they create a single project per module or library ).