•  08-06-2019
  •  | 
  •  

문제

ILMerge를 사용하시나요?dll 배포를 쉽게 하기 위해 ILMerge를 사용하여 여러 어셈블리를 병합합니까?ILMerging 어셈블리를 함께 사용한 후 프로덕션 환경에서 배포/버전 관리에 문제가 있습니까?

가능하다면 배포 마찰을 줄이기 위해 ILMerge를 사용하는 것과 관련하여 몇 가지 조언을 찾고 있습니다.

도움이 되었습니까?

해결책

저는 거의 모든 다양한 애플리케이션에 ILMerge를 사용합니다.릴리스 빌드 프로세스에 바로 통합했기 때문에 결국에는 추가 dll 없이 애플리케이션당 하나의 exe가 생성되었습니다.

네이티브 코드가 있는 C++ 어셈블리는 ILMerge할 수 없습니다.또한 WPF용 XAML이 포함된 어셈블리를 ILMerge할 수 없습니다(적어도 저는 성공하지 못했습니다).런타임에 리소스를 찾을 수 없다고 불평합니다.

병합하려는 프로젝트의 시작 exe 이름과 출력 exe 이름을 전달하는 ILMerge용 래퍼 실행 파일을 작성한 다음 종속 어셈블리를 반영하고 적절한 명령줄 매개 변수를 사용하여 ILMerge를 호출합니다.이제 프로젝트에 새 어셈블리를 추가할 때 빌드 스크립트를 업데이트하는 것을 기억할 필요가 없어 훨씬 쉬워졌습니다.

다른 팁

소개

이 게시물은 모두 교체하는 방법을 보여줍니다. .exe + .dll files 싱글로 combined .exe.또한 디버깅을 유지합니다. .pdb 파일은 그대로 유지됩니다.

콘솔 앱의 경우

여기에 기본이 있습니다 Post Build String Visual Studio 2010 SP1의 경우 .NET 4.0을 사용합니다.모든 하위 .dll 파일이 포함된 콘솔 .exe를 작성 중입니다.

"$(SolutionDir)ILMerge\ILMerge.exe" /out:"$(TargetDir)$(TargetName).all.exe" "$(TargetDir)$(TargetName).exe" "$(TargetDir)*.dll" /target:exe /targetplatform:v4,C:\Windows\Microsoft.NET\Framework64\v4.0.30319 /wildcards

기본 힌트

  • 출력은 "AssemblyName.all.exe"는 모든 하위 DLL을 하나의 .exe로 결합합니다.
  • 주목하세요 ILMerge\ 예배 규칙서.ILMerge 유틸리티를 솔루션 디렉터리에 복사하거나(ILMerge 설치 문서화에 대해 걱정할 필요 없이 소스를 배포할 수 있도록) ILMerge.exe가 있는 위치를 가리키도록 이 경로를 변경해야 합니다.

고급 힌트

작동하지 않는 문제가 있으면 켜십시오. Output, 을 선택하고 Show output from: Build.Visual Studio에서 실제로 생성한 정확한 명령을 확인하고 오류가 있는지 확인하세요.

샘플 빌드 스크립트

이 스크립트는 모든 것을 대체합니다. .exe + .dll files 싱글로 combined .exe.또한 디버깅 .pdb 파일을 그대로 유지합니다.

사용하려면 이것을 붙여넣으세요. Post Build 단계, 아래 Build Events C# 프로젝트의 탭에서 첫 번째 줄의 경로가 다음을 가리키도록 조정했는지 확인하세요. ILMerge.exe:

rem Create a single .exe that combines the root .exe and all subassemblies.
"$(SolutionDir)ILMerge\ILMerge.exe" /out:"$(TargetDir)$(TargetName).all.exe" "$(TargetDir)$(TargetName).exe" "$(TargetDir)*.dll" /target:exe /targetplatform:v4,C:\Windows\Microsoft.NET\Framework64\v4.0.30319 /wildcards
rem Remove all subassemblies.
del *.dll
rem Remove all .pdb files (except the new, combined pdb we just created).
ren "$(TargetDir)$(TargetName).all.pdb" "$(TargetName).all.pdb.temp"
del *.pdb
ren "$(TargetDir)$(TargetName).all.pdb.temp" "$(TargetName).all.pdb"
rem Delete the original, non-combined .exe.
del "$(TargetDir)$(TargetName).exe"
rem Rename the combined .exe and .pdb to the original project name we started with.
ren "$(TargetDir)$(TargetName).all.pdb" "$(TargetName).pdb"
ren "$(TargetDir)$(TargetName).all.exe" "$(TargetName).exe"
exit 0

우리는 Microsoft 애플리케이션 블록에서 ILMerge를 사용합니다. 12개의 개별 DLL 파일 대신 클라이언트 영역에 업로드할 수 있는 단일 파일이 있고 파일 시스템 구조가 훨씬 더 깔끔해졌습니다.

파일을 병합한 후 Visual Studio 프로젝트 목록을 편집하고 12개의 개별 어셈블리를 제거하고 단일 파일을 참조로 추가해야 했습니다. 그렇지 않으면 특정 어셈블리를 찾을 수 없다고 불평할 것입니다.하지만 이것이 배포 후 어떻게 작동할지 잘 모르겠습니다. 시도해 볼 가치가 있습니다.

이것이 오래된 질문이라는 것을 알고 있지만 우리는 ILMerge를 사용하여 종속성 수를 줄일 뿐만 아니라 유틸리티에서 사용되는 "내부" 종속성(예: automapper, Restsharp 등)을 내부화합니다.이는 완전히 추상화되어 병합된 유틸리티를 사용하는 프로젝트가 이에 대해 알 필요가 없음을 의미합니다.이렇게 하면 프로젝트에서 필요한 참조가 다시 줄어들고 필요한 경우 동일한 외부 라이브러리의 자체 버전을 사용/업데이트할 수 있습니다.

