.NET Framework와 달리 Windows Sandbox 환경에서는 아쉽게도 .NET과 .NET Core 런타임은 공유되지 않는 한계가 있습니다. 그래서 원칙적으로는 샌드박스 환경 안에서 AOT나 Standalone 모드로 빌드되지 않은 닷넷 코어 애플리케이션을 실행하려면 다시 .NET 런타임이나 SDK를 다운로드해야 하는 한계가 있습니다.
독립 실행형으로 빌드되지 않은 .NET 애플리케이션을 빠르게 실행할 수 있는 대안으로, 아래와 같이 가벼운 트릭을 쓰면 쉽게 문제가 해결됩니다.
Windows Sandbox 폴더 마운트 추가 (C:\Program Files\dotnet)
<Configuration>
<LogonCommand>
<Command>powershell.exe -ExecutionPolicy Bypass -File C:\Users\WDAGUtilityAccount\Desktop\Launcher\Launch.ps1</Command>
</LogonCommand>
<MappedFolders>
<MappedFolder>
<HostFolder>C:\Users\UserName\Projects\Launcher</HostFolder>
</MappedFolder>
<MappedFolder>
<HostFolder>C:\Program Files\dotnet</HostFolder>
</MappedFolder>
</MappedFolders>
</Configuration>
위와 같이 dotnet 디렉터리에 대한 폴더를 마운트하도록 지정하면, 바탕 화면에 dotnet이라는 폴더가 마운트된 상태로 Windows Sandbox가 시작됩니다.
그리고 Launch.ps1의 내용은 다음과 같이 작성하면 되겠습니다.
$desktopPath = [Environment]::GetFolderPath("Desktop")
$sourcePath = Join-Path $desktopPath "dotnet"
$programFilesPath = [Environment]::GetFolderPath("ProgramFiles")
$targetPath = Join-Path $programFilesPath "dotnet"
if (Test-Path $sourcePath) {
if (-Not (Test-Path $targetPath)) {
cmd.exe /c "mklink /D `"$targetPath`" `"$sourcePath`""
}
}
이렇게 하면 샌드박스 환경 내의 C:\Program Files\dotnet 디렉터리가 호스트의 닷넷 런타임/SDK 디렉터리와 공유되는 상태가 유지되고, 비 스탠드얼론 상태의 닷넷 애플리케이션들도 손쉽게 실행이 가능했습니다. 닷넷 런타임이나 SDK 자체가 윈도우 버전의 경우에도 레지스트리 설정에 의존하지 않기 때문에 이런 높은 유연성을 보이는 것 같아 흥미로웠습니다. 
ps. 폴더 마운트 개념이 제공되는 다른 VM에도 이런 접근법을 써서 닷넷 런타임을 두 번 이상 설치하지 않고 호스트와 동일 런타임을 공유할 수 있으니 다른 상황에서도 유용하게 활용하실 수 있을 겁니다.