.NET Framework에서 .NET으로 포팅 개요

2025-06-03

이 문서에서는 .NET Framework에서 .NET으로 코드를 이식할 때 고려해야 할 사항(이전의 .NET Core)에 대한 개요를 제공합니다. .NET Framework에서 .NET으로 포팅하는 작업은 많은 프로젝트에서 비교적 간단합니다. 프로젝트의 복잡성은 프로젝트 파일의 초기 마이그레이션 후에 수행해야 하는 작업의 양을 결정합니다.

라이브러리, 콘솔 앱 및 데스크톱 앱과 같은 .NET에서 앱 모델을 사용할 수 있는 프로젝트는 일반적으로 거의 변경이 필요하지 않습니다. ASP.NET ASP.NET Core로 이동하는 등 새 앱 모델이 필요한 프로젝트에는 더 많은 작업이 필요합니다. 이전 앱 모델의 많은 패턴에는 변환 중에 사용할 수 있는 동일한 패턴이 있습니다.

Windows 데스크톱 기술

.NET Framework용으로 만든 많은 애플리케이션은 Windows Forms 또는 WPF(Windows Presentation Foundation)와 같은 데스크톱 기술을 사용합니다. Windows Forms와 WPF는 모두 .NET에서 사용할 수 있지만 Windows 전용 기술로 남아 있습니다.

Windows Forms 또는 WPF 애플리케이션을 마이그레이션하기 전에 다음 종속성을 고려합니다.

.NET용 프로젝트 파일은 .NET Framework와 다른 형식을 사용합니다.
프로젝트에서 .NET에서 사용할 수 없는 API를 사용할 수 있습니다.
타사 컨트롤 및 라이브러리는 .NET으로 이식되지 않았을 수 있으며 .NET Framework에서만 사용할 수 있습니다.
프로젝트에서는 .NET에서 더 이상 사용할 수 없는 기술을 사용합니다.

.NET은 Windows Forms 및 WPF의 오픈 소스 버전을 사용하며 .NET Framework에 대한 향상된 기능을 포함합니다.

데스크톱 애플리케이션을 .NET으로 마이그레이션하는 자습서는 다음 문서 중 하나를 참조하세요.

Windows 관련 API

애플리케이션은 여전히 .NET에서 지원하는 플랫폼에서 네이티브 라이브러리를 P/Invoke할 수 있습니다. 이 기술은 Windows로 제한되지 않습니다. 그러나 참조하는 라이브러리가 user32.dll 또는 kernel32.dll같은 Windows 전용인 경우 코드는 Windows에서만 작동합니다. 앱을 실행하려는 각 플랫폼에 대해 플랫폼별 버전을 찾거나 모든 플랫폼에서 실행할 수 있을 만큼 코드를 일반화해야 합니다.

.NET Framework에서 .NET으로 애플리케이션을 포팅하는 경우 애플리케이션에서 .NET Framework에서 제공하는 라이브러리를 사용했을 수 있습니다. .NET Framework에서 사용할 수 있었던 많은 API는 Windows 레지스트리 또는 GDI+ 그리기 모델과 같은 Windows 관련 기술에 의존했기 때문에 .NET으로 이식되지 않았습니다.

Windows 호환성 팩은 .NET Framework API 화면의 상당 부분을 .NET에 제공하며 Microsoft.Windows.Compatibility NuGet 패키지를 통해 제공됩니다.

자세한 내용은 Windows 호환성 팩을 사용하여 코드를 .NET이식하는 방법을 참조하세요.

.NET Framework 호환성 모드

