AssemblyVersion, AssemblyFileVersion 및 AssemblyInformationVersion의 차이점은 무엇입니까?

AssemblyVersion, AssemblyFileVersion 및 AssemblyInformationVersion의 차이점은 무엇입니까?

어셈블리 버전 속성은 세 가지가 있습니다.차이점은 무엇입니까?가 도해됩니까용을 사용해도 괜찮습니까?AssemblyVersion그리고 나머지는 무시합니까?

---

MSDN은 다음과 같이 말합니다.

• 어셈블리 버전:

  특성을 지정할 어셈블리의 버전을 지정합니다.

• 어셈블리 파일 버전:

  컴파일러가 Win32 파일 버전 리소스에 대해 특정 버전 번호를 사용하도록 지시합니다.Win32 파일 버전이 어셈블리의 버전 번호와 같을 필요는 없습니다.

• 어셈블리 정보 버전:

  어셈블리 매니페스트에 대한 추가 버전 정보를 정의합니다.

---

어셈블리 속성 사용을 위한 모범 사례는 무엇입니까?의 후속 조치입니다.

어셈블리 버전

어셈블리를 참조하는 다른 어셈블리가 찾을 위치입니다.이 번호가 변경되면 다른 어셈블리에서 사용자 어셈블리에 대한 참조를 업데이트해야 합니다!이전 버전과의 호환성이 손상된 경우에만 이 버전을 업데이트하십시오. 그AssemblyVersion필수 항목입니다.

major.minor 형식을 사용합니다(그리고 매우 안정적인 코드베이스의 경우 major).이로 인해 다음과 같은 결과가 발생합니다.

[assembly: AssemblyVersion("1.3")]

SemVer를 엄격하게 따르는 경우 메이저가 변경될 때만 업데이트된다는 의미이므로 1.0, 2.0, 3.0 등입니다.

어셈블리 파일 버전

설치 프로그램과 같은 배포에 사용됩니다.모든 배포에 대해 이 수를 늘릴 수 있습니다.한 동한어를표데시사는용다니합하가 있는 어셈블리를 표시할 때 합니다.AssemblyVersion다른 빌드 및/또는 코드에서 생성됩니다.

Windows에서는 파일 속성에서 볼 수 있습니다.

AssemblyFileVersion은 선택 사항입니다.지정되지 않은 경우 AssemblyVersion이 사용됩니다.

major.minor.patch.build 형식을 사용합니다. 여기서 처음 세 부분은 SemVer를 따르고 마지막 부분은 빌드 서버의 빌드 번호를 사용합니다(로컬 빌드의 경우 0).이로 인해 다음과 같은 결과가 발생합니다.

[assembly: AssemblyFileVersion("1.3.2.42")]

시스템에 주의하십시오.버전에서는 이 부품의 이름을 다음과 같이 지정합니다.major.minor.build.revision!

어셈블리 정보 버전

어셈블리의 제품 버전입니다.고객과 대화하거나 웹 사이트에 표시할 때 사용하는 버전입니다.이 버전은 '1.0 릴리스 후보'와 같은 문자열일 수 있습니다.

그AssemblyInformationalVersion선택 사항입니다.지정되지 않은 경우 AssemblyFileVersion이 사용됩니다.

major.minor[.patch] [revision as string] 형식을 사용합니다.이로 인해 다음과 같은 결과가 발생합니다.

[assembly: AssemblyInformationalVersion("1.3 RC1")]

.NET에서 어셈블리의 버전을 지정하는 방법이 현재 적어도 세 가지가 있다는 점에서 어셈블리의 버전을 지정하는 것은 혼란스러운 전망이 될 수 있습니다.

다음은 버전과 관련된 세 가지 주요 어셈블리 속성입니다.

// Assembly mscorlib, Version 2.0.0.0
[assembly: AssemblyFileVersion("2.0.50727.3521")]
[assembly: AssemblyInformationalVersion("2.0.50727.3521")]
[assembly: AssemblyVersion("2.0.0.0")]

관례에 따라 버전의 네 부분을 주 버전, 부 버전, 빌드 및 개정이라고 합니다.

