.cs 파일을 프로젝트에 링크하는 것보다 .dll 파일을 사용할 때의 장점 (내 자신의 일반적인 도우미 클래스 / 확장 방법의 경우)

내가 만든 모든 응용 프로그램에서 사용하는 도우미 프로젝트가 있습니다. 여기에는 몇 가지 확장 메서드와 많은 일반 도우미 클래스, 컨트롤 등이 포함되어 있습니다. 도우미 프로젝트를 수시로 업데이트 / 확장합니다. 이들은 일반적으로 규모가 작고 관련이없는 프로젝트이며, 나는 그들 모두에서 일하는 유일한 사람입니다.

나는 그것을 사용하기 위해 두 가지 접근법을 시도했다.

• 내가 사용하는 각 프로젝트에 .cs 파일을 직접 추가 (링크로 추가)
• .dll로 컴파일하고 참조로 추가하십시오.

이러한 접근 방식의 장점과 단점이 있습니다.
첫번째:

• 도우미 클래스가 exe 파일로 컴파일되기 때문에 더 간단합니다. 따라서 종종 잘 작동하는 단일 .exe 파일을 매우 쉽게 제공 할 수 있습니다. 링크로 추가하기 때문에 도우미를 사용하는 프로젝트를 빌드 할 때마다 도우미 파일이 최신 버전이 될 것입니다.
• .NET 4.0에서 잘 실행되는 확장 방법을 .NET 4.5가 필요한 확장 방법과 별도로 참조 할 수 있도록 파일을 분리 할 수 ​​있기 때문에 훨씬 간단합니다. 따라서 앱 전체가 .NET 4.0에서 실행될 수 있습니다
• 중단 점 등의 모든 이점과 함께 코드를 통해 디버그 할 수 있습니다 ...
• '모범 사례'가 아닌 것 같습니다

두 번째 것 :

• 올바른 접근 방식 인 것처럼 보이지만 다음과 같습니다.
• 별도의 .dll 파일을 제공해야하는데, 어떤 이유로 든 사용자들에게는 훨씬 더 어렵습니다 (.dll없이 프로그램을 공유하는 경향이 있습니다.
• 단일 .dll로 컴파일되면 최상위 버전의 .NET이 필요합니다. 많은 사용자에게는 .NET 4.5가 없으며 내 도우미 클래스의 일부 요소에만 필요합니다. 이유없이 시스템을 업데이트
• 또한 프로그램을 업데이트 할 때마다 .dll 파일도 제공해야합니다. 마지막 버전 이후로 변경되었는지 여부는 알 수 없지만 (있을 수도 있지만 가능하지는 않습니다) 같은 버전 일 수도 있습니다). 어셈블리 버전을 추적하지 않고 추가 작업을 수행하는 간단한 방법을 알 수 없습니다. 지금은 프로그램을 업데이트 할 때 업데이트 된 exe 만 제공하며 작고 낮은 프로파일을 유지하고 싶습니다.

그렇다면 .dll 파일을 사용하면 실제로 어떤 이점이 있습니까? 본인은 모든 응용 프로그램 및 도우미 파일의 코드를 편집하는 유일한 사람입니다.

또한 명확히하기 위해-응용 프로그램은 일반적으로 매우 작지만 도우미 클래스에 포함 된 코드는 모든 응용 프로그램에 대해 일반적입니다 (일부 간단한 문자열 비교, 경로 또는 XML 작업 등)

실제로 누군가가 지금 세 번째 옵션이 있음을 깨닫게했습니다. separte 프로젝트에 도우미 코드가 있으므로이 프로젝트를 별도의 각 응용 프로그램의 솔루션에 추가 할 수 있습니다. 단일 프로젝트 만 추가하는 것을 제외하고는 단일 파일의 '링크로 추가'와 같은 방식으로 작동합니다 ...하지만 Doc Brown이 알 수 있듯이 이것은 본질적으로 .dll을 프로젝트에 추가해야한다는 것을 의미합니다 ...

dll 파일을 사용하지 않는 데 도움이되는 또 다른 것은 도우미 클래스를 적극적으로 디버깅하는 기능입니다 ...

당신은 이미 대부분의 장단점을 발견했습니다. cs 파일을 참조로 사용하는 것이 실제로보다 가볍고 종종 관리하기가 더 쉽습니다. 그러나 cs파일이 완전히 자체 포함되어 있고 특별한 빌드 요구 사항이없는 경우에만이 방법을 사용하는 것이 좋습니다 .

별도의 DLL 사용

• 다른 유틸리티 또는 라이브러리에 대한 종속성을 명시 적으로 만듭니다 (그러한 종속성이없는 한 정상적으로 작동합니다)

• 특정 빌드 구성을 정의 할 수 있습니다 (예를 들어, 클래스가 x86 구성에서만 작동하거나 .NET 4.0 이상이 필요한 경우 어셈블리의 빌드 구성으로 인해이 요구 사항이 명확 해집니다).

따라서 특히 단일 클래스의 자체 포함 구성 요소가 많은 경우 파일 참조를 사용하는 것이 좋지만 다른 구성 요소를 참조하는 구성 요소 또는 특정 빌드 요구 사항이있는 경우 DLL을 사용하는 것이 좋습니다.

많은 개별 DLL을 관리 할 때 발생하는 문제를 완화하기 위해 설치 관리자 패키지를 만들거나 ILMerge를 사용 하여 어셈블리 집합을 단일 실행 파일에 포함시킬 수 있습니다. 우리 환경에서는 각 응용 프로그램마다 배포 스크립트를 사용하여 문제를 다르게 처리합니다. 이 스크립트는 새 응용 프로그램 릴리스가 게시 될 때 필요한 모든 DLL이 항상 프로덕션에 제공되도록합니다.

