점진적 Windows Forms 강화

MS에서 계속해서 Windows Forms 고객들의 지원을 강화할 예정이라고 밝힌 만큼 Windows Forms를 계속해서 업데이트 해주고 있습니다.

참고삼아서 .NET 7 업데이트 사항도 링크 올립니다.

What’s new in Windows Forms .NET 7 - Windows Forms .NET | Microsoft Learn

Breaking changes in .NET 8 | Microsoft Learn

심지어 Preview Release 순서중에 1,2번에 해당할 정도로 우선순위가 높았다는 것도 놀랍네요.

Preview 순서에 그런 가치를 두는 게 맞는지는 모르겠지만 저는 그렇게 보여집니다.

그런데 이렇게 열심히 MS에서 Windows Forms 개발자들에게 지원을 계속해줌에도 불구하고 .NET Framework를 버리게 잘 유도할 수 있을지는 모르겠네요.

Windows Forms 하시는 분들은 .NET이라는게 있다는 거도 잘 모르시던데…주변 경험에 의하면…

7개의 좋아요

제가 보기에는 WinForm 개발자 분들이 .NET Framework에서 넘어올 메리트를 잘 느끼지 못하는 이유가 다음과 같은게 있다고 봅니다.

  • 만들어지는 애플리케이션 바이너리 사이즈가 압도적으로 큰 차이가 나는 점.
    • 이를 개선할 목적으로 Native AOT를 생각해볼 순 있지만, Windows Forms가 COM 기술을 적극 사용하고 있어 AOT 지원이 안된다는 점 + AOT 지원이 된다 한들 여전히 .NET Framework 버전 대비 바이너리 사이즈가 매우 크다는 점.
    • Windows XP 시절 때만 하더라도 .NET Framework 자체를 배포하는게 큰 일이었지만, 이제는 그럴 걱정이 전혀 없다는 것. (Windows 10이 대중화된 이후로 확실해진 부분이죠.)
  • Visual Studio가 .NET Framework 기반이고, .NET Core 버전의 Windows Forms Designer가 별도 서버 형태로 띄워지기 때문에 자연스럽지 않고 느리다는 점.
  • .NET Framework 기반으로 만들었기 때문에 많이들 사용했던 AppDomain을 이용한 동적 로딩이나 WCF, .NET Remoting 같은 오래된 기술을 버리고 다시 .NET Core 기반으로 넘겨야 할 만큼 실익이나 이점이 설명이 잘 안된다는 것.
  • 무엇보다도 위의 모든 내용을 당장 고려해야 할 상황인 .NET Framework의 EOS가 도래하려면 아직 멀었다는 점

이러한 부분들 때문에 새로운 버전의 Windows Forms가 나오더라도 굳이 무리해서 옮기려 하지 않을 것이라는 결론이 쉽게 나는 것 같습니다. ㅎㅎ

8개의 좋아요

여러가지 이유들이 있겠지만 넘어가기 많이 힘들 것 같습니다.
단순히 기술적 정체를 가진 회사를 제외하더라도,

  • Windows XP 지원 (사실 이건 버려야 하는게 맞습니다 T^T)
  • .NET Framework 기반으로 짜여진 드라이버들
  • 써드파티 라이브러리 (DevExpress 등…) 의 지원 여부

데브 같은 경우는 현재 VS2022 조차도 지원이 안되서,
VS2019를 이용해야하는 상황입니다.

4개의 좋아요

그러면 사실 이게 전환이 된다기 보다는 쓸사람만 쓰세요~의 느낌같은데, 마이그레이션에 어떤 고객들의 변화 차도가 안보인다면 MS에서 해주던 지원도 끊기지 않을까하네요…

결국 Windows Forms의 기술력 자체나 소스코드 품질의 문제라기보다는 여러 라이브러리 의존성, 고객들의 OS 의존성 이런 것들이 걸린다는 것인데…

또 버려지는 거 아닌가…생각되기도 하네요.

4개의 좋아요

VB6 부활 시키는 편이 관심 받을 것 같습니다.

2개의 좋아요

XP는 이미 보수기간이 지났지요… ㅠㅠ
그럼에도 불구하고 대체가 (실제로, 또는 비용 상)불가능한 장비가 있어서 울며 겨자 먹기로 쓰는 경우가 많다고 들었습니다. 에효…

윈도 자체에 Framework가 내장인 부분도 있어서 드라이버의 디메리트…? 는 잘 모르겠어요.
OS단에서 지원을 끊는다면 모르겠지만요.
당분간은 그럴 생각도 없어 보이구요.

데브는 사실 VS2022도 충분히 잘 됩니다.
기존 윈폼 프로젝트 개발에 쓰던 데브 버전의 문제일 가능성이 제일 높아요.
데브가 Nuget Feed로 제공하는 패키지로 세팅해도 사용 가능하고,
설치형 패키지를 깔면 도구상자 복구 옵션도 제공해서 ㅎㅎ

특히 2019만 된다고 하신 걸로 보아, 비주얼스튜디오 x86 에 맞춘 패키지일 가능성이 높아 보여요.
VS2022부턴 x64로 작동하거든요.

1개의 좋아요

.NET으로 넘어가면서 ui 테마만이라도 WinUI 스타일로 바꿨으면 대박났을텐데,
기존걸 그대로 넘기니까 굳이 바꿀 필요성을 못 느끼는거겠죠.
기업에서는 프레임워크 버전 하나 올리는것도 엄청난 리스크를 감수하고 도전해야할 판인데
완전히 다른 플랫폼으로 넘어간다는건 무조건 마이너스 업무이고,
이런 무쓸모 작업에 책임을 지고 담당자로 나설 사람은 아무도 없죠.

2개의 좋아요

Devexpress에서 vs2022지원합니다. 아마도 dev버전때문이신듯.

1개의 좋아요