Re-Enable Designer on Virtual Machines Option

I suggest to implement the following feature:

A Core.LlSetOption(LlOption.IgnoreContainerType,1) option that suspends checking whether LL is running on a virtual machine.

A typical use case might be:

With LL25, the Designer could also be run on a VM. With LL27 it is no longer possible. Internally LL27 checks the registry key [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control] “ContainerType”, if present it throws the error “The Designer is not available in web applications”. With the new option, the check would be skipped and the designer would be started (like LL25 used to do ;). Deleting registry keys is risky and not a sustainable (nor an elegant ;)) solution.

Many thanks and best regards
Silas

Just to reassure - the check should not generally stop LL from running on virtual machines (Virtual Box, VMware,…), AFAIK only the Windows sandbox mode and Docker images are affected. For the latter, the error makes absolute sense while for the Win sandbox this indeed is a glitch.

True, I did only test the Windows Sandbox. Support suggested it should only happen if ContainerType > 0 but it also happens for ContainerType = 0, until the Key is deleted.

Could you check what the actual value for “ContainerType” is on your end? This value is not documented by Microsoft, if we have a chance to reliably tell the difference between “running on Docker” and “running in Windows Sandbox” we might be able to change the behavior to something more fine-grained. Here is a discussion that revolves around the same topic…

My Win10 and Win11 Sandboxes have ContainerType = 4.

1 Like

I’ll run a survey here - at least for a couple of Docker containers the value seems to be “2”:

C:\>reg query HKLM\system\CurrentControlSet\Control

HKEY_LOCAL_MACHINE\system\CurrentControlSet\Control
    ContainerType    REG_DWORD    0x2

It seems safe to assume the value would be “2” for Docker - we’ll apply this change to LL28.

1 Like

Great. I’ll be looking forward to it. Thanks

© combit GmbH