회사 제품을 개발하면서 MSIX 패키징을 하는 WPF 앱을 개발하고 있습니다.
MSIX를 선택한 이유는 큰 이유는 없고, 앞으로 winapp cli를 통해 개발도 자동화 할 수 있는 MS에서 밀고 있는 차세대 패키징이기도하고, windows에서 유저레벨에서는 접근이 불가능한 격리 경로에 설치가 되기 때문에 제거도 모든 패키징 기술 중에 가장 깔끔하기 때문입니다.
게다가 빌드 스크립트를 쓸 수 없다는 제약때문에 찌꺼기를 남길 확률도 적습니다.
다만 이렇게 유연하지 못하게, 아무것도 못하게 해버리니 (스크립트 지원 안해줌)
inno setup이나 Wix, NSIS 처럼 intaller를 통해 여러 행위를 못한다는 점입니다.
그래서 설치과정에서 option으로 .net 설치도 불가합니다.
그래서 self contained 옵션도 고려해봤지만, msix 패키징 시 wpf 앱 하나 뿐아니라 여러 .net 콘솔앱이 side-car 형태로 함께 나가기 때문에 그 .net 어셈블리도 모두 self contained를 하기엔 패키지 용량이 점점 커졌습니다.
심지어 plugin을 지원하고 있었는데 dll 중 하나가 aspnetcore를 참조해야 했기 때문에 의존이 걸려서 wpf와 console 앱으로 구성된 서비스이지만, aspnetcore 런타임도 필요한 상황이었습니다.
해당 dll을 visual studio에서 빌드 할 때 의존성에서 제거하고 runtime에서 plugin으로 참조하려했더니 역시 실패했습니다. (빌드단계에서 aspnetcore 런타임을 의존하지 않기에 plugin 참조 실패)
따라서 회사 앱을 windows에서 실행하려면 .net desktop runtime과 .net aspnetcore runtime이 모두 필요한 상황입니다. 그런데 dotnet 다운로드 사이트에 가면 통합 installer는 없고 runtime들이 다 각자 다운로드 하도록만 되어있어서 1개만 설치해서 .net 통합 런타임 환경이 되려면 sdk를 설치할 수 밖에 없더군요.
그런데 고객입장에선 개발할 것도 아닌데 sdk의 의미를 가진 플랫폼이 설치된 다는게 싫은 고객도 있을꺼라 이런 부분이 불만족스러웠습니다.
닷넷데브에서도 언급된 차세대 도구인 dotnetup 은 이 문제를 해결할 수 있는 것은 맞습니다.
다만 현장의 고객이 터미널 도구를 열어서 dotnetup 도구를 설치해서 선택옵션을 통해 runtime을 설치하라는 것은 개발자가 아니고서야 커다란 진입장벽입니다.
따라서 단순한 그냥 runtime만 통합으로 있는 installer가 필요하다고 생각해서 issue up 하게 되었습니다.
신기한 것은 비슷한 issue를 일단은 저는 못찾았는데 왜 아직도 없을까 궁금한 부분이긴 합니다…