그AssemblyFileVersion개별 어셈블리의 빌드를 고유하게 식별하기 위한 것입니다.

일반적으로 주 및 보조 어셈블리 파일 버전을 어셈블리 버전을 반영하도록 수동으로 설정한 다음 빌드 시스템이 어셈블리를 컴파일할 때마다 빌드 및/또는 수정본을 증분합니다.AssemblyFileVersion을 사용하면 어셈블리 빌드를 고유하게 식별할 수 있으므로 문제를 디버깅하기 위한 시작점으로 사용할 수 있습니다.

현재 프로젝트에서 빌드 서버는 소스 제어 저장소의 변경 목록 번호를 AssemblyFileVersion의 빌드 및 리비전 부분으로 인코딩합니다.이를 통해 빌드 서버에서 생성된 어셈블리에 대해 어셈블리에서 소스 코드로 직접 매핑할 수 있습니다(소스 제어에서 레이블이나 분기를 사용하거나 릴리스된 버전의 레코드를 수동으로 보관할 필요 없음).

이 버전 번호는 Win32 버전 리소스에 저장되며 어셈블리에 대한 Windows 탐색기 속성 페이지를 볼 때 볼 수 있습니다.

CLR은 AssemblyFileVersion에 대해 관심이 없거나 검사하지 않습니다.

그AssemblyInformationalVersion하기 위한 것입니다.

AssemblyInformationVersion은 전체 제품의 일관성 있는 버전 관리를 가능하게 하기 위한 것으로, 버전 관리 정책이 다를 수 있으며 서로 다른 팀이 개발할 수 있는 여러 어셈블리로 구성될 수 있습니다.

"예를 들어, 제품 버전 2.0에는 여러 어셈블리가 포함되어 있을 수 있습니다. 이 어셈블리 중 하나는 동일한 제품 버전 1.0에 제공되지 않은 새 어셈블리이므로 버전 1.0으로 표시됩니다.일반적으로 제품의 공용 버전을 나타내도록 이 버전 번호의 주 및 부 부분을 설정합니다.그러면 모든 조립품이 포함된 전체 제품을 포장할 때마다 빌드 및 리비전 부품이 증가합니다." – Jeffrey Richter, [CLR via C# (Second Edition)] 페이지 57

CLR은 Assembly Information Version에 대해 관심이 없거나 검사하지 않습니다.

그AssemblyVersion을 갖는 CLR ).AssemblyVersion)

AssemblyVersion은 CLR에서 강력하게 명명된 어셈블리에 바인딩하는 데 사용됩니다.빌드된 어셈블리의 AssemblyDef 매니페스트 메타데이터 테이블과 이를 참조하는 어셈블리의 AssemblyRef 테이블에 저장됩니다.

이는 강력한 이름의 어셈블리를 참조할 때 해당 어셈블리의 특정 AssemblyVersion에 단단히 바인딩된다는 의미이므로 매우 중요합니다.바인딩이 성공하려면 전체 AssemblyVersion이 정확하게 일치해야 합니다.예를 들어 빌드 시 강력한 이름의 어셈블리 버전 1.0.0.0을 참조하지만 런타임에 해당 어셈블리 버전 1.0.0.1만 사용할 수 있는 경우 바인딩이 실패합니다. 그런 다음 어셈블리 바인딩 리디렉션을 사용하여 이 문제를 해결해야 합니다.

전체 여부에 대한 혼란AssemblyVersion일치해야 합니다. (네, 일치합니다.)

어셈블리를 로드하려면 전체 AssemblyVersion이 정확하게 일치해야 하는지에 대해 약간의 혼란이 있습니다.일부 사람들은 바인딩이 성공하기 위해서는 AssemblyVersion의 주요 부분과 작은 부분만 일치해야 한다는 잘못된 믿음을 가지고 있습니다.이는 합리적인 가정이지만 궁극적으로 잘못된 것이며(.NET 3.5 기준) CLR 버전에 대해 이를 확인하는 것은 사소한 일입니다.이 샘플 코드를 실행하십시오.

