Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 

최신 C# 문법을 .NET Framework 프로젝트에 쓸 수 있을까요?

간혹 유사한 질문을 하는 분들이 있는데,

.NET Framework에서 C# 버전만 올릴 수 있을까요?
; https://forum.dotnetdev.kr/t/net-framework-c/9750

개인적인 답변이라면, 아무 문제 없다고 말씀드리고 싶습니다. 일단 방법은 아래의 문서에도 나오는데요,

C# language versioning
; https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/configure-language-version

단지 csproj 파일에 <LangVersion /> 속성만 추가하면 됩니다.

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />
  <PropertyGroup>
      ...[생략]..
    <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
    <Deterministic>true</Deterministic>
    <LangVersion>12</LangVersion>
  </PropertyGroup>

  ...[생략]..

  <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
</Project>

그런데, 문서에 보면 이런 문구가 있습니다. ^^

C# 12 is supported only on .NET 8 and newer versions. 

여기서 "only"는 사실 부분적으로는 맞고 부분적으로는 틀립니다. 이유는...?




C# 컴파일러가 새로운 버전이 나왔을 때, 신규 문법은 크게 다음의 4가지 분류로 나눌 수 있습니다.

  1. Syntactic sugar 문법인 경우
  2. BCL에 추가 타입이 함께 요구되는 경우
  3. 닷넷 런타임의 변경이 함께 요구되는 경우
  4. 하위 버전의 C#과 컴파일 결과가 달라지는 경우

첫 번째 유형의 경우, C# 12에서 예를 들면 "컬렉션 식"이 좋은 예입니다.

C# 12 - 컬렉션 식(Collection Expressions)
; https://www.sysnet.pe.kr/2/0/13415

가령 아래의 코드는,

List<int> list = [1, 2, 3, 4, 5];

C# 컴파일러가 단순히 기존 문법으로 변환해,

List<int> list = new List<int>(5) { 1, 2, 3, 4, 5 };

컴파일시키기 때문에 아무런 문제 없이 .NET Framework에 적용이 가능합니다.




그다음, 두 번째 유형은 신규 문법을 위해 BCL에 새로운 타입이 추가된 경우입니다. C# 12 문법에서는 Experimental 지원이 그 사례입니다.

C# 12 - Experimental 특성 지원
; https://www.sysnet.pe.kr/2/0/13444

문법 자체는 C#의 기본 문법을 벗어나진 않지만, 그것을 사용할 때 ".NET 8" BCL에 포함된 타입을 사용하는 유형인데요,

using System.Diagnostics.CodeAnalysis;

namespace ConsoleApp1
{
    internal class Program
    {
        static void Main(string[] args)
        {
#pragma warning disable MYID01
            MyType myType = new MyType();
#pragma warning restore MYID01
        }
    }
}

[Experimental("MYID01")]
public class MyType
{
}

당연히, .NET Framework 프로젝트에서 저대로 컴파일하면 ExperimentalAttribute가 없다는 오류가 발생합니다.

error CS0246: The type or namespace name 'ExperimentalAttribute' could not be found (are you missing a using directive or an assembly reference?)

하지만, 그냥 맞춰주면 될 일이기 때문에 다음과 같이 .NET 8의 ExperimentalAttribute 정의를 그대로 가져와 .NET Framework 프로젝트에 포함만 시켜 처리할 수 있습니다.

[Experimental("MYID01")]
public class MyType
{
}

#if !NET8_0_OR_GREATER
namespace System.Diagnostics.CodeAnalysis
{
    [AttributeUsage(AttributeTargets.Assembly | AttributeTargets.Module | AttributeTargets.Class | AttributeTargets.Struct | AttributeTargets.Enum | AttributeTargets.Constructor | AttributeTargets.Method | AttributeTargets.Property | AttributeTargets.Field | AttributeTargets.Event | AttributeTargets.Interface | AttributeTargets.Delegate, Inherited = false)]
    public sealed class ExperimentalAttribute(string diagnosticId) : Attribute
    {
        public string DiagnosticId { get; } = diagnosticId;

