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

Question

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

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

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

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

Answer 1

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

Answer 2

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

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

using the_namespace_of_dll

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

Answer 3

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

Я избегаю копирования -n-paste в [почти] всех затратах. Подход SCM может работать, но на самом деле не заставляет ABI разрабатываться и не поддерживается в разных SCM. SVN без помощи - это плохо, если только одно решение не является «владельцем»; то внешние могут быть справедливыми.

Answer 4

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

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

Answer 5

Добавить код в одном проекте, то add it to the other as a link. Тогда вам не нужно беспокоиться о «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 может сломать на вас, добавив файл в папку с файлами, связанными с подстановочными знаками, может разбить их на отдельные записи. Или нет. Зависит от ветра.