배포 시 추가 어셈블리가 동봉되는 것을 최소화해야하는 요건을 가진 프로젝트가 있었고, 이를 해결한 방법에 대한 내용입니다.
경우에 따라선 유용한 내용이 될 것 같아 공유드립니다.
DLL을 JS 처럼 import 단계에서 네트워크로 동적 로딩하기
감사합니다.
12 Likes
DLL을 CDN에 올려서 쓴다는건 생각해보지도 못했는데 발상 자체가 놀랍네요
좋은 글 감사합니다.
1 Like
혹시 .NET Core 3.0 이상을 타깃으로 하신다면 AssemblyLoadContext를 이용해 보시는 것은 어떨런지요?
컨텍스트 단위로 언로드까지 가능해서 웹 상에 있는 dll을 실행 중에 새로운 dll로 업데이트 할 수도 있기 때문에 관리가 유연해질 것입니다.
제 경우는 WPF 기반 MDI 앱에서 각 화면을 관리할 때 자동으로 업데이트하는데 유용해서요~
실행 중 새 dll로 업데이트가 필요 없다면 굳이 쓸 필요는 없습니다만, 좀 더 재밌는 결과물이 나오지 않을까 해서 말씀드려 봅니다. 
물론 .NET Framework에서는 못 씁니다.. 
7 Likes
@Vagabond-K 님의 의견과 유사한, 약간은 소소한 딴지입니다.
보여주신 코드는 CDN에 배포된 어셈블리가 변경되면, 앱을 재실행하지 않는 한 업데이트가 반영되지 않는 구조입니다.
그것이 원래 의도하신 바인 듯 하지만, 어셈블리 로딩이 앱 (재)실행 시에만 유효하기 때문에, "동적 로딩"이라는 표현 보다는 “지연 로딩” 혹은 "분산 로딩"이라는 표현이 맞을 것 같습니다.
일반적으로 "동적 로딩"은 어셈블리 업데이트를 앱의 재실행 없이, “안전하게” 반영해야 하는 것을 가리킵니다. VS 코드나 브라우저가 앱 실행 중에 확장을 관리하는 방식이 대표적인 예입니다.
이에 반해, VS 코드 자체 업데이트의 경우 재실행을 요구하기 때문에, 현재 구현한 방식과 일맥상통하는 부분이 있습니다.
4 Likes
(보안 픽스 등 중요도가 높은 패치가 필요한 경우를 제외하고는) 되도록 어셈블리가 변경되는 상황을 만들지 않도록 의도하였습니다.
CDN을 쓴다고해서 로컬에 미리 배포하는 기존 방법과 다르게 자유롭게 업데이트를 허용하고 이런게 아니라
데이터 소스만 바꾼다 방향으로 가는게 기존 방법의 안정성과 안전에 가깝게 유지하는 것라는 판단이 들었습니다.
그래서 Version 값으로 어셈블리 위치를 고정해두고 업데이트가 되더라도 이전 버전이 유지되도록 하였습니다.
하지만, CDN의 장점을 더 활용하는 고민이 필요하기도 하고, 중요도가 높은 패치를 배포해야하는 상황은 있을 수 있습니다.
업데이트가 필요한 상황을 더 고려해서 개선할 방법을 고민해보도록 하겠습니다. 
3 Likes