        public string UrlFormat { get; set; }
    }
}
#endif




세 번째 유형은, "닷넷 런타임" 자체가 바뀐 경우로 이건 방법이 없습니다. 바로 이런 유형이 있기 때문에 문서에서 "C# 12 is supported only on .NET 8 and newer versions."라는 문구가 있는 것입니다.

이에 대한 좋은 사례가 인라인 배열입니다.

C# 12 - 인라인 배열(Inline Arrays)
; https://www.sysnet.pe.kr/2/0/13412

인라인 배열의 경우 Experimental처럼 InlineArray 특성을 필요로 하는데요,

[System.Runtime.CompilerServices.InlineArray(5)]
public struct Buffer
{
    private int _element0;
}

#if !NET8_0_OR_GREATER
namespace System.Runtime.CompilerServices
{
    [AttributeUsage(AttributeTargets.Struct, AllowMultiple = false)]
    public sealed class InlineArrayAttribute : Attribute
    {
        public InlineArrayAttribute(int length)
        {
            Length = length;
        }

        public int Length { get; }
    }
}
#endif

위와 같이 InlineArrayAttribute를 포함시켜도 빌드할 때 컴파일 오류가 발생합니다.

error CS9171: Target runtime doesn't support inline array types.

오류 메시지가 친절하게 ^^ "Target runtime"이 지원하지 않는다고, 즉, .NET Framework 4.8의 CLR 환경에서는 지원이 안 된다고 알려줍니다.




마지막 4번째로 인해 아마도 해당 문서에서는 "Choosing a language version newer than the default can cause hard to diagnose compile-time and runtime errors."라는 문구를 넣은 듯합니다.

이에 대한 사례로는 ref readonly가 있는데요,

C# 12 - ref readonly 매개변수
; https://www.sysnet.pe.kr/2/0/13428

ref readonly 대신 in 변경자로 처리해야만 했던 C# 11 이하에서는 허용되었던 구문을 ref readonly 이후로는 경고가 발생하는 식으로 바뀌는 등의 미묘한 차이가 있는 것입니다. 또 다른 예로는 C# 9의 개선된 조건 연산자 처리를 들 수 있습니다.

C# 9.0 - (10) 대상으로 형식화된 조건식(Target-typed conditional expressions)
; https://www.sysnet.pe.kr/2/0/12399

그렇다고 해서, 위에 나열한 2가지 유형들이 이전 버전과의 호환성을 깨뜨릴 정도는 아니고, 단지 경고나 에러로 대체하기 때문에 다시 한번 그 코드를 살펴봐야 하는 정도의 문제가 발생합니다.

아마도 이것 때문에, 마이크로소프트 입장에서는 뭐랄까,,, 약간의 보험 성격으로 "Choosing a language version newer than the default can cause hard to diagnose compile-time and runtime errors." 문구를 넣어둔 것이 아닌가... 하는 개인적인 의견입니다.




정리해 볼까요? 1번과 2번에 해당하는 문법은 그냥 쓰시면 됩니다. 반면 3번과 같은 경우는 어차피 컴파일 오류로 보여주기 때문에 사용하고 싶어도 할 수 없으므로 걱정할 필요가 없습니다.

4번 유형의 경우, 일례로 개선된 타입 추론 등으로 인해 신규 C# 컴파일러로는 경고 또는 에러가 발생할 수 있는 건데요, 만약 그 코드를 유지 보수해야 하는 핵심 인력이 빠졌고, 논리적으로 도저히 건드릴 수 없는 코드라면 그냥 기존 C# 컴파일러를 고수하는 것이 좋겠습니다. 그런 의미에서, 만약 신규 프로젝트를 진행하는 경우라면 최신 C# 버전을 적용하는 것을 두려워할 필요는 없을 것입니다.




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]







[최초 등록일: ]
[최종 수정일: 3/7/2024]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




