알려진 트리밍 비호환성
이 문서에는 현재 도구로 트리밍과 호환되지 않는 패턴이 나열되어 있습니다.
리플렉션 기반 직렬 변환기
대안: 반사가 없는 직렬 변환기.
트리밍 경고 소개에 설명된 대로 대부분의 리플렉션 사용은 트리밍 호환되도록 설정할 수 있습니다. 그러나 직렬 변환기는 리플렉션을 복잡하게 사용하는 경향이 있습니다. 이러한 용도 중 상당수는 빌드 시 분석할 수 없습니다. 아쉽게도 가장 좋은 옵션은 일반적으로 소스 생성을 사용하도록 시스템을 다시 작성하는 것입니다.
다음 표에는 널리 사용되는 리플렉션 기반 직렬 변환기와 권장 대안이 나열되어 있습니다.
| 직렬 변환기 | 대체 |
|---|---|
| Newtonsoft.Json | 원본 생성됨 System.Text.Json |
| System.Configuration.ConfigurationManager | 구성 바인딩 소스 생성기 |
| System.Runtime.Serialization.Formatters.Binary.BinaryFormatter | 보안 및 안정성 결함으로 인해 BinaryFormatter 직렬화에서 마이그레이션합니다. |
JIT를 통한 런타임 코드 생성
예를 들어, System.Reflection.Emit를 통한 JIT를 통한 런타임 코드 생성은 트리밍과 호환되지 않습니다.
동적 어셈블리 로딩 및 실행
트리밍과 동적 어셈블리 로딩은 일반적으로 LoadFrom(String) 같은 API를 통해 플러그 인 또는 확장을 지원하는 시스템에서 일반적으로 발생하는 문제입니다. 트리밍은 빌드 시간에 모든 어셈블리를 확인하므로 사용되지만 잘릴 수 없는 코드를 알 수 있습니다. 대부분의 플러그 인 시스템은 타사 코드를 동적으로 로드하므로 트리머가 필요한 코드를 식별할 수 없습니다.
Windows 플랫폼 비호환성
다음 섹션에는 Windows에서 트리밍과 관련된 알려진 비호환성이 나열되어 있습니다.
C++/CLI를 사용한 .NET 프로그래밍
C++/CLI를 사용한 NET 프로그래밍은 현재 트리밍을 지원하지 않습니다.
기본 제공 COM 마샬링
대안: COM 래퍼
.NET Framework 1.0부터 자동 COM 마샬링이 .NET에 기본 제공됩니다. 런타임 코드 분석을 사용하여 네이티브 COM 개체와 관리형 .NET 개체 간에 자동으로 변환합니다. 불행하게도 트리밍 분석은 자동 COM 마샬링을 위해 어떤 .NET 코드를 보존해야 하는지 항상 예측할 수는 없습니다. 그러나 COM 래퍼를 대신 사용하는 경우 트리밍 분석에서는 사용되는 모든 코드가 올바르게 유지되도록 보장할 수 있습니다.
WPF
WPF(Windows Presentation Foundation) 프레임워크는 리플렉션을 많이 활용하고 일부 기능은 런타임 코드 검사에 크게 의존합니다. 트리밍 분석이 WPF 애플리케이션에 필요한 일부 코드를 유지할 수 없습니다. 안타깝게도 트리밍 후 실행 가능한 WPF 앱은 거의 없으므로 WPF에 대한 트리밍 지원은 현재 .NET SDK에서 사용하지 않도록 설정되어 있습니다. WPF 트리밍 사용 설정에 대한 진행률은 WPF가 트리밍과 호환되지 않음 문제를 참조하세요.
Windows Forms
Windows Forms 프레임워크는 최소한의 리플렉션을 사용하지만 기본 제공 COM 마샬링에 크게 의존합니다. 불행하게도 기본 제공 COM 마샬링 없이 실행 가능한 Windows Forms 앱은 거의 없으므로 현재 .NET SDK에서는 Windows Forms 앱에 대한 트리밍 지원이 사용하지 않도록 설정되어 있습니다. Windows Forms용 트리밍 사용 설정에 대한 진행률은 WinForms 자르기 호환 가능 문제를 참조하세요.
.NET