컴파일 구성을 변경할 때의 .NET 구성 요소 동작 차이

Visual Studio의 릴리스 또는 디버그 구성에서 컴파일되었는지 여부에 따라 다르게 동작하는 코드에 문제가 있습니다. 릴리스 구성에서 볼 수있는 모든 프로젝트 컴파일 설정을 수동으로 변경하여 디버그 파일과 일치 시키지만 문제는 계속 발생합니다.컴파일 구성을 변경할 때의 .NET 구성 요소 동작 차이

코드 (아래) 실행 어셈블리의 GUID를 반환. "인덱스 배열의 범위를 벗어난"

private static Guid GetApplicationUid() 
{ 
    Assembly assembly = Assembly.GetCallingAssembly(); 
    GuidAttribute attribute = (GuidAttribute)assembly.GetCustomAttributes(typeof(GuidAttribute), false)[0]; 
    return new Guid(attribute.Value); 
}

메소드가 실패 릴리스 모드에서 컴파일 한 후 실행될 때의 예외입니다. 디버그 모드에서 올바르게 작동합니다. 이 구성에서 GetExecutingAssembly()가 만든 어셈블리 참조가 기본 "실제"어셈블리가 아닌 임시 어셈블리 (예 : App_Web_eelfd0ff, Version = 0.0.0.0, Culture = neutral, PublicKeyToken = null) 때문입니다.

이상하게도, 동일한 코드를 사용하는 동일한 웹에서 실행중인 다른 구성 요소가 있고 컴파일 모드에 관계없이 동일하게 작동합니다.

왜 이런 일이 발생하며이를 방지하는 방법은 무엇입니까?

출처

2013-01-12 Paul Taylor

빌드중인 구성에 따라 변경되거나 디버거에 있는지 여부에 따라 변경됩니까? –

가능한 복제본은 왜 [이 어셈블리는 임시 asp.net dll입니까?] (http://stackoverflow.com/questions/4333833/why-is-this-assembly-a-temporary-asp-net-dll) –

That 기사에서는 디버그 모드와 릴리스 모드간에 컴파일 모델이 다르다고 제안하지만 릴리스 모드에서 반환되는 임시 DLL을 방지하는 방법은 설명하지 않습니다. –

최적화가 활성화되면 함수가 다른 어셈블리로 인라인 될 수 있습니다. this answer에 따라 MethodImplOptions.NoInlining을 추가하여 메서드가 어셈블리에 있다고 생각하면됩니다.

출처

2013-01-13 09:10:52

예외는 어셈블리 에 GUID 특성이이 없음을 의미합니다. 짐작 컨대, 어셈블리가 COM이 보이도록 설정되어 있지 않으면 컴파일러가 해제 모드로 최적화 할 수 있습니다 . 다른 작업 어셈블리를 확인하여 COM interop에 이으로 등록되어 있는지 확인하십시오.

GUID는 COM interop 용 .NET 어셈블리에서만 사용됩니다. COM interop을 원한다면 Visual Studio가 새 프로젝트를 만들 때 자동으로 GUID를 추가하지만 그렇지 않으면 쓸모가 없습니다.

출처

2013-01-12 19:07:55

둘 중 하나의 어셈블리가 COM interop에 대해 등록되지 않았습니다. 코드에서 검사 한 어셈블리에는 Guid 특성이 없다는 것이 맞습니다.하지만 그 이유는 릴리스 모드에서는 실제 DLL이 아닌 임시 DLL을 얻고 있기 때문입니다. –

컴파일 구성을 변경할 때의 .NET 구성 요소 동작 차이

답변

관련 문제