... 31  32  33  34  35  36  37  38  39  40  41  42  43  [44]  45  ...
NoWriterDateCnt.TitleFile(s)
12539정성태2/16/20219764Windows: 189. WM_TIMER의 동작 방식 개요파일 다운로드1
12538정성태2/15/202110176.NET Framework: 1023. C# - GC 힙이 아닌 Native 힙에 인스턴스 생성 - 0SuperComicLib.LowLevel 라이브러리 소개 [2]
12537정성태2/11/202111208.NET Framework: 1022. UI 요소의 접근은 반드시 그 UI를 만든 스레드에서! - 두 번째 이야기 [2]
12536정성태2/9/202110193개발 환경 구성: 542. BDP(Bandwidth-delay product)와 TCP Receive Window
12535정성태2/9/20219321개발 환경 구성: 541. Wireshark로 확인하는 LSO(Large Send Offload), RSC(Receive Segment Coalescing) 옵션
12534정성태2/8/20219857개발 환경 구성: 540. Wireshark + C/C++로 확인하는 TCP 연결에서의 closesocket 동작 [1]파일 다운로드1
12533정성태2/8/20219558개발 환경 구성: 539. Wireshark + C/C++로 확인하는 TCP 연결에서의 shutdown 동작파일 다운로드1
12532정성태2/6/202110034개발 환경 구성: 538. Wireshark + C#으로 확인하는 ReceiveBufferSize(SO_RCVBUF), SendBufferSize(SO_SNDBUF) [3]
12531정성태2/5/20219034개발 환경 구성: 537. Wireshark + C#으로 확인하는 PSH flag와 Nagle 알고리듬파일 다운로드1
12530정성태2/4/202113261개발 환경 구성: 536. Wireshark + C#으로 확인하는 TCP 통신의 Receive Window
12529정성태2/4/202110274개발 환경 구성: 535. Wireshark + C#으로 확인하는 TCP 통신의 MIN RTO [1]
12528정성태2/1/20219690개발 환경 구성: 534. Wireshark + C#으로 확인하는 TCP 통신의 MSS(Maximum Segment Size) - 윈도우 환경
12527정성태2/1/20219875개발 환경 구성: 533. Wireshark + C#으로 확인하는 TCP 통신의 MSS(Maximum Segment Size) - 리눅스 환경파일 다운로드1
12526정성태2/1/20217721개발 환경 구성: 532. Azure Devops의 파이프라인 빌드 시 snk 파일 다루는 방법 - Secure file
12525정성태2/1/20217427개발 환경 구성: 531. Azure Devops - 파이프라인 실행 시 빌드 이벤트를 생략하는 방법
12524정성태1/31/20218552개발 환경 구성: 530. 기존 github 프로젝트를 Azure Devops의 빌드 Pipeline에 연결하는 방법 [1]
12523정성태1/31/20218619개발 환경 구성: 529. 기존 github 프로젝트를 Azure Devops의 Board에 연결하는 방법
12522정성태1/31/202110127개발 환경 구성: 528. 오라클 클라우드의 리눅스 VM - 9000 MTU Jumbo Frame 테스트
12521정성태1/31/202110072개발 환경 구성: 527. 이더넷(Ethernet) 환경의 TCP 통신에서 MSS(Maximum Segment Size) 확인 [1]
12520정성태1/30/20218622개발 환경 구성: 526. 오라클 클라우드의 VM에 ping ICMP 여는 방법
12519정성태1/30/20217663개발 환경 구성: 525. 오라클 클라우드의 VM을 외부에서 접근하기 위해 포트 여는 방법
12518정성태1/30/202125126Linux: 37. Ubuntu에 Wireshark 설치 [2]
12517정성태1/30/202112771Linux: 36. 윈도우 클라이언트에서 X2Go를 이용한 원격 리눅스의 GUI 접속 - 우분투 20.04
12516정성태1/29/20219399Windows: 188. Windows - TCP default template 설정 방법
12515정성태1/28/202110658웹: 41. Microsoft Edge - localhost에 대해 http 접근 시 무조건 https로 바뀌는 문제 [3]
12514정성태1/28/202110913.NET Framework: 1021. C# - 일렉트론 닷넷(Electron.NET) 소개 [1]파일 다운로드1
... 31  32  33  34  35  36  37  38  39  40  41  42  43  [44]  45  ...