내 기계에서 두 번째 어셈블리 로드가 실패하고 융합 로그의 마지막 두 줄은 다음과 같은 이유를 완벽하게 설명합니다.

.NET Framework Version: 2.0.50727.3521
---
Attempting to load assembly: Rhino.Mocks, Version=3.5.0.1337, Culture=neutral, PublicKeyToken=0b3305902db7183f
Successfully loaded assembly: Rhino.Mocks, Version=3.5.0.1337, Culture=neutral, PublicKeyToken=0b3305902db7183f
---
Attempting to load assembly: Rhino.Mocks, Version=3.5.0.1336, Culture=neutral, PublicKeyToken=0b3305902db7183f
Assembly binding for  failed:
System.IO.FileLoadException: Could not load file or assembly 'Rhino.Mocks, Version=3.5.0.1336, Culture=neutral, 
PublicKeyToken=0b3305902db7183f' or one of its dependencies. The located assembly's manifest definition 
does not match the assembly reference. (Exception from HRESULT: 0x80131040)
File name: 'Rhino.Mocks, Version=3.5.0.1336, Culture=neutral, PublicKeyToken=0b3305902db7183f'

=== Pre-bind state information ===
LOG: User = Phoenix\Dani
LOG: DisplayName = Rhino.Mocks, Version=3.5.0.1336, Culture=neutral, PublicKeyToken=0b3305902db7183f
 (Fully-specified)
LOG: Appbase = [...]
LOG: Initial PrivatePath = NULL
Calling assembly : AssemblyBinding, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.
===
LOG: This bind starts in default load context.
LOG: No application configuration file found.
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v2.0.50727\config\machine.config.
LOG: Post-policy reference: Rhino.Mocks, Version=3.5.0.1336, Culture=neutral, PublicKeyToken=0b3305902db7183f
LOG: Attempting download of new URL [...].
WRN: Comparing the assembly name resulted in the mismatch: Revision Number
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.

이러한 혼동의 원인은 아마도 Microsoft가 원래 전체 Assembly Version의 엄격한 일치에 대해 메이저 버전과 마이너 버전 부분만 일치시키는 것에 대해 조금 더 관대하게 하려고 했기 때문이라고 생각합니다.

