Как вы делитесь кодом между проектами / решениями в Visual Studio?

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

• Какой лучший способ сделать это с Visual Studio 2008?
• Присутствует ли проект в более чем одном решении?
• У меня есть отдельное решение для отдельного куска кода?
• Может ли решение зависеть от другого?

На проект могут ссылаться несколько решений.

Поместите вашу библиотеку или основной код в один проект, а затем сделайте ссылку на этот проект в обоих решениях.

Вы можете «связать» файл кода между двумя проектами. Щелкните правой кнопкой мыши свой проект, выберите 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 извлечет проект из хранилища и сохранит его в подпапке файла вашего решения. Ваш файл решения может просто использовать относительные пути для ссылки на ваш проект.

Если я найду больше времени, я объясню это подробно.

Извлеките общий код в проект библиотеки классов и добавьте этот проект библиотеки классов в свои решения. Затем вы можете добавить ссылку на общий код из других проектов, добавив ссылку на проект в эту библиотеку классов. Преимущество наличия ссылки на проект по сравнению с ссылкой на двоичный файл / сборку состоит в том, что если вы измените конфигурацию сборки на отладочную, выпускную, пользовательскую и т. Д., Проект библиотеки общих классов также будет построен на основе этой конфигурации.

Хорошая идея - создать библиотеку классов DLL, которая будет содержать все общие функции. Каждое решение может ссылаться на эту DLL независимо от других решений.

Фактически, так устроены наши источники в моей работе (и я верю во многих других местах).

Кстати, Solution не может явно зависеть от другого решения.

Два основных этапа включают

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 #. Это работает хорошо.

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

Далее это читайте

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

Существует очень хороший случай использования «добавления существующих ссылок на файлы» при повторном использовании кода в проектах, и именно тогда вам нужно ссылаться и поддерживать разные версии зависимых библиотек.

Создание нескольких сборок со ссылками на разные внешние сборки не так просто сделать без дублирования кода или использования трюков с контролем исходного кода.

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

Один более простой способ включить файл класса одного проекта в другие проекты - это добавить проект в существующее решение, а затем добавить ссылку на DLL нового проекта в существующий проект. Наконец, вы можете использовать методы добавленного класса, используя декальринг с помощью директивы в верхней части любого класса.

Начиная с VisualStudio 2015, если вы храните весь свой код в одном решении, вы можете поделиться кодом, добавив общий проект . Затем добавьте ссылку на этот общий проект для каждого проекта, в котором вы хотите использовать код, а также соответствующие директивы using.

Теперь вы можете использовать общий проект

Общий проект - отличный способ совместного использования общего кода между несколькими приложениями. Мы уже сталкивались с типом общего проекта в Visual Studio 2013 как часть разработки универсального приложения для Windows 8.1, но в Visual Studio 2015 это автономный новый шаблон проекта; и мы можем использовать его с другими типами приложений, такими как Console, Desktop, Phone, Store Store и т. д. Этот тип проекта чрезвычайно полезен, когда мы хотим совместно использовать общий код, логику, а также компоненты для нескольких приложений на одной платформе. , Это также позволяет получить доступ к API, активам и т. Д. Для конкретной платформы.

для получения дополнительной информации проверьте это