Ik heb twee oplossingen die een gemeenschappelijke code hebben, dus ik wil deze eruit halen en met hen delen. Verder zou ik die bibliotheek graag zelfstandig willen kunnen vrijgeven omdat het nuttig kan zijn voor anderen.
- Wat is de beste manier om dit te doen met Visual Studio 2008?
- Is een project aanwezig in meer dan één oplossing?
- Heb ik een aparte oplossing voor het aparte stukje code?
- Kan een oplossing afhankelijk zijn van een andere?
Antwoord 1, autoriteit 100%
Je kunt een codebestand “linken” tussen twee projecten. Klik met de rechtermuisknop op uw project, kies Add-> Existing itemen klik vervolgens op de pijl-omlaag naast de knop Add:
In mijn ervaring is het koppelen eenvoudiger dan het maken van een bibliotheek. Gelinkte code resulteert in een enkel uitvoerbaar bestand met een enkele versie.
Antwoord 2, autoriteit 29%
Er kan naar een project worden verwezen door meerdere oplossingen.
Plaats uw bibliotheek- of kerncode in één project en verwijs vervolgens naar dat project in beide oplossingen.
Antwoord 3, autoriteit 14%
File > Add > Existing Project...laat je projecten toevoegen aan je huidige oplossing. Ik voeg dit gewoon toe, omdat geen van de bovenstaande berichten dat aangeeft. Hierdoor kunt u hetzelfde project in meerdere oplossingen opnemen.
Antwoord 4, autoriteit 9%
U kunteen project in meer dan één oplossing opnemen. Ik denk niet dat een project een idee heeft van welke oplossing het deel uitmaakt. Een ander alternatief is echter om de eerste oplossing naar een bekende plaats te laten bouwen en naar de gecompileerde binaire bestanden te verwijzen. Dit heeft het nadeel dat je wat werk moet verzetten als je naar verschillende versies wilt verwijzen, afhankelijk van of je release- of debug-configuraties inbouwt.
Ik geloof niet dat je de ene oplossing echt van de andere kunt laten afhangen, maar je kunt je geautomatiseerde builds in de juiste volgorde uitvoeren via aangepaste scripts. Behandel uw gemeenschappelijke bibliotheek in principe alsof het een andere afhankelijkheid van een derde partij is, zoals NUnit enz.
Antwoord 5, autoriteit 9%
Je kunt inline wildcards gebruiken met de volgende techniek (dit is de manier waarop de oplossing van @Andomar wordt opgeslagen in de .csproj)
<Compile Include="..\MySisterProject\**\*.cs">
<Link>_Inlined\MySisterProject\%(RecursiveDir)%(Filename)%(Extension)</Link>
</Compile>
Invoeren:
<Visible>false</Visible>
Als je de bestanden wilt verbergen en/of wilt voorkomen dat de joker-opname wordt uitgevouwen als je een item toevoegt aan of verwijdert uit een ‘virtueel bestaand item’-map zoals MySisterProjecthierboven.
Antwoord 6, autoriteit 7%
Je zou gewoon een apart Class Library-project maken om de gemeenschappelijke code te bevatten. Het hoeft geen deel uit te maken van een oplossing die het gebruikt. Verwijs naar de klassenbibliotheek van elk project dat het nodig heeft.
De enige truc is dat je een bestandsverwijzing moet gebruiken om naar het project te verwijzen, aangezien het geen deel uitmaakt van de oplossingen die ernaar verwijzen. Dit betekent dat de eigenlijke uitvoereenheid op een locatie moet worden geplaatst die toegankelijk is voor iedereen die een project bouwt dat ernaar verwijst. Dit kan bijvoorbeeld door de assembly op een share te plaatsen.
Antwoord 7, autoriteit 4%
Pak de algemene code uit in een klassenbibliotheekproject en voeg dat klassenbibliotheekproject toe aan uw oplossingen. Vervolgens kunt u een verwijzing naar de gemeenschappelijke code van andere projecten toevoegen door een projectverwijzing aan die klassenbibliotheek toe te voegen. Het voordeel van het hebben van een projectreferentie in tegenstelling tot een binaire/assemblagereferentie is dat als u uw buildconfiguratie wijzigt in debug, release, custom, enz., het gemeenschappelijke klassenbibliotheekproject ook op die configuratie wordt gebouwd.
Antwoord 8, autoriteit 3%
U zou hetzelfde project in meer dan één oplossing kunnen opnemen, maar u zult gegarandeerd problemen tegenkomen op de weg (relatieve paden kunnen ongeldig worden wanneer u bijvoorbeeld mappen verplaatst)
Na jaren van worstelen met dit, kwam ik eindelijk met een werkbare oplossing, maar je moet Subversion gebruiken voor broncontrole (wat geen slechte zaak is)
Voeg op directoryniveau van uw oplossing een eigenschap svn:externalstoe die verwijst naar de projecten die u in uw oplossing wilt opnemen. Subversion haalt het project uit de repository en slaat het op in een submap van uw oplossingsbestand. Uw oplossingsbestand kan eenvoudig relatieve paden gebruiken om naar uw project te verwijzen.
Als ik wat meer tijd heb, zal ik dit in detail uitleggen.
Antwoord 9, autoriteit 2%
Het is een goed idee om een dll-klassebibliotheek te maken die alle gebruikelijke functionaliteit bevat. Elke oplossing kan onafhankelijk naar deze dll verwijzen, ongeacht andere oplossingen.
In feite is dit hoe onze bronnen in mijn werk zijn georganiseerd (en ik geloof op veel andere plaatsen).
Trouwens, Oplossing kan niet expliciet afhankelijk zijn van een andere oplossing.
Antwoord 10, autoriteit 2%
Als je code probeert te delen tussen twee verschillende projecttypes (dat wil zeggen: desktopproject en een mobiel project), kun je kijken naar de gedeelde map met oplossingen. Ik moet dat doen voor mijn huidige project, omdat de mobiele en desktopprojecten beide identieke klassen vereisen die zich slechts in 1 bestand bevinden. Als je deze route volgt, kan elk van de projecten waaraan het bestand is gekoppeld er wijzigingen in aanbrengen en alle projecten zullen opnieuw worden opgebouwd tegen die wijzigingen.
Antwoord 11, autoriteit 2%
Twee belangrijke stappen zijn
1- Een C++ dll maken
In visuele 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.
Koptekst Bestandscode
// 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-bestand
//first_dll.cpp
#include "stdafx.h"
#include "first_dll.h"
namespace first_dll
{
double Class1:: sum(int x,int y)
{
return x+y;
}
}
Vink dit aan
**Project-> Properties -> Configuration/General -> Configuration Type**
deze optie moet Dynamic Library(.dll)zijn en de oplossing/het project nu bouwen.
first_dll.dll-bestand wordt gemaakt in Debug-map
2- Koppelen in C#-project
C#-project openen
Rightclick on project name in solution explorer -> Add -> References -> Browse to path
where first_dll.dll is created and add the file.
Voeg deze regel bovenaan toe in C#-project
Using first_dll;
Nu kan de functie van dll worden geopend met behulp van onderstaande instructie in een bepaalde functie
double var = Class1.sum(4,5);
Ik heb dll gemaakt in het c++-project in VS2010 en gebruikt in het VS2013 C#-project. Het werkt goed.
Antwoord 12, autoriteit 2%
Je kunt een interne NuGet-serverhosten en de gemeenschappelijke bibliotheken die intern en extern in andere projecten worden gedeeld.
Verder op deze lees
Antwoord 13, autoriteit 2%
Er is een zeer goede reden om “bestaande bestandskoppelingen toe te voegen” bij het hergebruik van code in projecten, en dat is wanneer u naar verschillende versies van afhankelijke bibliotheken moet verwijzen en deze moet ondersteunen.
Het maken van meerdere assembly’s met verwijzingen naar verschillende externe assembly’s is niet eenvoudig om anders te doen zonder uw code te dupliceren of trucs te gebruiken met broncodecontrole.
Ik geloof dat het het gemakkelijkst is om één project te onderhouden voor ontwikkeling en unit-test, en vervolgens om ‘build’-projecten te maken met behulp van bestaande bestandskoppelingen wanneer je de assemblages moet maken die verwijzen naar verschillende versies van die externe assemblages.
Antwoord 14
Vanaf VisualStudio 2015, als u al uw code in één oplossing bewaart, kunt u code delen door een gedeeld project toevoegen.
Voeg vervolgens een verwijzing naar dit gedeelde project toe voor elk project waarin u de code wilt gebruiken, evenals de juiste gebruiksaanwijzingen.
Antwoord 15
Je kunt nu het Gedeelde project
. gebruiken
Gedeeld project is een geweldige manier om gemeenschappelijke code over meerdere te delen
toepassing We hebben al ervaring met het type Shared Project
in Visual Studio 2013 als onderdeel van Windows 8.1 Universal App
Ontwikkeling, maar met Visual Studio 2015 is het een standalone nieuw
Projectsjabloon; en we kunnen het gebruiken met andere soorten apps zoals
Console, Desktop, Telefoon, Store-app enz. Dit type project is:
uiterst handig als we een gemeenschappelijke code willen delen, ook logica
als componenten in meerdere applicaties met in één platform.
Dit geeft ook toegang tot de platform-specifieke API’s, activa enz.
controleer voor meer informatie dit
Antwoord 16
Een eenvoudigere manier om een klassenbestand van het ene project in een ander project op te nemen, is door het project toe te voegen aan een bestaande oplossing en vervolgens de DLL-referentie van het nieuwe project toe te voegen aan het bestaande project. Ten slotte kunt u de methoden van de toegevoegde klasse gebruiken door te decaleren met behulp van de instructie bovenaan de willekeurige klasse.