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



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




  • каков наилучший способ сделать это с Visual Studio 2008?

  • присутствует ли проект в более чем одном решении?

  • есть ли у меня отдельное решение для отдельного фрагмента кода?

  • решение может зависеть от еще один?

1465   16  

16 ответов:

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

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

вы можете "связать" файл кода между двумя проектами. Щелкните правой кнопкой мыши проект, выберите Add ->Existing item, а затем щелкните стрелку вниз рядом с :

Screengrab

по моему опыту связывание проще, чем создание библиотеки. Связанный код приводит к одному исполняемому файлу с одной версией.

File > Add > Existing Project... позволит вам добавлять проекты в текущем решении. Просто добавляя это, так как ни один из приведенных выше сообщений не указывает на это. Это позволяет включить один и тот же проект в несколько решений.

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

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

вы можете встроить wild-card, используя следующий метод (который является способом, которым решение @Andomar сохраняется в .csproj)

<Compile Include="..\MySisterProject\**\*.cs">
  <Link>_Inlined\MySisterProject\%(RecursiveDir)%(Filename)%(Extension)</Link>
</Compile>

положить в:

    <Visible>false</Visible>

Если вы хотите скрыть файлы и / или предотвратить расширение wild-card include, если вы добавляете или удаляете элемент из папки "виртуальный существующий элемент", например MySisterProject выше.

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

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

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

вы можете включить один и тот же проект в более чем одно решение, но вы гарантированно столкнетесь с проблемами в будущем (относительные пути могут стать недействительными, например, при перемещении каталогов)

после многих лет борьбы с этим, я, наконец, придумал работоспособное решение, но оно требует, чтобы вы использовали Subversion для управления версиями (что не так уж плохо)

на уровне каталога Вашего решения добавьте svn: externals свойство, указывающее на проекты, которые вы хотите включить в свое решение. Subversion вытащит проект из репозитория и сохранит его в подпапке вашего файла решения. Ваш файл решения может просто использовать относительные пути для ссылки на ваш проект.

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

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

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

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

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

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

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

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

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

два основных шага участвуют

1-создание библиотеки dll C++

в visual studio

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 File

//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** 

этот параметр должен быть Динамическая Библиотека(.dll) и построить решение/проект.

first_dll.dll файл создается в отладка папка

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

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

далее читать

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

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

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

enter image description here

более подробная информация этой

Comments

    Ничего не найдено.