.NET에서 정적 라이브러리와 동일합니까?

저는 관리되는 코드 (주로 C++/CLI)에서 '일반 사용자'버전과 '프로'버전의 두 가지 버전으로 도구를 구축하고 있습니다..NET에서 정적 라이브러리와 동일합니까?

핵심 코드가 두 버전간에 동일하다는 사실 때문에 결과 도구를 단일 어셈블리 (DLL)로 패키징하고 .cpp를 포함하지 않아도되기 때문에 약간의 문제가있었습니다. 두 가지 버전의 도구 프로젝트에서 공통 코드에 대한 파일. 차라리 공통 코드에 대한 프로젝트와 각 버전의 프로젝트에 대한 프로젝트를 가지며 도구 프로젝트의 각 버전을 공통 코드에 의존하고 원하는대로 링크 할 수 있습니다.

관리되지 않는 C++에서는 정적 라이브러리에 공통 코드를 삽입하고 두 버전의 도구를이 라이브러리에 연결하면됩니다. 이 C++/CLI에서 작동하도록 할 수없는 것 같습니다. DLL 어셈블리에 공통 코드를 작성해야하고 DLL보다 더 많은 결과를 얻는 것 같습니다.

요약하면 하나의 프로젝트에서 공통 코드를 작성하고 각 최종 제품 프로젝트와 연결하여 공통 코드를 포함하는 두 개의 단일 DLL 어셈블리를 생성하는 방법을 알아낼 수 없습니다.

나는 아마 뭔가 잘못하고 있지만 netmodules를 사용하여이 작업을 수행하는 방법을 알아 내려고 노력했습니다. 그리고 나는 그걸 작동시키지 못했습니다. 결국 나는 그것이 작동하는 유일한 방법은 작동하는 결과보다는 공통 코드 어셈블리의 빌드 제품을 링크하도록 링커에 지시하는 것이지만 해킹 IMHO 비트입니다.

어쨌든 누구든지이 문제를 해결하는 방법에 대한 제안이 있습니까?

편집 됨 : 편집 된 어셈블리는 100 % 관리 코드가 아니며 관리되는 코드와 관리되지 않는 코드가 혼합되어 있다는 사실을 언급 했어야합니다. 아마도 C++/CLI로 생성 된 어셈블리와 매우 공통적입니다. ...

출처

2009-10-02 Len Holgate

단일 DLL로 패키지해야한다는 생각을 없애는 것이 좋습니다. –

모든 DLL에서 짜증이 난다면 ILMerge을 다운로드하십시오. 나는 이것을 사용하여 여러 개의 DLL을 내 고객을위한 사용하기 쉬운 .EXE로 묶는다.

출처

2009-10-02 08:55:18 PaulMcG

고마워, 내가 살펴볼 게. –