.NET Framework 호환성 모드는 .NET Standard 2.0에서 도입되었습니다. 호환 모드를 사용하면 .NET Standard 및 .NET 프로젝트가 프로젝트의 대상 프레임워크에 대해 컴파일된 것처럼 .NET Framework 라이브러리를 참조할 수 있습니다. 그러나 일부 .NET 구현은 다른 구현보다 더 큰 .NET Framework 청크를 지원할 수 있습니다. 예를 들어 .NET Core 3.0은 .NET Framework 호환성 모드를 Windows Forms 및 WPF로 확장합니다. 라이브러리에서 WPF API를 사용하는 경우와 같이 .NET Framework 라이브러리를 참조하는 것은 모든 프로젝트에서 작동하지 않지만 많은 포팅 시나리오의 차단을 해제합니다. 자세한 내용은 .NET Framework에서 .NET으로 코드를 이식하기 위한 종속성 분석을 참조하세요.

.NET Framework 라이브러리 참조는 사용된 .NET Framework API와 프로젝트의 대상 프레임워크에서 이러한 API를 지원하는지 여부에 따라 달라지기 때문에 모든 경우에 작동하지 않습니다. 또한 일부 .NET Framework API는 Windows에서만 작동합니다. .NET Framework 호환성 모드는 많은 포팅 시나리오의 차단을 해제하지만 프로젝트를 테스트하여 런타임에도 작동하는지 확인해야 합니다. 자세한 내용은 .NET Framework에서 코드 포팅을 위한 종속성 분석을 참조하세요.

SDK 스타일 프로젝트의 대상 프레임워크 변경 내용

앞에서 설명한 것처럼 .NET용 프로젝트 파일은 SDK 스타일 프로젝트 형식이라고 하는 .NET Framework와 다른 형식을 사용합니다. .NET Framework에서 .NET으로 이동하지 않더라도 프로젝트 파일을 최신 형식으로 업그레이드해야 합니다. 대상 프레임워크를 지정하는 방법은 SDK 스타일 프로젝트에서 다릅니다. .NET Framework <TargetFrameworkVersion> 에서 속성은 .NET Framework의 버전을 지정하는 모니커와 함께 사용됩니다. 예를 들어 .NET Framework 4.7.2는 다음 코드 조각과 같습니다.

<PropertyGroup>
  <TargetFrameworkVersion>v4.7.2</TargetFrameworkVersion>
</PropertyGroup>

SDK 스타일 프로젝트는 다른 속성을 사용하여 대상 프레임워크인 속성을 식별합니다 <TargetFramework> . .NET Framework를 대상으로 할 때, 모니커는 net로 시작하고 .NET Framework 버전으로 마침표 없이 끝납니다. 예를 들어 .NET Framework 4.7.2를 대상으로 하는 모니커는 다음과 같습니다 net472.

<PropertyGroup>
  <TargetFramework>net472</TargetFramework>
</PropertyGroup>

모든 대상 모니커 목록은 SDK 스타일 프로젝트의 대상 프레임워크를 참조하세요.

사용할 수 없는 기술

.NET Framework에는 .NET에 없는 몇 가지 기술이 있습니다.

애플리케이션 도메인

추가 애플리케이션 도메인 만들기는 지원되지 않습니다. 코드 격리의 경우 별도의 프로세스 또는 컨테이너를 대안으로 사용합니다.
원격

원격은 더 이상 지원되지 않는 애플리케이션 도메인 간에 통신하는 데 사용됩니다. 프로세스 간 간단한 통신을 위해 IPC(프로세스 간 통신) 메커니즘을 원격에 대한 대안(예: System.IO.Pipes 클래스 또는 MemoryMappedFile 클래스)으로 고려합니다. 더 복잡한 시나리오의 경우 StreamJsonRpc 또는 ASP.NET Core 와 같은 프레임워크( gRPC 또는 RESTful Web API 서비스 사용)를 고려합니다.

원격 호출은 지원되지 않으므로 대리자 개체에서 BeginInvoke() 및 EndInvoke()을(를) 호출하면 PlatformNotSupportedException 예외가 발생합니다.
CAS(코드 액세스 보안)

CAS는 .NET Framework에서 지원되지만 .NET Framework 4.0에서는 사용되지 않는 샌드박싱 기술입니다. 보안 투명성으로 대체되었으며 .NET에서는 지원되지 않습니다. 대신 가상화, 컨테이너 또는 사용자 계정과 같은 운영 체제에서 제공하는 보안 경계를 사용합니다.
보안 투명성

