Hot Swapping modules (and themes) at runtime in OC.

[rwxzig]

Are there any plans to support the ability to hot swap or upload modules in runtime, and themes too but since they are simply a module, that would fall into the same mechanism.

[hishamco]

AFAIK, @sebastienros mentioned that long time ago, it's not planned for PERF reasons

[rwxzig]

Does it affect the entire system, or only during the load and restart?

[Piedone]

Since that would need a restart of the app anyway what would you like to gain from a hot swap feature?

[rwxzig]

There are a few, on top of my head:

1. you would not need to create a release, rebuild the entire solution.
2. Avoiding CI/CD pipelines to run for rebuilding the entire solution.
3. Less downtime.
4. Allow customers to bring their own modules and themes, developed independently.

[Piedone]

In our experience, neither of these would be better or beneficial:

1. Building the whole solution together with a new project is an important safety check. E.g. if you add a module that depends on a different, incompatible breaking version, you could get a MethodNotFoundException or similar during runtime, while this would be caught during build. Note that you don't have to rebuild the entire solution, necessarily: when you add a new project or change an existing one in a solution that was built previously, MSBuild only builds it and the projects that depend on it (like the root web project). If you run builds on ephemeral CI runners, then you indeed do a fresh build every time by default, but you can optimize that with package caches (our build workflow does this), or even with a custom runner image that has the solution pre-built.
2. See point 1, but I'd add that having a CI pipeline for the deployment itself (i.e. what happens after the binaries were built) is also an important safety step, making sure that the deployment happens the same way every time (avoiding e.g. differences between dev machine setups). It also allows deployments to be triggered other than manually (like with Git commits or chat messages), and you can add automation on top of the deployment (like running tests on the deployed app, something we also do).
3. In any case the downtime only needs to be a restart of the app, regardless of how many DLLs you update.
4. If you're thinking of a SaaS scenario, even if a restricted private one with only select customers, this would be very dangerous, since small honest mistakes could bring down the whole app. For such cases, customization options with much more guardrails like Workflows (including Elsa that also offers C# scripting), server and client-side JS scripting, Liquid templates (going as far as deploying a full theme) are better options.

Granted, not every project needs to makes things extra safe, but a passing build is a fundamental check in every .NET app.

We had such a feature in O1 and it was useless due to the reasons mentioned above. It even had a gallery where you could directly install modules and themes from, what made it a more coherent feature set, but with that it was even more dangerous.

[Skrypt]

1 - You need to build the assembly of your module still. And also make sure that this assembly/module will work with the version of OC that it is trying to install it to.
2 - CI/CD pipelines are there to avoid build and runtime issues by testing these assemblies.
3 - Downtimes are created by the fact that you turn the App Pool off while updating your website. This can be mitigated by using staging in Azure. This can be mitigated by using Docker containers and swapping them live.
4 - Nothing prevents customers to do this, it's up to you to give them access to the source code so that they can do it.

What's I'm basically trying to say is that allowing to install modules on runtime has never been a trouble free experience. Wordpres has its own issues with that. Updating a module doesn't garantee that it won't break your website integrations. This is why using a CI/CD with Unit Tests and Functional Tests is more responsible for that matter.

Having modules installed on runtime would need to be tested which will surely not happen if this module comes from an external source. You want to be able to make testable / predictable changes to make sure what you deploy won't break your entire website.

That's one part of the issues related with it. There's also the fact that technically it's always been a challenge to swap an assembly on runtime. You can install it, but removing it and installing the updated assembly is technically complex and there's never been any easy way to do this with .NET Core.