Jak współdzielić kod między projektami / rozwiązaniami w Visual Studio?

Mam dwa rozwiązania, które mają wspólny kod, więc chciałbym go wyodrębnić i udostępnić między nimi. Ponadto chciałbym móc samodzielnie wydać tę bibliotekę, ponieważ może być przydatna dla innych.

• Jak najlepiej to zrobić w Visual Studio 2008?
• Czy projekt występuje w więcej niż jednym rozwiązaniu?
• Czy mam osobne rozwiązanie dla oddzielnego fragmentu kodu?
• Czy rozwiązanie może zależeć od innego?

Do projektu może odnosić się wiele rozwiązań.

Umieść bibliotekę lub kod podstawowy w jednym projekcie, a następnie odwołaj się do tego projektu w obu rozwiązaniach.

Możesz „połączyć” plik kodu między dwoma projektami. Kliknij projekt prawym przyciskiem myszy, wybierz Add-> Existing item, a następnie kliknij strzałkę w dół obok Addprzycisku:

Z mojego doświadczenia wynika, że ​​łączenie jest prostsze niż tworzenie biblioteki. Połączony kod daje pojedynczy plik wykonywalny z jedną wersją.

File > Add > Existing Project...pozwoli Ci dodawać projekty do obecnego rozwiązania. Właśnie to dodałem, ponieważ żaden z powyższych postów tego nie wskazuje. Umożliwia to dołączenie tego samego projektu do wielu rozwiązań.

Państwo może zawierać projekt w więcej niż jedno rozwiązanie. Nie sądzę, że projekt ma pojęcie, którego rozwiązania jest częścią. Inną alternatywą jest jednak zbudowanie pierwszego rozwiązania w znanym miejscu i odniesienie do skompilowanych plików binarnych. Ma to tę wadę, że trzeba będzie trochę popracować, jeśli chcesz odwoływać się do różnych wersji w zależności od tego, czy budujesz konfigurację wydania, czy debugowania.

Nie sądzę, aby można było uzależnić jedno rozwiązanie od drugiego, ale można wykonać automatyczne kompilacje w odpowiedniej kolejności za pomocą niestandardowych skryptów. Zasadniczo traktuj swoją wspólną bibliotekę tak, jakby była inną zależnością strony trzeciej, taką jak NUnit itp.

Możesz wstawić symbole wieloznaczne za pomocą następującej techniki (w taki sposób zapisywane jest rozwiązanie @ Andomar w .csproj)

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

Wtrącić:

    <Visible>false</Visible>

Jeśli chcesz ukryć pliki i / lub uniemożliwić rozwinięcie symbolu wieloznacznego, jeśli dodasz lub usuniesz element z folderu „wirtualnego istniejącego elementu”, jak MySisterProjectwyżej.

Po prostu utworzyłbyś oddzielny projekt biblioteki klas, aby zawierał wspólny kod. Nie musi być częścią żadnego rozwiązania, które z niego korzysta. Odwołaj się do biblioteki klas z dowolnego projektu, który jej potrzebuje.

Jedyną sztuczką jest to, że będziesz musiał użyć odwołania do pliku, aby odwołać się do projektu, ponieważ nie będzie to część rozwiązań, które go dotyczą. Oznacza to, że rzeczywisty zestaw wyjściowy będzie musiał zostać umieszczony w miejscu, do którego może uzyskać dostęp każdy, kto buduje projekt, który się do niego odwołuje. Można to zrobić na przykład poprzez umieszczenie zestawu na udziale.

Możesz uwzględnić ten sam projekt w więcej niż jednym rozwiązaniu, ale na pewno napotkasz problemy w przyszłości (ścieżki względne mogą stać się nieprawidłowe, na przykład podczas przenoszenia katalogów)

Po latach zmagania się z tym w końcu wymyśliłem praktyczne rozwiązanie, ale wymaga ono użycia Subversion do kontroli źródła (co nie jest złe)

Na poziomie katalogu swojego rozwiązania dodaj właściwość svn: externals wskazującą projekty, które chcesz uwzględnić w swoim rozwiązaniu. Subversion wyciągnie projekt z repozytorium i zapisze go w podfolderze pliku rozwiązania. Plik rozwiązania może po prostu używać ścieżek względnych do odniesienia do twojego projektu.

Jeśli znajdę trochę więcej czasu, wyjaśnię to szczegółowo.

Wyodrębnij wspólny kod do projektu biblioteki klas i dodaj ten projekt biblioteki klas do swoich rozwiązań. Następnie możesz dodać odwołanie do wspólnego kodu z innych projektów, dodając odwołanie do projektu do tej biblioteki klas. Zaletą posiadania odwołania do projektu w przeciwieństwie do odwołania do pliku binarnego / zestawu jest to, że jeśli zmienisz konfigurację kompilacji na debugowanie, wydanie, niestandardowe itp., Projekt biblioteki klas wspólnych zostanie również zbudowany na podstawie tej konfiguracji.