CAS와 마찬가지로 보안 투명성 샌드박싱 기술은 .NET Framework 애플리케이션에 더 이상 권장되지 않으며 .NET에서는 지원되지 않습니다. 대신 가상화, 컨테이너 또는 사용자 계정과 같은 운영 체제에서 제공하는 보안 경계를 사용합니다.
System.EnterpriseServices

System.EnterpriseServices (COM+)는 .NET에서 지원되지 않습니다.
WF(Windows Workflow Foundation)

.NET에서는 WF가 지원되지 않습니다. 대안은 CoreWF 참조하세요.

지원되지 않는 이러한 기술에 대한 자세한 내용은 .NET 6 이상에서 사용할 수 없는 .NET Framework 기술을 참조하세요.

플랫폼 간

.NET(이전의 .NET Core)은 플랫폼 간으로 설계되었습니다. 코드가 Windows 관련 기술에 의존하지 않는 경우 macOS, Linux 및 Android와 같은 다른 플랫폼에서 실행할 수 있습니다. 이러한 코드에는 다음과 같은 프로젝트 형식이 포함됩니다.

라이브러리
콘솔 기반 도구
자동화
ASP.NET 사이트

.NET Framework는 Windows 전용 구성 요소입니다. 코드에서 Windows 특정 기술 또는 API(예: Windows Forms 및 WPF)를 사용하는 경우 코드는 .NET에서 계속 실행할 수 있지만 다른 운영 체제에서는 실행되지 않습니다.

라이브러리 또는 콘솔 기반 애플리케이션은 많이 변경하지 않고 플랫폼 간을 사용할 수 있습니다. .NET으로 이식하는 경우 이를 고려하고 다른 플랫폼에서 애플리케이션을 테스트할 수 있습니다.

.NET Standard의 미래

.NET Standard는 여러 .NET 구현에서 사용할 수 있는 .NET API의 공식 사양입니다. .NET Standard의 동기는 .NET 에코시스템에서 더 큰 균일성을 확립하는 것이었습니다. .NET 5부터는 균일성을 설정하는 다른 접근 방식이 채택되었으며, 이 새로운 접근 방식을 통해 많은 시나리오에서 .NET Standard가 필요하지 않습니다. 자세한 내용은 .NET 5+ 및 .NET Standard를 참조하세요.

.NET Standard 2.0은 .NET Framework를 지원하는 마지막 버전입니다.

포팅을 지원하는 도구

.NET Framework에서 .NET으로 애플리케이션을 수동으로 포팅하는 대신 다른 도구를 사용하여 마이그레이션의 일부 측면을 자동화할 수 있습니다. 복잡한 프로젝트 포팅은 그 자체로 복잡한 프로세스입니다. 이 도구는 해당 여정에 도움이 될 수 있습니다.

도구를 사용하여 애플리케이션을 포팅하는 경우에도 이 문서의 섹션을 포팅할 때 고려 사항을 검토해야 합니다.

.NET 업그레이드 도우미

.NET 업그레이드 도우미는 다양한 종류의 .NET Framework 앱에서 실행할 수 있는 명령줄 도구입니다. .NET Framework 앱을 .NET으로 업그레이드하는 데 도움이 되도록 설계되었습니다. 도구를 실행한 후 대부분의 경우 앱은 마이그레이션을 완료하기 위해 더 많은 노력이 필요합니다. 이 도구에는 마이그레이션 완료에 도움이 될 수 있는 분석기 설치가 포함됩니다. 이 도구는 다음과 같은 유형의 .NET Framework 애플리케이션에서 작동합니다.

윈도우 폼즈 (Windows Forms)
WPF (Windows Presentation Foundation, 윈도우 프레젠테이션 파운데이션)
ASP.NET MVC
콘솔
클래스 라이브러리

