On Wed, Mar 3, 2021 at 08:47 PM, Maxim Batourine wrote:
Sorry, my bad, I forgot some using Simpl yet¡ :-)
?
If not at runtime and in S#Pro it is not a problem¡ at least without re-writing code, never tried to swap real-time¡. And with restart of the program - same app domain is not the issue - program is restarted. I thought conversation was about inability to change transports when changing drivers and not run-time restriction¡.
?
Having S#Pro might solve Simpl transport issue - ?look how PepperDash folks addressed it - S#Pro with driver could run in separate slot, and bridge to SIMPL through EISC.?
Of course, you can still do the same thing in SIMPL if you were to define all 3 wrappers and then choose which symbol you wanted to use depending on the transport you wanted to use... That still doesn't mean that the transports are changeable at runtime though because it involves loading an additional driver for every other transport type you need. (Each driver can only be one of the transport types and not multiple at the same time.) To further clarify what we meant by runtime transport changes, we were referring to the ability for a single driver (dll) to change between IR, Serial, and IP at runtime.
A single AppDomain is an issue (with the current driver framework design) because the driver cannot be unloaded without unloading the only AppDomain that exists for each program on the 3-series platform, which you can't do on 3-series without killing the program itself. This means that outside of the RAD framework, you really can't replace an existing driver that has been loaded into memory with a different one to achieve runtime changeable transports. However, the single AppDomain problem isn't the culprit for this inconvenience, but rather a design fault by Crestron for the RAD framework architecture... It would still be possible to have transport changeable at runtime (even with a single AppDomain), but Crestron is too far invested in the current architecture of the RAD driver framework to change it at this point unfortunately.
SIMPL# Pro won't be any different than SIMPL regarding this topic, since you can't unload a driver to swap it out with a new one, you can only load another driver into memory and neglect that the previously loaded driver even exists.
** Using a separate program slot to address this problem doesn't inherently solve the problem itself, it only serves as a good workaround, and can be done in both SIMPL and SIMPL# Pro.
?
Here is an article about AppDomains:
"Application domains provide an isolation boundary for security, reliability, and versioning, and for unloading assemblies. Application domains are typically created by runtime hosts, which are responsible for bootstrapping the common language runtime before an application is run."
?
--
?
Crestron Service Provider - TBD Enterprises Inc.