"어셈블리를 로드할 때 CLR은 자동으로 요청 중인 어셈블리의 주/부 버전과 일치하는 최신 설치 서비스 버전을 찾습니다." – Jeffrey Richter, [CLR via C# (Second Edition)] 56페이지

이것은 1.0 CLR의 베타 1에서 수행된 동작이지만 이 기능은 1.0 릴리스 이전에 제거되었으며 .NET 2.0에서 다시 표면화되지 않았습니다.

"참고: 방금 버전 번호에 대해 어떻게 생각해야 하는지 설명했습니다.안타깝게도 CLR은 버전 번호를 이러한 방식으로 처리하지 않습니다.[.NET 2.0]에서 CLR은 버전 번호를 불투명 값으로 처리하며 어셈블리가 다른 어셈블리의 버전 1.2.3.4에 종속된 경우 CLR은 바인딩 리디렉션이 없는 한 버전 1.2.3.4만 로드하려고 합니다.그러나 Microsoft는 CLR의 로더를 향후 버전에서 변경하여 주어진 주/부 버전의 어셈블리에 대한 최신 빌드/리비전을 로드할 계획입니다.예를 들어 CLR의 미래 버전에서 로더가 어셈블리의 버전 1.2.3.4를 찾으려 하고 버전 1.2.5.0이 있는 경우 로더가 최신 서비스 버전을 자동으로 선택합니다.이것은 CLR 로더에 매우 반가운 변화가 될 것입니다. 저는 기다릴 수 없습니다." - Jeffrey Richter, [CLR via C# (Second Edition)] 페이지 164 (광산 강조)

이러한 변화가 아직 구현되지 않았기 때문에 Microsoft가 이러한 의도를 역추적했다고 가정해도 무방할 것이며, 지금 이를 변경하기에는 너무 늦은 것 같습니다.저는 이 계획들에 무슨 일이 일어났는지 알아보기 위해 웹을 검색하려고 했지만, 답을 찾을 수 없었습니다.저는 여전히 그것의 진상을 알고 싶었습니다.

그래서 저는 제프 리히터에게 이메일을 보내 직접 질문을 했습니다. 만약에 무슨 일이 일어났는지 아는 사람이 있다면, 그 사람일 거라고 생각했습니다.

그는 토요일 아침에 12시간 이내에 응답했고 .NET 1.0 베타 1 로더가 어셈블리의 최신 빌드 및 리비전을 선택하는 이 '자동 롤포워드' 메커니즘을 구현했지만 이 동작은 .NET 1.0이 출하되기 전에 되돌렸습니다.나중에 이것을 되살리려고 했지만 CLR 2.0이 출시되기 전에는 성공하지 못했습니다.그리고 CLR 팀을 우선시하는 Silverlight가 등장하여 이 기능은 더욱 지연되었습니다.그동안 CLR 1.0 베타 1 시대에 있었던 대부분의 사람들이 그 이후로 이동했기 때문에 이미 많은 노력을 기울였음에도 불구하고 이 작업이 빛을 보게 될 것 같지는 않습니다.

현재의 행동은 여기에 머물러 있는 것처럼 보입니다.

또한 Jeff와의 논의에서 AssemblyFileVersion은 '자동 롤포워드' 메커니즘을 제거한 후에만 추가되었습니다. 1.0 베타 1 이후에는 AssemblyVersion의 변경 사항이 고객에게 획기적인 변경 사항이었기 때문에 빌드 번호를 안전하게 저장할 수 있는 곳이 없었습니다.AssemblyFileVersion은 CLR에 의해 자동으로 검사되지 않으므로 안전한 피난처입니다.그러면 어셈블리 버전의 주/부차(분할) 부분과 빌드/수정(분할) 부분을 구분하는 것보다 두 개의 개별 버전 번호와 별도의 의미를 갖는 것이 더 명확할 수 있습니다.

결론:당신이 언제 당신의 것을 바꾸는지 잘 생각하세요.AssemblyVersion

다른 개발자들이 참조할 어셈블리를 발송할 경우 어셈블리 버전을 변경할 때(그리고 변경하지 않을 때) 매우 주의해야 합니다.AssemblyVersion을 변경하면 응용 프로그램 개발자가 새 버전에 대해 다시 컴파일하거나(이러한 AssemblyRef 항목을 업데이트하기 위해) 어셈블리 바인딩 리디렉션을 사용하여 바인딩을 수동으로 재정의해야 합니다.

• 이전 버전과 호환되는 서비스 릴리스의 AssemblyVersion을 변경하지 마십시오.
• 변경 사항이 있는 릴리스에 대해 어셈블리 버전을 변경합니다.

mscorlib의 버전 특성을 다시 한 번 살펴 보십시오.

// Assembly mscorlib, Version 2.0.0.0
[assembly: AssemblyFileVersion("2.0.50727.3521")]
[assembly: AssemblyInformationalVersion("2.0.50727.3521")]
[assembly: AssemblyVersion("2.0.0.0")]

AssemblyFileVersion에는 모든 흥미로운 서비스 정보가 포함되어 있습니다(어떤 서비스 팩에 있는지 알려주는 이 버전의 Revision 부분). 반면 AssemblyVersion은 지루한 2.0.0.0으로 고정되어 있습니다.AssemblyVersion을 변경하면 mscorlib.dll을 참조하는 모든 .NET 응용 프로그램이 새 버전을 기준으로 다시 컴파일됩니다!

AssemblyVersion에 거의 있는 .NET은 .NET 내부에 있습니다.AssemblyFileVersionWindows(윈도우)에 표시됩니다.디렉토리에 있는 어셈블리의 속성으로 이동하여 버전 탭으로 전환하는 경우AssemblyFileVersion위에 보시면 알 수 있습니다.버전별로 파일을 정렬하면 탐색기에서 사용하는 항목입니다.

그AssemblyInformationalVersion"제품 버전"에 매핑되며 순수하게 "인간이 사용하는" 것을 의미합니다.

AssemblyVersion확실히 가장 중요하지만, 저는 건너뛰지 않을 것입니다.AssemblyFileVersion 다요 느하나어하나▁either.않하지는을 제공하지 .AssemblyInformationalVersion컴파일러는 당신의 버전 번호의 "sla" 부분을 제거하고 major.dll을 남겨 당신을 위해 그것을 추가합니다.체격이 좋은

AssemblyInformationalVersion그리고.AssemblyFileVersion파일 속성을 보고 Windows 탐색기를 통해 파일의 "버전" 정보를 볼 때 표시됩니다.는 한속실다같이컴파다니됩일과음제로로 됩니다.VERSION_INFO컴파일러에서 생성한 리소스입니다.

AssemblyInformationalVersion는 "제품 버전" 값입니다. AssemblyFileVersion는 "파일 버전" 값입니다.

그AssemblyVersion..에 로드하는 데 됩니다.NET 어셈블리에 한정되며 .NET 어셈블리 로더에서 런타임에 로드/바인딩할 어셈블리 버전을 파악하는 데 사용됩니다.

중 .은 이뿐입니다.NET에서 절대적으로 필요한 것은AssemblyVersion도 무분별하게 때 큰 문제를 수 . 의 어셈블리에 것이 말이죠.안타깝게도, 특히 어셈블리 이름을 강력하게 지정하는 경우 무차별적으로 변경될 때 가장 많은 문제가 발생할 수 있습니다.

이 질문을 최신 상태로 유지하기 위해 강조할 가치가 있습니다.AssemblyInformationalVersionNuGet에서 사용되며 릴리스 전 접미사를 포함한 패키지 버전을 반영합니다.

예를 들어 asp.net core dotnet-cli와 함께 패키지된 1.0.3.*의 AssemblyVersion

dotnet pack --version-suffix ci-7 src/MyProject

다음을 사용하여 반사 검사할 수 있는 버전 1.0.3-ci-7로 패키지를 생성합니다.

CustomAttributeExtensions.GetCustomAttribute<AssemblyInformationalVersionAttribute>(asm);

다음과 같은 몇 가지 사항에 주목할 필요가 있습니다.

1. 생성된 어셈블리 파일에 대한 Windows 탐색기 속성 대화상자에 표시된 것처럼 "파일 버전"이라는 두 개의 위치가 있습니다.대화상자의 헤더에 표시된 것은 AssemblyFileVersion이 아니라 AssemblyVersion을 표시합니다.

   기타 버전 정보 섹션에는 "파일 버전"이라는 다른 요소가 있습니다.여기서 어셈블리 파일 버전으로 입력된 내용을 볼 수 있습니다.

2. AssemblyFileVersion은 일반 텍스트입니다.AssemblyVersion이 수행하는 번호 지정 체계 제한(<build> < 65K 등)을 준수할 필요는 없습니다.3.2가 될 수 있습니다.<release 태그 텍스트>.원한다면, <datetime>.빌드 시스템에서 토큰을 입력해야 합니다.

   또한 AssemblyVersion과 같은 와일드카드 대체가 적용되지 않습니다.값이 "3.0.1"이면 됩니다.AssemblyInfo.cs 에서, 이것이 바로 기타 버전 정보->파일 버전 요소에 표시되는 내용입니다.

3. 하지만 설치 프로그램에서 숫자 파일 버전 번호가 아닌 다른 것을 사용하는 것이 어떤 영향을 미치는지는 모르겠습니다.

어셈블리의 AssemblyVersion이 변경될 때 이름이 강력한 경우 참조 어셈블리를 다시 컴파일해야 합니다. 그렇지 않으면 어셈블리가 로드되지 않습니다!강력한 이름이 없으면 프로젝트 파일에 명시적으로 추가되지 않으면 빌드 시 출력 디렉터리에 복사되지 않으므로 특히 출력 디렉터리를 정리한 후에 어셈블리에 종속되지 않을 수 있습니다.

언급URL : https://stackoverflow.com/questions/64602/what-are-differences-between-assemblyversion-assemblyfileversion-and-assemblyin