응용 프로그램에서 동일한 GUID의 영향

Question

새 C# 프로젝트가있을 때마다 대부분의 코드를 다시 사용하기 위해 기존의 코드를 복사하거나 이름을 바꾸는 경우가 있습니다. 이것은 Assembly Info에 들어가 프로젝트 이름을 변경하는 것을 의미합니다. 과거에는 GUID의 이름을 변경하는 데 정말로 신경 쓰지 않았습니다.

나쁜 프로그래밍 방식이며 같은 GUID로 다른 프로그램을 열면 사용자에게 부정적인 영향을 줄 수 있습니까?

필자는 결코 전문가 프로그래머는 아니지만, 필자는 필자와 같이 생각하고 있습니다. 모든 조언을 환영 할 것입니다.

Answer 1

GUID가 무엇에 사용되는지에 따라 다릅니다. 내가 합병증이 가 심각한 (아직 미묘한)을 일으킬 수 있다는 사실을 알고 GUID의 일부를 다시 사용 :

1. GUID를 어떤 방법으로 COM에 노출. 동일한 GUID를 가진 두 COM 구성 요소가 등록되면 매우 혼란스럽고 거의 해결할 수없는 충돌이 발생합니다.
2. GUID는 설치 프로젝트의 제품 ID입니다. 제품을 제거하거나 설치를 방해하는 상황에 처하는 것은 그리 재미있는 일이 아닙니다.
3. SharePoint의 대부분의 GUID입니다. (열 유형, 타이머 작업 등)

결국 가능한 한 다른 방법으로 "재사용"을 찾습니다.

해피 코딩.

Answer 2

나는 맹목적인 복사/붙여 넣기 대 스마트 재사용은 일반적으로 나쁜 습관이라고 말하고 싶지만 assemblyInfo의 값을 업데이트하면 안전 할 수 있습니다.

개인적으로 나는 항상 그 파일을 복사하면 모든 프로젝트에 다른 GUID를 할당하지만 어쨌든 AssemblyGuid 속성은 COM 상호 운용성에만 사용되므로 순수한 .NET 클래스 라이브러리 또는 응용 프로그램을 만들고 ComVisible을 false로 설정하면 COM을 통해 아무 것도 노출시키지 않으므로 걱정하지 않아도되고 다른 것에 어떤 영향도 미치지 않아야합니다.

Answer 3

.Net.하지만 대부분의 언어로 재사용 가능한 코드를 라이브러리에 패키지화 할 수 있습니다. 하나의 프로젝트에서 소스를 라이브러리에 보관 한 다음 각 주요 어플리케이션에서 라이브러리의 2 진 파일에 링크하십시오.

복사하여 붙여 넣기 코드를 다시 사용하면 유지 관리가 악몽이되는 것을 빨리 알 수 있습니다. 재사용 가능한 코드를 한 곳에서 관리하면 버그를 수정할 때 버그를 사용하는 모든 프로그램에서 버그가 수정 될 수 있습니다.

Answer 4

자주 복사/붙여 넣기하는 경우 공용 코드를 라이브러리로 추출하고 다른 프로젝트에서 참조하는 것이 좋습니다. 버그 수정을 할 때 유지 관리가 줄어들어 이점이 있습니다.