아마도 어셈블리 중 하나가 100 % 관리되는 코드가 아니라고 언급 했어야합니다 ... ILMerge가 작동하지 않습니다. ( –

Paul,이 답변을 받아 들였습니다. 어셈블리에서 관리되지 않는 코드가 없습니다. 여전히 혼합 어셈블리와 함께 작동하는 솔루션을 찾고 있습니다. 아직 모듈 문제를 조사하지 않았습니다. –

.Net 컴파일 프로세스의 단점은 정적 라이브러리와 헤더 파일을 함께 유지할 수 없으며 모든 것이 하나의 큰 dll 파일과 정보를 공유하는 유일한 방법으로 유지된다는 것입니다. 공통 dll을 빌드하고 다른 어셈블리에서 참조하거나 (프로젝트간에 .cs 파일을 복사/링크하여) 각 dll의 코드를 복제하는 것입니다.

두 번째 방법은 이름이 같더라도 다른 유형을 선언한다는 점에 유의하십시오. 이것은 리모팅 (또는 프로세스들 사이의 특정 공유 인터페이스에 캐스팅을 요구하는 것)과 같은 것들로 엉덩이에 당신을 물 것입니다.

출처

2009-10-02 08:49:53 Blindy

두 번째 단락에 대해 좀 더 설명해 주시겠습니까? 링커 링크를 통해 공통 코드 어셈블리의 제품을 최종 어셈블리에 빌드하면 이러한 문제가 발생할 것이라고 말하고 있습니까? –

그렇기 때문에 원격 작업을 수행 할 때 공용 인터페이스는 서버와 클라이언트 프로그램에서 모두 참조되는 세 번째 .dll 파일에 보관됩니다. 2 개의 서로 다른 어셈블리에서 같은 이름과 구조를 갖는 타입을 가지면, 메타 데이터가없는 관리되지 않는 C++ 라이브러리와는 다른 두 가지 유형이 생성되므로 두 버전의 프로그램에서 동일한 구조화 된 유형을 볼 수 있습니다. – Blindy

Remotesoft Salamander으로 연결됩니다. 기본적으로 원시 컴파일러 및 링커입니다.

출처

2009-10-02 08:58:55 AngryHacker

감사합니다. 원하는 것은 조금 비싸지 만, 그것도 내 난독 화 요구 사항을 해결할 수 있습니다 봐 ... –

다시 관리/관리되지 않는 혼합 된 어셈블리를 처리하지 않습니다 ... –

마찬가지로 ILmerge 편도, 개인적으로 귀하의 번들링 DLL이 많은 경우 나는 많은 것을 선호합니다 Netz.

출처

2009-10-02 09:00:29 Nils

감사합니다 닐스, 그것을 밖으로 시도하겠습니다! –

1) exe 인 출력이 필요해 것 같습니다 (내 응용 프로그램은 DLL로 패키지되어 있습니다). 2) 관리 형/비 관리 형 혼합 C++/CLI 어셈블리를 처리하지 않습니다. –

1) 예 - "dll 전용"패키지를 처리 할 수 없습니다 .. 2) "mkbundle"에 대해 살펴 보았습니까? (다른 답변을 참조하십시오) - cygwin은 다소 이상한 전제 조건 일 수 있지만 IMO mkbundle은 managed/관리되지 않는 믹스 - 그러나 : 나는 그것을 수동으로 시도하지 않았습니다. (항상 원했고, 힘들었습니다.) – Nils

mono (또는 cygwin이 옵션 일 때) mkbundle을 사용하는 것이 유효한 선택 일 수도 있습니다.

출처

2009-10-02 09:04:38 Nils

modules을 사용할 수 있습니다. 조립 링커 인 al.exe을 사용하여 조립품에 어셈블리를 연결할 수 있습니다.

출처

2009-10-02 09:10:39

나는 그것을 시도했지만 제대로 작동하지 않을 수 있습니다. 이것을 설정하는 방법에 대한 간단한 예를 알고 있습니까? 이상적으로 코드가 VS2008로 빌드 될 수 있고 모듈이 사용자 정의 빌드 단계와 병합 되었습니까? –

아니요, 잘 모르겠습니다. 모듈은 꽤 난해합니다. –

정확하게 이해하고 있다면 두 가지 프로젝트가 포함 된 솔루션이 있습니다. "일반"사용자를위한 하나의 프로젝트와 "프로"사용자를위한 하나의 프로젝트.Visual Studio에서는 다른 프로젝트의 다른 파일 소스에 "링크"를 추가 할 수 있습니다. "pro"버전에 실제 코어 코드 파일이 있고 "normal"버전에 "pro"프로젝트에서 파일을 찾은 다음 추가 버튼으로 아래쪽 화살표를 클릭하고 "Add as Link"를 선택하십시오 ". 이제 두 프로젝트간에 문자 그대로 동일한 단일 파일이 생깁니다.

출처

2009-11-12 04:17:38

Erik, 확장 성 관점에서 볼 때 약간의 어려움이 있습니다. 즉, 프로젝트 1에서 코드의 90 %에 의존하는 다른 프로젝트를 추가하기가 쉽지 않습니다. 나는 그것을 줄 것이다. –

사실,하지만 확장 성 문제가 다른 일반, 프로 등의 버전간에 문제가 될 것이라고 생각합니다. 자신의 DLL에 대해 코드를 작성하려고한다면 프로 버전을 사용하게 될 것이라고 생각합니다. :). –

.NET에서 정적 라이브러리와 동일합니까?

답변

관련 문제