다음을 통해 공유

포팅 계획 만들기

코드를 바로 시작하기 전에 권장되는 마이그레이션 전 단계를 진행합니다. 이 문서에서는 발생할 수 있는 문제의 종류에 대한 인사이트를 제공하고 가장 적합한 접근 방식을 결정하는 데 도움이 됩니다.

중요하다

.NET 업그레이드 도우미 도구를 사용한 바이너리 분석을 선호하여 API 포트는 사용이 권장되지 않습니다. API 포트의 백 엔드 서비스가 종료되었으므로 도구를 사용하려면 오프라인으로 사용해야 합니다. 자세한 내용은 .NET API 포트 추가 정보를 참조하세요.

코드 포팅

계속 진행하기 전에 코드 포팅에 대한 필수 구성 요소를 따라야 합니다. 가장 적합한 접근 방식을 결정하고 코드 포팅을 시작할 준비를 하세요.

중요하다

.NET 업그레이드 도우미는 공식적으로 사용되지 않습니다. Visual Studio 2026 및 Visual Studio 2022 17.14.16 이상에 포함된 GitHub Copilot 현대화 채팅 에이전트 를 대신 사용합니다. 이 에이전트는 프로젝트 및 종속성을 분석하고, 대상 권장 사항 및 자동화된 코드 수정을 사용하여 단계별 마이그레이션 계획을 생성하며, 각 변경 내용을 커밋하여 유효성을 검사하거나 롤백할 수 있습니다. 프로젝트 파일을 업데이트하고, 사용되지 않는 API를 대체하고, 빌드 문제를 해결하는 일반적인 포팅 작업을 자동화하므로 수동 작업을 줄이면서 더 빠르게 현대화할 수 있습니다.

주로 컴파일러 처리

이 접근 방식은 작은 프로젝트 또는 많은 .NET Framework API를 사용하지 않는 프로젝트에 적합합니다. 접근 방식은 간단합니다.

  1. 필요에 따라 프로젝트에서 ApiPort를 실행합니다. ApiPort를 실행하는 경우 해결해야 할 문제에 대한 보고서에서 정보를 가져오세요.
  2. 모든 코드를 새 .NET 프로젝트에 복사합니다.
  3. 이식성 보고서(생성된 경우)를 참조하면서 프로젝트가 완전히 컴파일될 때까지 컴파일러 오류를 해결합니다.

구조화되지 않은 경우에도 이 코드 중심 접근 방식은 문제를 빠르게 해결하는 경우가 많습니다. 데이터 모델만 포함하는 프로젝트가 이 접근 방식에 적합한 후보가 될 수 있습니다.

이식성 문제가 해결될 때까지 .NET Framework를 계속 사용하세요.

이 접근 방식은 전체 프로세스 중에 컴파일되는 코드를 선호하는 경우 적합할 수 있습니다. 이 접근 방식은 다음과 같습니다.

  1. 프로젝트에서 ApiPort를 실행합니다.
  2. 이식 가능한 다른 API를 사용하여 문제를 해결합니다.
  3. 직접적인 대안을 사용할 수 없는 영역을 기록해 둡니다.
  4. 각 프로젝트를 새 .NET 프로젝트에 복사할 준비가 되었다고 확신할 때까지 포팅하려는 모든 프로젝트에 대해 이전 단계를 반복합니다.
  5. 새 .NET 프로젝트에 코드를 복사합니다.
  6. 직접적인 대안이 없는 것으로 기록해 둔 문제를 해결합니다.

이 신중한 접근 방식은 단순히 컴파일러 오류를 해결하는 것보다는 구조적이지만 비교적 코드 중심적이며 컴파일되는 코드가 항상 있다는 장점이 있습니다. 다른 API를 사용하여 해결할 수 없는 특정 문제를 해결하는 방법은 현저하게 달라집니다. 특정 프로젝트에 대해 보다 포괄적인 계획을 개발해야 할 수 있으며, 이는 다음 접근 방식에서 설명합니다.

포괄적인 공격 계획 개발

