vs2008로 컴파일 된 소스는 명령 줄에서 csc가 직접 컴파일 한 동일한 소스와 다른 바이너리를 생성합니다.

Question

왜 소스를 Visual Studio 2008 (MSBuild)과 함께 컴파일 한 다음 csc (또는 NANT) 명령 행에서 같은 바이너리 파일 (동일한 어셈블리)을 exacly 얻을 수 없습니다.

출력 창에서 명령을 복사 한 다음 명령을 vs2008 명령 프롬프트에 붙여 넣기 때문에 Visual Studio에서 명령 줄을 호출하는 명령 줄은 동일합니다.

나는 같은 소스를 다른 시간에 컴파일하면 어셈블리 메타 데이터의 타임 스탬프 때문에 다른 바이너리를 얻는다는 것을 알고있다. 사실, vs2008에서 생성 한 두 개의 바이너리를 서로 다른 시간에 비교하면 바이너리 데이터 간의 작은 차이가 있음을 알 수 있습니다.

하지만 vs로 컴파일 한 다음 csc로 컴파일하면 바이너리가 매우 다릅니다! 이유를 알고 계십니까? 뭐가 문제 야?

Answer 1

컴파일러에서 만든 메타 데이터의 특정 순서에 대한 보장은 없습니다. 즉, in-proc 컴파일러와 csc.exe간에 다른 순서를 고의로 일으키는 것은 없습니다.

Answer 2

대담한 추측이지만 VS IDE와 터미널에서 환경 변수가 같지 않을 수 있습니다. 더 나쁜 경우에는 아마도 다른 .NET Framework 또는 적어도 다른 라이브러리/코드 파일 또는 컴파일러 스위치에 대해 터미널 버전 링크가 연결되어 있을까요?

Answer 3

Visual Studio에서 디버그 빌드를 빌드하는지 이진 빌드를 빌드하는지 여부는 밝혀지지 않았습니다. 명령 줄 기본값이 중 하나 인과 동일하지는 않습니다.

명시적인 /debug 및 /o 스위치 (원하는대로 설정)로 빌드하고 Visual Studio에서 일치시켜보십시오. 또한 Visual Studio 빌드 구성에서 정의 된 경우 DEBUG 및/또는 TRACE 기호를 정의하십시오.

Answer 4

@ Marc Gravell, Divo, Jon : ILDASM으로 두 개의 엉덩이를 분해하려고합니다. 깊은 분석과 비교를 한 결과, 일리노이의 내용은 거의 동일하지만 모든 클래스와 메소드, 속성 getter와 setter 등은 어셈블리에서 매우 다른 순서로 존재한다는 것을 알았습니다! 그래서 두 어셈블리를 16 진수 편집기/비교 자와 비교해 보면 전혀 다른 바이너리 바디를 볼 수 있습니다!

이제 VS와 Csc가이 다른 방식으로 컴파일러와 상호 작용하는 이유를 알아야합니다!

두 가지 승인을 설명하는 문서에 대한 참조가 있습니까?