어셈블리 정의 프로퍼티

인스펙터 창에서 어셈블리의 프로퍼티를 설정하려면 해당 어셈블리 정의 에셋을 클릭합니다.

Assembly Definition 프로퍼티는 다음 섹션으로 구성됩니다.

• 이름 및 일반
• 제약 정의
• 어셈블리 정의 레퍼런스
• 어셈블리 레퍼런스
• 플랫폼
• 버전 정의

이름 및 일반

프로퍼티:	설명:
Name	어셈블리의 이름(파일 확장자 없음)입니다. 어셈블리 이름은 프로젝트 전체에 걸쳐 고유해야 합니다. 특히 두 개 이상의 프로젝트에서 어셈블리를 사용하려는 경우 이름 충돌 가능성을 줄이기 위해 리버스 DNS 방식으로 이름을 지정하는 것을 고려하십시오. 참고: Unity는 어셈블리 정의 에셋에 할당한 이름을 이름 필드의 기본값으로 사용하지만 필요에 따라 이름을 변경할 수 있습니다. 그러나 GUID가 아닌 이름으로 어셈블리 정의를 참조하는 경우 이름을 변경하면 레퍼런스를 중단합니다.
Allow ‘unsafe’ Code	어셈블리 내 스크립트에서 C# unsafe 키워드를 사용하는 경우 Allow ‘unsafe’ Code 옵션을 활성화합니다. 이 설정을 활성화하면 Unity는 어셈블리를 컴파일할 때 C# 컴파일러에 /unsafe 옵션을 전달합니다.
Auto Referenced	사전 정의된 어셈블리가 이 프로젝트 어셈블리를 참조해야 하는지 여부를 지정합니다. Auto Reference 옵션을 비활성화하면 Unity는 컴파일 중에 어셈블리를 자동으로 참조하지 않습니다. 이는 Unity가 빌드에 포함하는지 여부에 영향을 주지 않습니다.
No Engine References	이 프로퍼티를 활성화하면 Unity는 어셈블리를 컴파일할 때 UnityEditor 또는 UnityEngine에 레퍼런스를 추가하지 않습니다.
Override References	Override References 설정을 활성화하여 해당 어셈블리가 종속되는 사전 컴파일된 어셈블리를 수동으로 지정합니다. Override References를 활성화하면 인스펙터는 레퍼런스를 지정하는 데 사용할 수 있는 Assembly References 섹션을 표시합니다. 사전 컴파일된 어셈블리는 Unity 프로젝트 외에서 컴파일된 라이브러리입니다. 기본적으로 프로젝트에서 정의한 어셈블리는 프로젝트에 추가한 모든 사전 컴파일된 어셈블리를 참조합니다. 이는 사전 정의된 어셈블리가 모든 사전 컴파일된 어셈블리를 참조하는 방식과 일치합니다. Override References를 활성화하면 해당 어셈블리는 어셈블리 레퍼런스에 추가한 사전 컴파일된 어셈블리만 참조합니다. 참고: 프로젝트 어셈블리가 사전 컴파일된 어셈블리를 자동으로 참조하지 않도록 하려면 Auto Referenced 옵션을 비활성화할 수 있습니다. 자세한 내용은 플러그인 인스펙터를 참조하십시오.
Root Namespace	이 어셈블리 정의에서 스크립트의 기본 네임스페이스입니다. Rider 또는 Visual Studio를 코드 에디터로 사용하는 경우 이 어셈블리 정의에서 생성하는 모든 새 스크립트에 이 네임스페이스가 자동으로 추가됩니다.

자세한 내용은 어셈블리 정의 에셋 생성을 참조하십시오.

제약 정의

제약 정의는 Unity가 어셈블리를 컴파일하거나 참조하도록 정의해야 하는 컴파일러 #define 지시문을 지정합니다.

Unity는 모든 제약 정의가 충족되는 경우에만 프로젝트 어셈블리를 컴파일하고 참조합니다. 제약은 C#의 #if 프리 프로세서 지시문처럼 작동하지만 스크립트 수준이 아닌 어셈블리 수준에서 작동합니다. 제약이 충족되도록 제약 정의 설정에서 모든 심볼을 정의합니다.

심볼이 정의되지 않도록 지정하려면 취소를 의미하는 !(느낌표) 심볼을 앞에 붙이십시오. 예를 들어 다음 심볼을 Define Constraints로 지정하는 경우를 살펴보겠습니다.

• !ENABLE_IL2CPP
• UNITY_2018_3_OR_NEWER

‘ENABLE_IL2CPP’ 심볼을 정의하지 않고 ‘UNITY_2018_3_OR_NEWER’ 기호를 정의하면 제약이 충족됩니다. 그 결과 Unity는 Unity 2018.3 이상을 위한 비IL2CPP 스크립팅 런타임에서만 이 어셈블리를 컴파일하고 참조합니다.

제약 중 충족된 제약이 적어도 하나가 있어야 함을 지정하려면 ||(OR) 연산자를 사용할 수 있습니다. 예는 다음과 같습니다.