이 접근 방식은 .NET을 지원하기 위해 코드를 재구성하거나 코드의 특정 영역을 완전히 다시 작성해야 할 수 있는 더 크고 더 복잡한 프로젝트에 가장 적합할 수 있습니다. 이 접근 방식은 다음과 같습니다.

  1. 프로젝트에서 ApiPort를 실행합니다.

  2. 이식 불가능한 각 형식이 사용되고 있는 위치 및 해당 형식이 전체 이식성에 어떻게 영향을 주는지를 파악합니다.

    • 해당 형식의 특성을 이해합니다. 수는 적은데 자주 사용되나요? 아니면 수는 많지만 자주 사용되지 않나요? 집중적으로 사용되나요? 아니면 코드 전체에 분산되어 있나요?
    • 이식할 수 없는 코드는 격리가 쉬우므로 더 효과적으로 처리할 수 있나요?
    • 코드를 리팩터링해야 하나요?
    • 이식할 수 없는 해당 형식에 대해 동일한 작업을 수행하는 다른 API가 있나요? 예를 들어 WebClient 클래스를 사용하고 있는 경우 HttpClient 클래스를 대신 사용합니다.
    • 드롭인 대체가 아닌 경우에도 작업을 수행하는 데 사용할 수 있는 이식 가능한 다른 API가 있나요? 예를 들어 XmlSchema를 사용하여 XML을 구문 분석하지만 XML 스키마 검색이 필요하지 않은 경우, API를 사용하는 대신 System.Xml.Linq API를 사용하고 직접 구문 분석을 구현할 수 있습니다.

  3. 이식하기 어려운 어셈블리가 있는 경우 지금은 .NET Framework에 유지하는 것이 나을까요? 고려할 사항은 다음과 같습니다.

    • .NET Framework 또는 Windows 관련 기능을 너무 많이 사용하기 때문에 .NET과 호환되지 않는 일부 기능이 라이브러리에 있을 수 있습니다. 기능 이식을 위해 리소스를 사용할 수 있을 때까지 해당 기능을 유지하고 당분간은 기능이 적은 라이브러리의 임시 .NET 버전을 릴리스하는 것이 더 나을까요?
    • 리팩터링이 도움이 될까요?

  4. 사용할 수 없는 .NET Framework API의 고유한 구현을 작성하는 것이 합리적일까요?

    .NET Framework 참조 소스에서 코드를 복사, 수정 및 사용하는 것이 좋을 수 있습니다. 참조 소스 코드는 MIT 라이선스에 따라 라이선스가 부여되므로, 소스를 자신의 코드에 대한 기초로 매우 자유롭게 사용할 수 있습니다. 코드에서 Microsoft 특성을 제대로 지정하기만 하면 됩니다.

  5. 필요에 따라 다른 프로젝트에 대해 이 프로세스를 반복합니다.

분석 단계는 코드베이스의 크기에 따라 다소 시간이 걸릴 수 있습니다. 이 단계에서 시간을 할애하여 필요한 변경의 범위를 철저하게 이해하고 계획을 개발하면 특히 복잡한 코드베이스가 있는 경우 대개 최종적으로 시간이 절약됩니다.

계획에는 .NET Framework 4.7.2를 계속 대상으로 지정하는 동시에 코드베이스를 크게 변경하는 것이 포함될 수 있습니다. 이는 이전 접근 방식의 좀 더 구조화된 버전입니다. 계획 실행을 시작하는 방법은 코드베이스에 따라 달라집니다.

혼합형 접근 방식

위의 접근 방식을 프로젝트 단위로 혼합하여 사용할 수 있습니다. 사용자 및 코드베이스에 가장 적합한 작업을 수행합니다.

테스트 포팅

코드를 이식한 경우 모든 항목이 제대로 작동하는지 확인하는 가장 좋은 방법은 .NET에 이식할 때 코드를 테스트하는 것입니다. 이렇게 하려면 .NET에 대한 테스트를 빌드하고 실행하는 테스트 프레임워크를 사용해야 합니다. 현재는 다음과 같은 세 가지 옵션이 있습니다.

궁극적으로 이식 작업은 .NET Framework 코드가 구성된 방법에 따라 크게 달라집니다. 코드를 이식하는 좋은 방법은 코드의 기본 구성 요소인 라이브러리의 기본으로 시작하는 것입니다. 이는 다른 모든 항목에서 직접적으로나 간접적으로 사용하는 데이터 모델이나 일부 다른 기본 클래스 및 메서드가 될 수 있습니다.

  1. 현재 이식하고 있는 라이브러리의 계층을 테스트하는 테스트 프로젝트를 이식합니다.
  2. 라이브러리의 기본을 새 .NET 프로젝트에 복사하고 지원하려는 .NET Standard의 버전을 선택합니다.
  3. 코드를 컴파일하는 데 필요한 대로 내용을 변경합니다. 이 작업의 많은 부분에서 NuGet 패키지 종속성을 csproj 파일에 추가해야 할 수 있습니다.
  4. 테스트를 실행하고 필요에 따라 조정합니다.
  5. 이식할 다음 코드 계층을 선택하고 이전 단계를 반복합니다.

라이브러리의 기본으로 시작하고 기본에서 바깥쪽으로 이동하면서 필요에 따라 각 계층을 테스트하면, 이식은 한 번에 하나의 코드 계층으로 문제가 격리되는 체계적인 프로세스가 됩니다.

다음 단계

  • Last updated on