Внутреннее повторное использование кода метода

Question

Допустим, у вас есть 2 совершенно разных проекта: Проект 1 и Проект 2. Один - приложение для Windows, а другой - веб-приложение.

Если оба проекта нуждаются в классах A, B и C для их собственного внутреннего использования, каков наилучший способ продвижения повторного использования кода в классах между двумя проектами (особенно, когда код обновляется более время)

• Заставить классы быть публичными, нарушить аккуратный публичный интерфейс и сделать ссылку из одного проекта в другой (чёрт!)
• Создайте третий проект для общих компонентов, а затем используйте их только для основных проектов (чёрт!)
• «Добавить» классы из проекта 1 в проект 2 (выход за пределы папки проекта) и признать, что у проекта 2 не будет всех классов, которые ему нужно построить в папке проекта (приемлемо, но не идеально)
• Зависит от копирования и вставки, перекрестных ссылок управления исходным кодом или других не связанных с программированием трюков.
• Какая-то другая техника, которая ускользает от меня на данный момент (пальцы скрещены ...)

Обратите внимание, что это идентичные, ВНУТРЕННИЕ, вспомогательные классы, необходимые для обоих проектов.

Answer 1

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

Answer 2

Обычно это реализуется с помощью проекта библиотеки классов, для которого требуется третий проект (тип библиотеки классов).

Проект библиотеки классов имеет расширение .dll, где он может использоватьсялюбые другие .NET проекты (написанные на любых языках).Чтобы использовать dll, добавьте ссылку на файл и поставьте

using the_namespace_of_dll

Это абсолютное решение

Answer 3

Я обычно использую отдельное решение (в комплекте с тестами) и добавляю ссылку.Затем я использую ILMerge в конце, чтобы не показывать отдельную DLL (пока это работает нормально для меня).Метод, на который указал Джон Раш, может использоваться совместно, чтобы не раскрывать «его», хотя я обычно ошибаюсь из-за того, что доверяю пользователю / другому разработчику (-ям).

Я избегаю copy-'n-паста почти на все расходы.Подход SCM может работать, но на самом деле не заставляет ABI разрабатываться и не поддерживается в разных SCM.SVN без помощи довольно плох в этом, если только одно решение не является "владельцем";тогда внешность может быть честной средне.

Answer 4

Добавьте код в один проект, затем добавьте его в другой как ссылку . Тогда вам не нужно беспокоиться о «InternalsVisibleTo» - он просто есть. Код представляет собой один и тот же файл для обоих проектов (или для любого количества проектов).

или

Не бойтесь редактировать файлы XML .csproj. Например, это работает ...

<Compile Include="$(Codez)\z.Libraries\diff-match-patch\DiffMatchPatch\**\*.cs"
Exclude="NotThisOne.cs;**\NotThisFolderWith\This*.cs">
<Link>Libs\%(RecursiveDir)%(Filename)%(Extension)</Link>
</Compile>

... и выдаст вам все файлы C # из исходной папки и подпапок в виде связанных файлов в целевом проекте в папке с именем \Libs\.

• $(Codez) - это переменная среды Windows, которую я использую на своих компьютерах.
• Я также мог бы использовать *.* в конце вместо *.cs.
• Это одна из тех вещей, которые Visual Studio может нарушить, добавив файл в папку, заполненную файлами подстановочных знаков, которые могут разбить их на отдельные записи. Или нет. Зависит от ветра.

Answer 5

Для тех, кто посещает эту страницу и хочет сделать то же самое, я нашел более подробное объяснение:

http://dotnetstep.blogspot.com/2009/01/internalsvisibleto-attribute-usage.html