• UNITY_IOS || UNITY_EDITOR_OSX
• UNITY_2019_3_OR_NEWER
• !UNITY_ANDROID

UNITY_IOS 또는 UNITY_EDITOR_OSX, 그리고 UNITY_2019_3_OR_NEWER가 정의되고 ’UNITY_ANDROID’가 정의되지 않은 경우 제약 조건이 충족됩니다. 개별 라인은 해당 제약 간에 논리적 AND 연산을 수행하는 것과 유사합니다. 위의 예는 다음과 같습니다.

(UNITY_IOS OR UNITY_EDITOR_OSX) AND (UNITY_2019_3_OR_NEWER) AND (NOT UNITY_ANDROID)

Unity의 빌트인 #define 지시문, 전역 컴파일러 리스폰스(.rsp) 파일, 그리고 프로젝트의 Scripting Define Symbols Player 설정에 정의된 심볼을 사용할 수 있습니다. 빌트인 심볼 리스트를 비롯한 자세한 내용은 플랫폼별 컴파일을 참조하십시오.

참고: Scripting Define Symbols 설정은 플랫폼 별로 다릅니다. 이 설정을 통해 어셈블리를 사용해야 하는지 여부를 정의하는 경우 반드시 해당하는 모든 플랫폼에서 필수 심볼을 정의해야 합니다.

자세한 내용은 조건부 어셈블리 포함을 참조하십시오.

유효하지 않거나 호환되지 않는 제약

Unity는 현재 정의된 설정을 기반으로 하는 지표로 각 제약을 표시합니다(예를 들어 다음 세 가지 제약 세트는 첫 번째 심볼이 현재 정의되어 있고 나머지 두 개는 정의되어 있지 않음을 표시합니다). 전체 제약을 충족하려면 각 개별 제약 조건이 참이여야 하므로 에디터는 전체 Define Constraints 섹션을 현재 호환되지 않거나 유효하지 않은 것으로 표시합니다.

이 예의 제약을 충족하기 위해 두 번째 제약 조건(Player Settings)에 대해 Scripting Backend를 IL2CPP로 변경하고 세 번째 제약에서 잘못된 문자를 제거할 수 있습니다. 그러나 종종 중요한 것은 Unity 에디터에 제약이 표시되는 방식이 아니라 프로젝트를 빌드할 때 제약 조건이 평가되는 방식입니다(예를 들어, IL2CPP 백엔드를 사용하는 빌드에만 포함시키고 Mono 백엔드를 사용하는 다른 빌드에는 포함하지 않으려는 어셈블리가 있을 수 있습니다).

어셈블리 정의 레퍼런스

프로퍼티:	설명:
Assembly Definition References	어셈블리 정의 에셋을 사용하여 생성한 다른 어셈블리에 대한 레퍼런스를 지정합니다. Unity는 이러한 레퍼런스를 사용하여 어셈블리를 컴파일하고 어셈블리 간 종속성을 정의합니다.
Use GUIDs	이 설정은 Unity가 다른 어셈블리 정의 에셋에 대한 레퍼런스를 직렬화하는 방식을 제어합니다. 이 프로퍼티를 활성화하면 Unity는 레퍼런스를 어셈블리 정의 이름이 아니라 에셋의 GUID로 저장합니다. 이름 대신 GUID를 사용하는 것은 항상 바람직합니다. 이렇게 하면 참조하는 다른 어셈블리 정의 파일을 업데이트하지 않고도 어셈블리 정의 에셋의 이름에 변경 사항을 적용할 수 있습니다.

자세한 내용은 어셈블리 정의 에셋 생성을 참조하십시오.

어셈블리 레퍼런스

Assembly References 섹션은 (일반 섹션에서) Override References 프로퍼티를 활성화한 경우에만 나타납니다. 이 영역을 사용하여 해당 어셈블리가 종속되는 사전 컴파일된 어셈블리에 대한 레퍼런스를 지정합니다.

자세한 내용은 사전 컴파일된 플러그인 어셈블리 레퍼런스를 참조하십시오.

플랫폼

어셈블리의 플랫폼 호환성을 설정합니다. Unity는 포함된(혹은 포함되지 않은) 플랫폼에서만 해당 어셈블리를 컴파일하거나 참조합니다.

자세한 내용은 플랫폼별 어셈블리 생성을 참조하십시오.

버전 정의

프로젝트의 패키지 및 모듈 버전에 따라 정의할 심볼을 지정하십시오.

프로퍼티:	설명:
Resource	패키지 또는 모듈입니다.
Define	적용 가능한 리소스 버전이 Unity 프로젝트에도 있는 경우를 정의하는 심볼입니다.
Expression	버전 또는 버전의 범위를 정의하는 표현식은 버전 정의 표현식을 참조하십시오.
Expression outcome	표현식은 논리 문으로 계산되며 여기서 “x”는 확인된 버전입니다. 표현식 결과가 유효하지 않다고 표시되면 표현식의 형식이 잘못된 것입니다.

자세한 내용은 프로젝트 패키지를 기반으로 심볼 정의를 참조하십시오.