우리는 꽤 많은 프로젝트에서 ILMerge를 사용합니다.그만큼 웹 서비스 소프트웨어 공장, 예를 들어 8개의 어셈블리를 출력으로 생성합니다.서비스 호스트가 하나의 DLL만 참조하면 되도록 모든 DLL을 단일 DLL로 병합합니다.

생활이 좀 더 편해지기는 하지만, 그다지 큰 문제도 아닙니다.

WPF 종속성을 결합하는 데에도 동일한 문제가 있었습니다....ILMerge는 이러한 문제를 처리하지 않는 것 같습니다.Costura.Fody는 우리에게 완벽하게 작동했지만 시작하는 데 약 5분이 걸렸습니다...아주 좋은 경험이었습니다.

Nuget으로 설치하면 됩니다(패키지 관리자 콘솔에서 올바른 기본 프로젝트 선택).대상 프로젝트에 자체적으로 소개되고 기본 설정이 즉시 작동했습니다.

"Copy Local" = true로 표시된 모든 DLL을 병합하고 크기가 훌륭하게 압축된(전체 출력 크기보다 훨씬 작은) 병합된 .EXE(표준 출력과 함께)를 생성합니다.

라이센스는 MIT이므로 필요에 따라 수정/배포할 수 있습니다.

https://github.com/Fody/Costura/

Windows GUI 프로그램(예: WinForms)의 경우 /target을 사용하는 것이 좋습니다.위넥스 스위치.
목표:exe 스위치는 병합을 생성합니다 콘솔 애플리케이션.

동일한 네임스페이스에 리소스가 있는 DLL을 병합할 때 문제가 발생했습니다.병합 프로세스에서 리소스 네임스페이스 중 하나의 이름이 변경되어 리소스를 찾을 수 없습니다.어쩌면 우리가 뭔가 잘못하고 있는 것일 수도 있고 여전히 문제를 조사하고 있는 것일 수도 있습니다.

우리는 다른 프로젝트에서 재배포 및 사용되는 솔루션에서 ILMerge를 사용하기 시작했으며 지금까지는 매우 훌륭했습니다.모든 것이 잘 작동하는 것 같습니다.우리는 패키지된 어셈블리를 직접 난독화하기도 했습니다.

우리는 MS Enterprise Library 어셈블리에도 동일한 작업을 수행하는 것을 고려하고 있습니다.

내가 본 유일한 실제 문제는 패키지의 개별 어셈블리 버전 관리입니다.

최근에 어셈블리에 어셈블리를 병합하는 문제가 발생했습니다. Umbraco 오픈 소스 CMS의 리플렉션을 통해 호출되는 일부 클래스가 있었습니다.

리플렉션을 통해 호출하기 위한 정보는 어셈블리 이름과 구현된 클래스의 네임스페이스 및 인터페이스가 있는 db 테이블에서 가져왔습니다.문제는 dll이 병합되면 리플렉션 호출이 실패하지만 dll이 분리되어 있으면 모두 잘 작동한다는 것입니다.내 생각에 문제는 longeasy가 겪고 있는 문제와 비슷할 수 있습니까?

저는 CI 빌드의 일부로 ILMerge를 사용하여 세밀하게 정리된 WCF 계약을 단일 라이브러리로 결합하기 시작했습니다.매우 잘 작동하지만 새로 병합된 lib는 해당 구성 요소 라이브러리 또는 해당 구성 요소 라이브러리에 의존하는 다른 lib와 쉽게 공존할 수 없습니다.

새 프로젝트에서 ILMerged lib와 ILMerge에 제공한 입력 중 하나에 의존하는 레거시 라이브러리를 모두 참조하는 경우 ILMerged lib의 어떤 유형도 다른 메소드로 전달할 수 없다는 것을 알게 될 것입니다. 일종의 유형 매핑을 수행하지 않고 레거시 라이브러리(예:자동 매퍼 또는 수동 매핑).모든 것이 컴파일되면 유형이 어셈블리 이름으로 효과적으로 한정되기 때문입니다.

이름도 충돌하지만 다음을 사용하여 문제를 해결할 수 있습니다. 외부 별칭.

내 조언은 병합된 어셈블리가 노출하는 공개적으로 사용 가능한 lib를 병합된 어셈블리에 포함하지 않는 것입니다(예:반환 유형, 메서드/생성자 매개 변수, 필드, 속성, 일반...)을 통해 병합된 어셈블리의 사용자가 동일한 라이브러리의 독립 버전에 의존하지 않으며 앞으로도 의존하지 않을 것이라는 점을 확실히 알지 않는 한.

제가 보기에 ILMerge 모범 사례 1위는 ILMerge를 사용하지 않는 것입니다.대신에 스마트어셈블리.그 이유 중 하나는 #2 ILMerge 모범 사례가 ILMerge를 수행한 후에 항상 PEVerify를 실행하는 것입니다. 왜냐하면 ILMerge는 어셈블리를 유효한 실행 파일로 올바르게 병합한다고 보장하지 않기 때문입니다.

기타 ILMerge 단점:

  • 병합할 때 XML 주석을 제거합니다(이 점에 관심이 있다면 난독화 도구를 사용할 것입니다).
  • 해당 .pdb 파일 생성을 올바르게 처리하지 않습니다.

주목할만한 또 다른 도구는 Mono.Cecil과 Mono.Linker [2] 도구입니다.

[2]:http://www.mono-project.com/Linker

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top