.net framework -> .net 전환 질문

[스노우맨]

.net framework 에서 .net 으로 전환하셨을때 어떠셨나요?
장단점 같은건 어떤게 있을까요?
전환 하실때 어려움같은것이 있으셨는지도 궁금합니다.

저는 윈도우 어플 개발을 .net framework 로만 해오고 있고 .net 으로 전환을 생각중인데
몇가지 걸리는 것들이 있어서 질문드립니다.

[rkttu]

기능적으로는 더 나은 비동기 처리나 최신 Windows API 기능 지원 등 개발 효율성 면에서의 이점이 큽니다. 다만 .NET Framework에서 쓰이던 개념이 .NET에 와서는 유효하지 않거나 크게 달라지는 부분들이 많을 수 있어서, 기계적으로 코드를 옮겨 담는 것 말고 종합적인 진단이 필요할 수 있습니다.

GitHub Copilot app modernization overview

이 문서의 내용을 참고하셔서 Github Copilot의 현대화 도우미 기능을 충분히 활용해 보실 것을 추천드립니다.

[파란매]

성능 개발 뭐 비교할수 도 없습니다 편의성까지 문제는 사람이죠
기존에 레거시 개발자들이 배울생각을 안해요 아직도 싸우는 중입니다.

[windowmini]

기존의 레거시 개발자들이 배울 생각 많습니다… 일부는 은퇴 한다는 사람도 있지만

문제는 클라이언트가 XP도 있고 XP 보다 더 망인.. Embedid 도 있고 아오 못 바꿈

바꾸자고 노래를 불러도 돈 들어 가는거 안함.. 클라이언트 장비 바꾸는데만 10~20억 드간다고 안된다는군요…….. ■■■… 개발자가 문제가 되는곳은 한번도 못 봄… 클라가 문제지

탈출 해야 될랑가 봅니다. 아오…

전 프리라 탈출 해도 되지만 클라만 바꿔 주면 한 몇년 더 다녀도 되는데….

클라 좀 바꾸자고 지금도 싸웁니다.

[Vagabond-K]

공감이 됩니다. 고객 분들은 기본적으로 지갑을 잘 열지 않으십니다.

윈도우 XP 시절에 만들었던 것을 아직도 쓰고 계신 분들이 꽤 계시더군요..

공장 환경이라 하드웨어가 더 이상 버티지 못해서 업그레이드를 한다고 할 때도, 그냥 윈도우7 기반 하드웨어로 바꾸기만 하고 소프트웨어 업그레이드는 돈 든다고 제외하는 케이스도 있었습니다.

[Tokhi]

가끔 공장에 들어가는 프로그램 운영환경들을 보면 그냥 고장나기를 바랍니다 ㅎㅎ;; 그래야 최신 버전으로 올리니까요~

[스노우맨]

윈도우 어플이라고 하니까 다들 공장 장비로 생각하시는데 그건 아니구요.
산업용 PC에 윈도우10 IOT 버전 설치해서 동작시킵니다.
CPU는 i5 4코어 이상입니다.

[이광석]

그렇다면…몇 가지 걸리는 것에 대해 얘기해보시는게 좋지않을까요?

[Chris_Shim]

공장 관련 항상 무서운 점은

어딘가 돌아가는 386 컴퓨터가 가장 중요한 시스템일 수 있다는 거

[이광석]

또 하나..있습니다..

강제로 전원이 나간다거나…
서버 전원 내렸지만 내부직원들은 서버가 내려가 있는지 조차 모르는 상황..(서버 모니터링 제안을 했지만..돈들어서 싫다..)

[스노우맨]

일단 제일 큰건 일정입니다.
윈도우 어플은 비슷한 프로그램 위주로 개발하고있어서 일정을 길게 잡으면 앞에꺼랑 뭐가 다른데 일정이 늘어나냐 이런 반응입니다.
아무래도 사용기술이 달라지면 적응하는데 시간이 필요할테고 사용 라이브러리도 .net 용이 맞는게 있어야할거같아요.
제가 만들어놓은 .net framework 용 라이브러리는 어렵지않게 포팅이 가능할거 같은데 다른것들은 맞는걸 찾아야할거같아서요.
넷상에 .net 용 보다 .net framework 용 라이브러리나 소스가 아직 더 많은걸로 알고있습니다.

