Влияние идентичного идентификатора GUID для всех приложений

Question

Всякий раз, когда у меня есть новый проект C#, я часто копирую/переименовываю существующий, чтобы повторно использовать большую часть кода. Это означает, что вы собираетесь в Assembly Info и переименовываете проект там. Раньше я действительно не беспокоился о переименовании GUID.

Является ли эта плохая практика программирования и может ли она отрицательно повлиять на пользователя, если у них есть другая программа, открытая с тем же GUID?

Я ни в коем случае не специалист-программист, но я прохожу мимо, и я понимаю, как я иду. Любой совет приветствуется.

Answer 1

Это зависит от того, для чего используются идентификаторы GUID. Некоторые повторные применения GUIDs, что я знаю, что может вызывать тяжелые (и все же тонкие) осложнения:

1. GUIDs подвергаются COM в любом случае. Если два COM-компонента с одинаковыми идентификаторами GUID будут зарегистрированы, будут возникать очень запутывающие и почти невозможные конфликты.
2. GUID, которые являются идентификаторами продуктов в проектах настройки. Не очень весело сталкиваться с ситуацией, когда отличается от продуктом, который удаляется и/или иным образом предотвращает установку.
3. Большинство идентификаторов GUID в SharePoint. (Типы столбцов, задания по таймеру и т. Д.)

В конце концов, я хотел бы найти другие способы «повторного использования», если это возможно.

Счастливое кодирование.

Answer 2

Я бы сказал, что слепая копия/вставка против умного повторного использования - это, как правило, плохая практика, но если вы обновите значения в сборке, вы можете быть в безопасности.

Лично я всегда назначаю другое руководство для каждого проекта, если я копирую этот файл, но в любом случае атрибут AssemblyGuid используется только для совместимости COM, поэтому, если вы делаете чистые библиотеки или приложения .NET-класса, и у вас есть ComVisible, установите значение false потому что вы ничего не открываете через COM, вам не стоит беспокоиться и не будет никакого влияния ни на что другое.

Answer 3

Я не знаю .Net, но на большинстве языков вы можете упаковать многоразовый код в библиотеку. Храните источник в своей библиотеке только в одном проекте, затем связывайтесь с бинарной библиотекой из каждого из основных приложений.

Если вы сохраняете повторное использование кода copy-n-paste, вы быстро обнаружите, что обслуживание становится кошмаром. Гораздо лучше, чтобы код многократного использования хранился в одном месте, чтобы при исправлении ошибки он исправлялся для всех программ, которые его используют.

Answer 4

Если вы так часто копируете/вставляете, рассмотрите возможность извлечения общего кода в библиотеку и ссылки на него из других проектов. У этого есть преимущества из-за сокращения обслуживания, когда вы делаете изменения в исправлении ошибки.