DLL은 응용 프로그램이 크고 업데이트가 필요한 부분이 있지만 전체 응용 프로그램이 아닌 경우에 유용합니다. 따라서 MS Word를 작성하는 경우 MS Word 전체를 업데이트하지 않고도 업데이트 할 수있는 맞춤법 검사 코드를 DLL로 작성하는 것이 편리합니다. 작성중인 것이 작은 유틸리티 응용 프로그램 (또는 모두 동일한 코드를 사용하는 일련의 자체 포함 된 응용 프로그램) 인 경우 코드가 응용 프로그램에 포함되어 있는지 여부에 큰 차이가 없습니다.

당신은 당신의 질문에 거의 요약 했으므로 추가 할 점이 몇 개뿐입니다.

Mono Options 는 첫 번째 접근 방식을 잘 사용하는 NuGet 패키지의 훌륭한 예입니다.

또는 dll을 사용하기로 결정한 경우 Costura 와 같은 도구를 사용 하여 해당 참조를 실행 파일에 포함 된 리소스로 포함시킬 수 있습니다. 사용하려면 Costura.Fody패키지를 추가하십시오 .

Install-Package Costura.Fody

dll이 더 유리한지 아닌지는 몇 가지 요소에 달려 있습니다.

1. 코드 크기 (컴파일시)
2. 얼마나 많은 exes가 사용합니까?
3. 코드를 업데이트하려는 빈도입니다.
4. exe가 함께 유지되거나 완전히 분리되어 존재하는지 여부입니다.

공유 라이브러리의 목적은 여러 실행 파일에 공통적 인 코드를 가져 와서 중앙 집중화하여 모든 실행 파일이 복사본을 공유하는 것입니다. 공간을 절약하고 코드를보다 쉽게 ​​업데이트 할 수 있도록하기위한 것입니다.

도우미 클래스의 코드 양이 매우 적 으면 dll에있는 코드의 오버 헤드가 중앙 집중화의 공간 절약 이점을 방해 할 수 있으므로 dll로 옮길 가치가 없습니다.

또한 실행 파일을 몇 개만 만드는 경우 각 실행 파일의 코드 크기가 문제가되지 않을 정도로 작을 수 있습니다. 그러나 동일한 코드를 사용하는 실행 파일이 많을수록 코드를 dll로 옮기는 것이 유리합니다.

간단한 예로, 도우미 클래스가 exe 파일에서 128 바이트로 컴파일하지만 dll로 이동하면 dll은 512 바이트라고 가정합니다. 실행 파일이 3 개 뿐인 경우 실행 파일에 코드를 포함하여 공간을 절약 할 수 있습니다. 그러나 5 개의 실행 파일이있는 경우 5 개의 코드 사본 (5 * 128 = 640 바이트)이 차지하는 결합 공간이 차지하는 공간보다 많기 때문에 dll을 사용하는 것이 좋습니다. dll (512 바이트)에 코드를 사용하여.

예를 들어 도우미 코드에서 버그를 발견했다고 가정 해보십시오. 구운 코드를 사용하여 모든 실행 파일을 컴파일 한 경우 모든 단일 실행 파일을 다시 컴파일 한 다음 다시 컴파일 된 버전을 다시 배포해야합니다. 코드를 dll로 컴파일하면 하나의 dll 만 재 컴파일하고 재배포해야하며 버그는 자동으로 수정되어 사용하는 모든 실행 파일에 대해 수정됩니다.

마지막으로, dll을 찾는 프로그램의 경우 dll을 찾을 위치를 알아야합니다. 모든 실행 파일을 함께 유지하는 경우 dll을 동일한 디렉토리에 넣으면 바로 찾을 수 있습니다. 의도적으로 분리 된 상태로 유지하면 동일한 dll을 사용하도록 조정하기가 더 어려워집니다.

세 번째 옵션이 가장 적합합니다 (솔루션에 별도의 "클래스 라이브러리"프로젝트로 추가). 이것은 모든 접근 방식의 이점을 결합합니다.

• "도우미 프로젝트"는 항상 모든 다른 프로젝트에서 최신 상태입니다.
• 변경 사항을 신속하게보고 싶을 때 프로젝트 코드를 참조 할 수 있습니다.
• 매번 올바른 .NET 버전으로 빌드 할 수 있습니다.
• 어쨌든 exe에 DLL을 포함시킬 수 있으므로 빌드의 일부로 DLL을 가질 수 있다고 걱정하지 마십시오.

우리는 항상 이것을하고 아무것도 할 수 없지만이 방법을 권장합니다.

언급하지 않은 또 다른 네 번째 대안은 개인 NuGet 저장소에 배치하여 올바른 버전을 지정하고 각 솔루션의 추가 프로젝트없이 참조 할 수 있도록하는 것입니다.

개발자는 항상 코드를 디버깅하고 (유틸리티에서 가능한 버그를 발견 할 수 있도록) 유틸리티의 모든 변경 사항이 응용 프로그램에 자동으로 포함되므로 유틸리티 솔루션 참조를 항상 응용 프로그램에 포함하고 싶습니다.

따라서 실제로 결정 은 유틸리티의 성숙도에 달려 있습니다 ! 유틸리티 버그에 대해 잘 모르는 경우 버그를 찾기 위해 항상 해당 유틸리티의 .cs 파일을 포함시켜야합니다. 그러나 유틸리티가 충분히 성숙하여 어떤 버그로도 결과를 반환하지 않을 경우 유틸리티의 향상을위한 범위는 없습니다. 계속해서 DLL 파일을 포함시킬 수 있습니다.