blazor의 최대 단점은 Release
라고 생각합니다…
최상위문이다 뭐 어쩐다 계속 Startup이나 Program.cs쪽 구조가 바뀌더니
이제는 blazor 분류가 또 바뀌어버리니…
개인적으로 너무 아쉬운 부분이 많습니다…
가뜩이나 체감상 짧은 LTS주기에, 다른건 몰라도 구조가 지속적으로 바뀌는건 너무하지 않나요…
Auto짬뽕은 또 뭐람… 하…
증말 많이 순화해서 작성했는데… 너무 화납니다…ㅎㅎㅎㅎㅎ
8개의 좋아요
아예 새로운 프레임워크여서 구조를 잡아나가다 보니 그런 게 아닐까 생각합니다.
오히려 닷넷 8 이전의 난잡했던 템플릿을 생각하면 지금쪽이 나아지는 방향 같기도 하구요.
5개의 좋아요
저도 그 방향성을 잡는 과도기라고 이해하고 있었습니다만
빈도가 너무 잦네요…
방향을 잡아나가는건 좋은데 닷넷 코어1,2,3부터 시작해서
닷넷5,6 그리고 이제 8까지…
얼마나 더 많은 변화를 해야 방향이 잡힐까 싶은거지요.
버전별로 다른 구조적인 특징때문에 참고자료도 많지않을뿐더러, 디버깅 범위가 다양해지는 문제도 안게된 것 같습니다.
가뜩이나 LTS주기도 짧은 닷넷이라 쩝…
얼마 지나지않아 vs에서 6.0으로 프로젝트 선택 생성시 마주할 문구가 두렵습니다.
“.NET 6.0 (지원되지 않음)”
5개의 좋아요
그래도 이번 업데이트는 웹앱 개발에 있어서 유연성을 가지게 된 것 같아 개인적으로는 괜찮은 것 같습니당…
4개의 좋아요
전 여러가지 방식을 지원해준다는 점에서 좋아보입니다.
기존꺼는 기존꺼대로 써도 문제가 없어요.
닷넷이 VS기반에서 Cli기반으로 가면서 vs당 닷넷 지원버전에 대한 문제도 점점 사라질거같네요.
그리고 어느 프레임워크나 다 진화하고 바뀝니다.
5개의 좋아요
.NET 6.0 쓰던거 계속 쓰고 싶습니다만, 문제가 없진 않지요.
결국은 마주하게 될 미래가 있으니까요.
사용중인 패키지를 업데이트를 하고 싶어도 그 패키지도 더이상 .NET 6.0에 설치할 수 없도록 해버리니까요.
그래서 쓰던거 계속 쓰는 고인물이 되기도 사실상 쉽지가 않은 것 같습니다.
무엇보다도 가장 큰 게 팀원들 설득하기가 더욱 어렵다는 것이 아닐까 싶습니다.
이렇게 구조가 자주 바뀌는데, 학습해야 될 내용도 더 많아지고 러닝 커브는 더욱 가팔라지게 되니까요…
.NET 6.0이 나온지 불과 2년 남짓이라는 걸 감안하면 변화는 굉장히 빠르고 크게 느껴집니다.
그리고 @루나시아 님께서 말씀하신 내용은 잘못된 것 같아요.
닷넷8 이전의 템플릿은 전혀 난잡하지 않습니다.
오히려 프로젝트 생성시 선택할 수 있는 가지 수로 따진다면 닷넷8의 템플릿이 더욱 많아진거죠.
눈에 보이는 템플릿 개수는 동일하다고 볼 수 있는데, UI방식으로 된 프로젝트 생성화면에서 선택할 수 있는 옵션은 더 늘어났습니다.
4개의 좋아요
답답한 마음에 푸념 한번 해봤습니다…ㅎㅎㅎ
넓은 마음으로 이해를 부탁드려요… 
6개의 좋아요
.net6는 내년 11월 까지죠
3개의 좋아요
그 이후에 쓴다고 해도 크게 문제 될 건 없지 않나요?
아직 .net framework 4.8도 많이 쓰는데…
2개의 좋아요
.NET Framework와 .NET의 결은 많이 다르다고 생각이 되네요.
Blazor를 얘기하고 있었으니, Blazor의 경우 .NET Framework가 아니라 .NET Core를 과거 버전의 예로 들어야하지 않을까 싶습니다.
2개의 좋아요
혹시 제 글에 LTS 기간에 대한 잘못된 정보가 있었나요…?
2개의 좋아요
지금도 .NET 5 또는 그 미만을 사용하시던 분들은 아래와 같이 호환성 문제를 겪고 있습니다.
@code 님이나 제 바람처럼 그냥 쓰던거 계속 써도 문제가 없어야 하는데, 실상 그렇지 않다는거죠…
2개의 좋아요
Nuget 패키지들의 버전 같은경우에는 기존 닷넷 버전과 같이 판올림 한다고 간주하시는게 낫지 않을까용?
밑에 보시면 버전 종속성도 있을테고요.
MS 주도 패키지의 경우 버전 넘버링도 닷넷 버전(빌드)과 거의 동일하게 가는 걸로 기억중이라서요.
적어도 스크린샷만 봐서는 제가 어떤 상황에 처하신 건지 이해를 못했을 수도 있구요.
닷넷 5 미만이라고 하면 3.1인데, 떙겨쓰는 패키지 종속성도 < 5.0이 맞지 않나 싶은 생각입니다.
여담이지만…
LTS임에도 불구하고 3년은 제가 보기에도 좀 짧지 않나… 라는 생각이 언제나 들어요.
3개의 좋아요
저도 .NET의 LTS가 짧다고 생각합니다. 대부분 짧아도 5년이고 보통 10년 정도 지원을 하는데 3년 밖에 지원하지 않으니까요.
하지만 짧게 가져가는 이유가 아마 Visual Studio 배포나 Azure DevOps의 Build Agent 관리, NuGet 패키지 개발 공급자 측면에서는 LTS 가 짧아야 사후 지원에 들어가는 비용을 줄이고 다음 버전 개발에 투자하려는 목적인 듯합니다. 그리고 .NET 버전 업데이트를 반 강제해야 새로운 기능을 꾸준히 배포하여 레거시 부담이 없는 신규 진입 개발자의 유입이 확대되어, 시장 점유율 확대에 더 도움이 된다고 판단했지 않았을까 싶습니다.
.NET을 직접 사용하는 사용자 측면보다는 여러 이해관계를 고려했을 때, 그런 것 같아요.
Python 같이 2 버전을 너무 길게 끌었더니, 라이브러리가 타겟팅하는 버전이 2 인지 3 인지에 따라 너무 달라서 난리였던 적도 있고 Java 만 봐도 Java SE 8 (LTS)가 2014년에 출시됐고 지원이 2030년까지 이다 보니, 안드로이드 어플 개발 언어가 Java SE 8 에 머물러 있어 레거시 유지보수하는 개발자만 고통을 받는 구조이기도 하죠. 지원 기간이 남아 있다 보니, 팀 내에서 버전을 올리자고 주장하는 게 힘을 받기가 어렵습니다. 자원을 할당받기도 어렵고요.
LTS 가 짧아서 개발자가 쫓아가야 하는 부담이 크지만 다행히(?) 문서라도 잘되어 있어서 다행이라고 생각합니다…
그래도 매번 적응할 때마다 홍역을 치루다 보니, 팀 내 마찰을 극복하기가 쉽지 않네요…
7개의 좋아요
써주신 내용을 읽어보니 다 일리가 있는 말씀이네요.
LTS가 짧을 때의 단점도 있겠지만 장점도 있군요.
이것저것 다 만족시키기가 참 어렵습니다… 
4개의 좋아요