Как вы делитесь кодом между проектами / решениями в Visual Studio?
У меня есть два решения, которые имеют некоторый общий код, поэтому я хотел бы извлечь его и поделиться им между ними. Кроме того, я хотел бы иметь возможность выпускать эту библиотеку независимо, потому что это может быть полезно для других.
- Какой лучший способ сделать это с Visual Studio 2008?
- Присутствует ли проект в более чем одном решении?
- У меня есть отдельное решение для отдельного куска кода?
- Может ли решение зависеть от другого?
17 ответов
На проект могут ссылаться несколько решений.
Поместите вашу библиотеку или основной код в один проект, а затем сделайте ссылку на этот проект в обоих решениях.
Вы можете "связать" файл кода между двумя проектами. Щелкните правой кнопкой мыши свой проект, выберите Add -> Existing item, а затем нажмите стрелку вниз рядом с Add кнопка:
По моему опыту, связывание проще, чем создание библиотеки. Связанный код приводит к одному исполняемому файлу с одной версией.
File > Add > Existing Project... позволит вам добавить проекты к вашему текущему решению. Просто добавьте это, так как ни один из вышеупомянутых постов не указывает на это. Это позволяет включать один и тот же проект в несколько решений.
Вы можете включить проект в более чем одно решение. Я не думаю, что у проекта есть концепция, частью решения которой он является. Однако другой альтернативой является сборка первого решения в известном месте и ссылка на скомпилированные двоичные файлы. Это имеет тот недостаток, что вам нужно будет немного поработать, если вы хотите ссылаться на разные версии в зависимости от того, используете ли вы конфигурацию выпуска или отладки.
Я не верю, что вы можете сделать одно решение фактически зависимым от другого, но вы можете выполнять автоматические сборки в соответствующем порядке с помощью пользовательских сценариев. По сути, обращайтесь с вашей общей библиотекой так, как будто это другая сторонняя зависимость, такая как NUnit и т. Д.
Вы можете использовать подстановочные знаки, используя следующую технику (таким образом, решение @Andomar сохраняется в.csproj)
<Compile Include="..\MySisterProject\**\*.cs">
<Link>_Inlined\MySisterProject\%(RecursiveDir)%(Filename)%(Extension)</Link>
</Compile>
Путин:
<Visible>false</Visible>
Если вы хотите скрыть файлы и / или запретить расширение подстановочного знака, добавьте или удалите элемент из папки "виртуальный существующий элемент", например MySisterProject выше.
Вы просто создадите отдельный проект библиотеки классов, который будет содержать общий код. Это не должно быть частью любого решения, которое использует это. Ссылка на библиотеку классов из любого проекта, который нуждается в этом.
Единственная хитрость в том, что вам нужно будет использовать ссылку на файл для ссылки на проект, поскольку он не будет частью решений, которые к нему относятся. Это означает, что фактическая выходная сборка должна быть размещена в месте, к которому может обратиться любой, кто создает проект, ссылающийся на нее. Это можно сделать, поместив сборку, например, в общий ресурс.
Извлеките общий код в проект библиотеки классов и добавьте этот проект библиотеки классов в свои решения. Затем вы можете добавить ссылку на общий код из других проектов, добавив ссылку на проект в эту библиотеку классов. Преимущество наличия ссылки на проект по сравнению с ссылкой на двоичный файл / сборку состоит в том, что если вы измените конфигурацию сборки на отладочную, выпускную, пользовательскую и т. Д., Проект библиотеки общих классов также будет построен на основе этой конфигурации.
Вы можете включить один и тот же проект в несколько решений, но вы гарантированно столкнетесь с проблемами в будущем (относительные пути могут стать недействительными, например, при перемещении каталогов)
После многих лет борьбы с этим, я наконец-то придумал работоспособное решение, но оно требует от вас использовать Subversion для управления исходным кодом (что не так уж плохо)
На уровне каталога вашего решения добавьте свойство svn:externals, указывающее на проекты, которые вы хотите включить в свое решение. Subversion извлечет проект из хранилища и сохранит его в подпапке файла вашего решения. Ваш файл решения может просто использовать относительные пути для ссылки на ваш проект.
Если я найду больше времени, я объясню это подробно.
Теперь вы можете использовать общий проект
Общий проект - отличный способ совместного использования общего кода между несколькими приложениями. Мы уже сталкивались с типом общего проекта в Visual Studio 2013 как часть разработки универсального приложения для Windows 8.1, но в Visual Studio 2015 это автономный новый шаблон проекта; и мы можем использовать его с другими типами приложений, такими как Console, Desktop, Phone, Store Store и т. д. Этот тип проекта чрезвычайно полезен, когда мы хотим совместно использовать общий код, логику, а также компоненты для нескольких приложений на одной платформе., Это также позволяет получить доступ к API, активам и т. Д. Для конкретной платформы.
для получения дополнительной информации проверьте это
Если вы пытаетесь обмениваться кодом между двумя различными типами проектов (например, настольный проект и мобильный проект), вы можете заглянуть в папку общих решений. Я должен сделать это для моего текущего проекта, так как для мобильных и настольных проектов требуются идентичные классы, которые находятся только в одном файле. Если вы пойдете по этому пути, любой из проектов, имеющих связанный файл, может внести в него изменения, и все проекты будут перестроены с учетом этих изменений.
Два основных этапа включают
1- Создание DLL C++
В визуальной студии
New->Project->Class Library in c++ template. Name of project here is first_dll in
visual studio 2010. Now declare your function as public in first_dll.h file and
write the code in first_dll.cpp file as shown below.
Код заголовочного файла
// first_dll.h
using namespace System;
namespace first_dll
{
public ref class Class1
{
public:
static double sum(int ,int );
// TODO: Add your methods for this class here.
};
}
Cpp файл
//first_dll.cpp
#include "stdafx.h"
#include "first_dll.h"
namespace first_dll
{
double Class1:: sum(int x,int y)
{
return x+y;
}
}
Проверь это
**Project-> Properties -> Configuration/General -> Configuration Type**
эта опция должна быть Dynamic Library(.dll) и построить решение / проект сейчас.
Файлfirst_dll.dll создается в папке Debug
2- Связывание в проекте C#
Открытый проект C#
Rightclick on project name in solution explorer -> Add -> References -> Browse to path
where first_dll.dll is created and add the file.
Добавьте эту строку вверху в проекте C#
Using first_dll;
Теперь к функции из dll можно получить доступ с помощью оператора ниже в некоторой функции
double var = Class1.sum(4,5);
Я создал dll в проекте C++ в VS2010 и использовал его в проекте VS2013 C#. Это работает хорошо.
Хорошая идея - создать библиотеку классов dll, которая будет содержать все обычные функции. Каждое решение может ссылаться на эту DLL независимо от других решений.
Фактически, так устроены наши источники в моей работе (и я верю во многих других местах).
Кстати, Solution не может явно зависеть от другого решения.
Вы можете разместить внутренний сервер NuGet и совместно использовать общие библиотеки, которые будут совместно использоваться в других проектах внутри и снаружи.
Далее об этом читайте
Существует очень хороший пример использования "добавления существующих ссылок на файлы" при повторном использовании кода в проектах, и именно тогда вам нужно ссылаться и поддерживать разные версии зависимых библиотек.
Создание нескольких сборок со ссылками на разные внешние сборки не так просто сделать без дублирования кода или использования трюков с контролем исходного кода.
Я считаю, что проще всего поддерживать один проект для разработки и модульного тестирования, а затем создавать "сборочные" проекты, используя существующие ссылки на файлы, когда вам нужно создать сборки, которые ссылаются на разные версии этих внешних сборок.
Начиная с VisualStudio 2015, если вы храните весь свой код в одном решении, вы можете поделиться кодом, добавив общий проект. Затем добавьте ссылку на этот общий проект для каждого проекта, в котором вы хотите использовать код, а также соответствующие директивы using.
Включать проект в несколько решений — очень плохая идея.
Допустим, у вас есть проект библиотеки классов, включенный как в , так и в .
Что произойдет, если вы работаете и вносите критические изменения в ? Затем вы получите ошибку сборки вSolutionAчто наверное легко исправить. НО вы не заметите, что вы на самом деле тоже что-то сломали. Ваш сервер сборки может сказать вам, но уже слишком поздно. Вы хотите знать, прежде чем нажимать свой код.
Есть только два хороших решения:
- Создайте пакет nuget, которым вы действительно сможете поделиться, и используйте semver, чтобы контролировать влияние критических изменений. Это может создать нежелательные накладные расходы.
- Создайте единое решение, содержащее все зависимые проекты из
SolutonAиSolutionB. Если у вас много несвязанных проектов, зависящих отSharedто это может быть не лучшим решением, и тогда вам следует использовать подход nuget.
Один более простой способ включить файл класса одного проекта в другие проекты - это добавить проект в существующее решение, а затем добавить ссылку на DLL нового проекта в существующий проект. Наконец, вы можете использовать методы добавленного класса, используя декальринг с помощью директивы в верхней части любого класса.