Dobrym pomysłem jest utworzenie biblioteki klas dll, która zawiera wszystkie typowe funkcje. Każde rozwiązanie może odwoływać się do tej biblioteki dll niezależnie, niezależnie od innych rozwiązań.

Rzeczywiście, w ten sposób zorganizowane są nasze źródła w mojej pracy (i wierzę w wiele innych miejsc).

Nawiasem mówiąc, rozwiązanie nie może jawnie zależeć od innego rozwiązania.

Są to dwa główne etapy

1- Tworzenie biblioteki dll C ++

W studio wizualnym

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.

Kod pliku nagłówka

// 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.
};
}

Plik CPP

//first_dll.cpp
#include "stdafx.h"

#include "first_dll.h"

namespace first_dll
{

    double Class1:: sum(int x,int y)
    {
        return x+y;
    }

 }

Sprawdź to

**Project-> Properties -> Configuration/General -> Configuration Type** 

tą opcją powinna być biblioteka dynamiczna (.dll) i teraz buduj rozwiązanie / projekt.

Plik first_dll.dll jest tworzony w folderze debugowania

2- Łączenie go w projekcie C #

Otwórz projekt C #

Rightclick on project name in solution explorer -> Add -> References -> Browse to path 
where first_dll.dll is created and add the file.

Dodaj tę linię u góry w projekcie C #

Using first_dll; 

Teraz do funkcji z biblioteki dll można uzyskać dostęp za pomocą poniższej instrukcji w niektórych funkcjach

double var = Class1.sum(4,5);

Stworzyłem dll w projekcie c ++ w VS2010 i użyłem go w projekcie VS2013 C #. To działa dobrze.

Możesz hostować wewnętrzny serwer NuGet i udostępniać wspólne biblioteki, które będą udostępniane wewnętrznie i zewnętrznie w innych projektach.

Dalej na tej przeczytane

Jeśli próbujesz współdzielić kod między dwoma różnymi typami projektów (tj. Projekt na komputery stacjonarne i projekt mobilny), możesz zajrzeć do folderu rozwiązań udostępnionych . Muszę to zrobić dla mojego obecnego projektu, ponieważ zarówno projekty mobilne, jak i stacjonarne wymagają identycznych klas, które znajdują się tylko w 1 pliku. Jeśli pójdziesz tą drogą, każdy projekt, do którego podłączony jest plik, może wprowadzić w nim zmiany, a wszystkie projekty zostaną odbudowane na podstawie tych zmian.

Jest bardzo dobry przypadek użycia „dodawania istniejących łączy plików” podczas ponownego wykorzystywania kodu w projektach, i wtedy trzeba odwoływać się i obsługiwać różne wersje bibliotek zależnych.

Tworzenie wielu zestawów z odniesieniami do różnych zestawów zewnętrznych nie jest łatwe do zrobienia inaczej bez powielania kodu lub stosowania sztuczek z kontrolą kodu źródłowego.

Uważam, że najłatwiej jest utrzymać jeden projekt na potrzeby programowania i testów jednostkowych, a następnie utworzyć projekty „kompilacji” przy użyciu istniejących łączy plików, gdy trzeba utworzyć zestawy, które odwołują się do różnych wersji tych zewnętrznych zestawów.

Jednym prostszym sposobem włączenia pliku klasy jednego projektu do innych projektów jest dodanie projektu do istniejącego rozwiązania, a następnie dodanie odwołania DLL nowego projektu do istniejącego projektu. Na koniec możesz użyć metod dodanej klasy, odszyfrowując przy użyciu dyrektywy na górze dowolnej klasy.

Począwszy od VisualStudio 2015, jeśli trzymasz cały swój kod w jednym rozwiązaniu, możesz udostępniać kod, dodając współdzielony projekt . Następnie dodaj odniesienie do tego współużytkowanego projektu dla każdego projektu, w którym chcesz użyć kodu, a także odpowiednie dyrektywy przy użyciu.

Teraz możesz użyć projektu współdzielonego

Shared Project to świetny sposób na dzielenie wspólnego kodu w wielu aplikacjach. Doświadczyliśmy już typu Shared Project w Visual Studio 2013 w ramach Windows 8.1 Universal App Development, ale w Visual Studio 2015 jest to samodzielny nowy szablon projektu; i możemy go używać z innymi rodzajami aplikacji, takimi jak konsola, komputer stacjonarny, telefon, aplikacja sklepowa itp. Tego typu projekty są niezwykle pomocne, gdy chcemy udostępnić wspólny kod, logikę oraz komponenty dla wielu aplikacji na jednej platformie . Umożliwia to również dostęp do specyficznych dla platformy interfejsów API, zasobów itp.

Aby uzyskać więcej informacji, sprawdź to