이 도구는 이 문서에 나열된 다른 도구(예: try-convert)를 사용하고 마이그레이션 프로세스를 안내합니다. 도구에 대한 자세한 내용은 .NET 업그레이드 도우미 개요를 참조하세요.

`try-convert`

이 try-convert 도구는 데스크톱 앱을 .NET으로 이동하는 것을 포함하여 프로젝트 또는 전체 솔루션을 .NET SDK로 변환할 수 있는 .NET 전역 도구입니다. 그러나 프로젝트에 사용자 지정 작업, 대상 또는 가져오기와 같은 복잡한 빌드 프로세스가 있는 경우에는 이 도구를 권장하지 않습니다.

자세한 내용은 GitHub 리포지토리를 참조try-convert하세요.

플랫폼 호환성 분석기

플랫폼 호환성 분석기는 런타임에 PlatformNotSupportedException를 던지는 API를 사용하고 있는지 여부를 분석합니다. .NET Framework 4.7.2 이상에서 이동하는 경우 이러한 API 중 하나를 찾을 가능성은 낮지만 확인하는 것이 좋습니다. .NET에서 예외를 throw하는 API에 대한 자세한 내용은 항상 .NET Core에서 예외를 throw하는 API를 참조하세요.

자세한 내용은 플랫폼 호환성 분석기를 참조하세요.

포팅 시 고려 사항

애플리케이션을 .NET으로 포팅할 때 다음 제안을 순서대로 고려합니다.

✔️ .NET 업그레이드 도우미 를 사용하여 프로젝트를 마이그레이션하는 것이 좋습니다. 이 도구는 미리 보기로 제공되더라도 이 문서에 자세히 설명된 대부분의 수동 단계를 자동화하고 마이그레이션 경로를 계속 진행하기 위한 훌륭한 시작점을 제공합니다.

✔️ 먼저 종속성을 검토하는 것이 좋습니다. 종속성은 .NET, .NET Standard 또는 .NET Core를 대상으로 해야 합니다.

✔️ NuGet packages.config 파일에서 프로젝트 파일의 설정으로 마이그레이션해야 합니다. Visual Studio를 사용하여 파일을 변환합니다package.config.

✔️ 아직 앱을 포팅할 수 없는 경우에도 최신 프로젝트 파일 형식으로 업그레이드하는 것이 좋습니다. .NET Framework 프로젝트는 오래된 프로젝트 형식을 사용합니다. SDK 스타일 프로젝트라고 하는 최신 프로젝트 형식이 .NET Core 및 그 너머에 대해 만들어졌지만 이 형식은 .NET Framework에서도 작동합니다. 프로젝트 파일을 최신 형식으로 사용하면 나중에 앱을 이식할 수 있습니다.

✔️ .NET Framework 프로젝트의 대상을 .NET Framework 4.7.2 이상으로 다시 지정합니다. 이렇게 하면 .NET Standard에서 기존 API를 지원하지 않는 경우 최신 API 대안의 가용성이 보장됩니다.

✔️ LTS(장기 지원) 릴리스인 .NET 8을 대상으로 하는 것이 좋습니다.

✔️ Windows Forms 및 WPF 프로젝트에 대해 .NET 6+를 대상으로 지정합니다. .NET 6 이상 버전에는 데스크톱 앱에 대한 많은 개선 사항이 포함되어 있습니다.

✔️ .NET Framework 프로젝트에서도 사용할 수 있는 라이브러리를 마이그레이션하는 경우 .NET Standard 2.0을 대상으로 지정하는 것이 좋습니다. .NET Framework와 .NET Standard를 모두 대상으로 라이브러리를 다중 대상화할 수도 있습니다.

✔️ 마이그레이션 후 누락된 API 오류가 발생하는 경우 Microsoft.Windows.Compatibility NuGet 패키지 에 대한 참조를 추가하세요. .NET Framework API 표면의 상당 부분은 NuGet 패키지를 통해 .NET에서 사용할 수 있습니다.