회사에서 저 혼자 독립된 분야를 개발하고있고 제가 개발하는 것은 뭐든 제 맘데로 결정할 수 있는 상황인데 좀 망설여지네요.
혼자 생각하다보면 굳이? 란 의문이 들기도 하고요.

[Ivory]

클라이언트 프로그램의 경우 현실에서는 기존에 사용하던 .net framework용 컨트롤을 계속 사용해야 하는 경우들이 있을 수 있으니 점차적으로 전환하는 것도 좋습니다.

일단 가장 먼저 해야 할 일은 .NET Framework의 버전을 올리는 것이죠. 기존에 .NET Framework 4.6.2 이하를 사용하고 있었다면 기존 프로젝트의 속성에서 .NET Framework 버전을 4.6.2 이상으로 올리고, 가능하면 4.8까지 올리면 더 좋습니다. 이 부분은 코드 수정할 것이 없으니 어렵지 않게 적용할 수 있습니다.

왜 최소 4.6.2냐면 이 버전부터 .NET Standard 2.0이 제대로 지원되기 때문입니다.

아, 그리고 .NET Framework 버전을 올리면 Visual Studio 버전도 문제가 되는데, .NET Standard 2.0 이하용 어셈블리를 참조하여 사용할 수 있는 최소 버전은 Visual Studio 2015입니다. (약간의 추가 작업이 필요합니다.)

그 다음에 새로 만드는 라이브러리나 기존의 라이브러리 중 UI와 상관없는 코드들을 일단 .NET Standard 2.0 프로젝트로 만듭니다. 이 때는 Visual Studio 2019 이상 정도는 필요하겠죠.

이렇게 천천히 기존 소스들을 .NET Standard 2.0 및 .NET Framework 4.8로 올리다가 어느 시점에 외부 종속성 중 .NET Framework 전용이 모두 없어질 때 쯤 .NET으로 이전하면 되겠죠.

그래도 아직까지는 nuget 패키지들이 대부분 .NET Framework 4.7과 .NET Standard를 지원하고 있어서 .NET Framework으로 개발하는데 별 문제가 없지만 가끔 일부 소규모 오픈소스 패키지들 중에는 개발자 취항에 따라 .NET Standard 2.1이나 .NET 8등 .NET Framework에선는 사용할 수 없도록 만들어진 것들도 있습니다. 이런 경우에는 어쩔 수 없이 소스 다운로드해서 .NET 버전을 바꿔서 재컴파일해야 합니다. 그래도 .NET Framework 4.8과 같이 최신 .NET Framework 버전은 .NET과 코드 호환성이 꽤 높아서 코드 수정을 거의 안해도 되기도 하고, 최신 c#에서만 지원되는 문법의 경우 .csproj에 속성 추가하면 일부 문법은 .NET Framework 4.8에서도 사용할 수 있어서 실질적으로 코드를 수정해야 할 부분들은 매우 적습니다.

하지만, 시간이 가면 갈수록 .NET Framework에서 사용할 수 있는 nuget 패키지 등의 리소스가 줄어들테니 한 번에 하거나, 아니면 점차적으로 하거나 계속 움직여야만 할 겁니다.

[이광석]

@스노우맨

제가 만들어놓은 .net framework 용 라이브러리는 어렵지않게 포팅이 가능할거 같은데 다른것들은 맞는걸 찾아야할거같아서요.

이것 역시 사실 그렇게 큰 어려움은 없습니다. 프로젝트(.proj)만 잘건드려준다면 닷넷프레임워크, 닷넷코어 둘다 쓸 수 있는 프로젝트로 만드실 수 있습니다.

---

@Ivory

하지만, 시간이 가면 갈수록 .NET Framework에서 사용할 수 있는 nuget 패키지 등의 리소스가 줄어들테니 한 번에 하거나, 아니면 점차적으로 하거나 계속 움직여야만 할 겁니다.

최근 npgsql 라이브러리를 최신으로 다운받게 될 일이 있어서 받았는데,
닷넷프레임워크 (8버전까지)만 지원을 하게 되고, 그 이 후 부턴 닷넷코어 전용이였습니다.

급하게 변화는 위험하겠지만 @Ivory 님 말씀처럼 차차 업그레이드는 생각하시는게 좋을 거같아요.

---

일정 문제는 어느 기업이건 간에..존재하죠. 다만, 강도가 다를뿐..