유니버설 Windows 플랫폼: .NET 스크립팅 백엔드의 플러그인
관리되는 플러그인
Windows 런타임 APIs (http://msdn.microsoft.com/en-us/library/windows/apps/br211377.aspx)을 사용하는 경우 Unity 에디터에서 유니버설 Windows 플랫폼 고유 플러그인을 사용할 수 없으므로, Unity 에디터가 이들을 처리하는 방법을 약간 변경하였습니다. 유니버설 Windows 플랫폼에만 적용되고 Unity 에디터에는 적용되지 않는 플러그인을 사용하고자 하는 경우, 플레이스홀더를 생성하지 않아도 됩니다. 이런 경우 플러그인 API를 사용하는 코드를 아래 코드로 래핑해야 합니다.
# if !UNITY_EDITOR
// Plugin code
# endif
플레이스홀더가 필요한 경우에는 아래와 같이 두 개의 플러그인을 만들어야 합니다.
- Unity 에디터용 한 개
- 유니버설 Windows 플랫폼용 한 개
중요 Unity 에디터 플레이스홀더 플러그인은 UnityEditor.dll을 참조할 수 없으며, 참조하는 경우 아래의 오류가 발생합니다.
Assembly UnityEditor는 플러그인이 참조합니다('Assets/Plugins/Plugin.dll'). 하지만 dll 파일은 포함되어서는 안되며, 그렇지 않으면 검색할 수 없게 됩니다.
두 경우 모두 같은 이름과 같은 어셈블리 버전을 가집니다. 예를 들어, 에디터에 호환이 가능한 플러그인은 Assets\Plugins\MyPlugin.dll에 저장하고, 유니버설 Windows 플랫폼용 플러그인은 Assets\Plugins\WSA\MyPlugin.dll에 저장해야 합니다.
Assets\Plugins\MyPlugin.dll에서 에디터를 유일한 호환 플랫폼으로 설정합니다.
Assets\Plugins\WSA\MyPlugin.dll에서 Universal Windows Platform을 유일한 호환 플랫폼으로 설정한 후, 유니버설 Windows 플랫폼 플러그인 설정으로 가야 합니다.
’Assets\Plugins\MyPlugin.dll’을 플레이스홀더 필드에 입력해야 합니다. 이 경우 유니버설 Windows 플랫폼으로 빌드하면 스크립트를 컴파일할 때 ’Assets\Plugins\MyPlugin.dll’가 사용되지만 ’Assets\Plugins\WSA\MyPlugin.dll’이 ‘Assets\Plugins\MyPlugin.dll’ 대신 최종 폴더로 복사됩니다. 이렇게 하면 Unity 에디터에서 스크립트를 성공적으로 컴파일할 수 있으며 그와 동시에 게임은 유니버설 Windows 플랫폼 고유의 플러그인 API를 사용할 수 있게 됩니다.
Don’t process 옵션
이 옵션은 Unity가 어셈블리를 패치하지 않도록 하는 데 사용되며, 보통 용량이 큰 Windows 런타임 API를 포함하는 플러그인에 대해서 사용됩니다. Unity가 패치를 진행하기 어렵기 때문입니다.
유니버설 Windows 플랫폼 플러그인 설정
| 프로퍼티: | 기능: |
|---|---|
| CPU | 플러그인을 32 비트, 64 비트, ARM 플레이어로 제한합니다. |
| Don’t process | (관리된 어셈블리에만 적용)해당 어셈블리 패치를 비활성화합니다. 어셈블리가 Unity가 직렬화 가능한 클래스를 포함하는 경우 패치가 필요합니다. 이러한 경우 추가 IL 코드가 어셈블리에 추가됩니다. 어셈블리에 그러한 클래스가 없다는 것을 아는 경우에는 문제없이 패치를 비활성화할 수 있습니다. 참고: 만일 어셈블리가 패치되지 않은 상태에서 Unity가 런타임 중 직렬화를 시도하는 경우, ’바운드 이탈’과 같은 오류가 발생합니다. |
| 플레이스홀더 | (관리된 어셈블리에만 적용). 유니버설 Windows 플랫폼을 통해 .NET 코어에 대해 플러그인을 컴파일할 수 있지만, Unity 에디터는 Mono에서 작동하므로 그러한 어셈블리를 인식할 수 없습니다. 따라서 C#나 JS 파일은 이들을 참조할 수 없습니다. 이 문제를 해결하려면 실제 플러그인의 플레이스홀더로 작동하는 동일한 API를 가지도록 .NET 3.5에 대해 컴파일된 어셈블리를 제공해야 합니다. |
플레이스홀더 예시
예를 들어, 두 개의 어셈블리가 있다고 가정하겠습니다.
Plugins\WSA\MyPlugin.dll - Windows 런타임 API가 내부에 있는 상태에서 .NET 코어에 대해 컴파일된 어셈블리.
Plugins\MyPlugin.dll - 더미 함수 구현이 있으며 동일한 공용 API를 가지는 .NET 3.5에 대해 컴파일된 어셈블리.
Plugins\WSA\MyPlugin.dll를 클릭한 후, 플레이스홀더를 선택하고 Plugins\MyPlugin.dll를 선택해야 합니다.
이렇게 하면 Unity가 스크립트를 컴파일하면 Plugins\MyPlugin.dll 파일을 참조하지만, Unity가 플러그인을 최종 디렉토리로 복사할 때에는 Plugins\MyPlugin.dll 대신 Plugins\WSA\MyPlugin.dll를 복사하게 됩니다.
Unity가 어셈블리를 패치하지 않으면 어떻게 됩니까?
Unity는 직렬화된 코드를 어셈블리에 추가하며, 따라서 플러그인에는 MonoBehaviour에서 파생된 클래스가 있게 됩니다. Unity가 이를 패치하지 않으면 런타임 도중 직렬화 오류가 발생할 수 있습니다.
두 경우 모두 이름이 동일해야 합니다. 예를 들어, 에디터에 호환되는 플러그인은 Assets\Plugins\MyPlugin.dll에 저장하고, 유니버설 Windows 플랫폼용 플러그인은 Assets\Plugins\WSA\MyPlugin.dll에 저장해야 합니다. 에디터에서 작업하는 경우 Assets\Plugins\MyPlugin.dll이 사용될 것이며, 유니버설 Windows 플랫폼 앱으로 빌드하는 경우 Assets\Plugins\WSA\MyPlugin.dll이 빌드로 복사될 것입니다.
• 2017–05–16 편집 리뷰 없이 페이지 수정됨