¿Cómo comparte código entre proyectos / soluciones en Visual Studio?

Tengo dos soluciones que tienen un código común, por lo que me gustaría extraerlo y compartirlo entre ellos. Además, me gustaría poder liberar esa biblioteca de forma independiente porque podría ser útil para otros.

• ¿Cuál es la mejor manera de hacerlo con Visual Studio 2008?
• ¿Hay un proyecto presente en más de una solución?
• ¿Tengo una solución separada para el fragmento de código separado?
• ¿Puede una solución depender de otra?

Un proyecto puede ser referenciado por múltiples soluciones.

Coloque su biblioteca o código central en un proyecto, luego haga referencia a ese proyecto en ambas soluciones.

Puede "vincular" un archivo de código entre dos proyectos. Haga clic derecho en su proyecto, elija Add-> Existing item, y luego haga clic en la flecha hacia abajo al lado del Addbotón:

En mi experiencia, vincular es más simple que crear una biblioteca. El código vinculado da como resultado un único ejecutable con una única versión.

File > Add > Existing Project...le permitirá agregar proyectos a su solución actual. Solo agrego esto ya que ninguna de las publicaciones anteriores lo señala. Esto le permite incluir el mismo proyecto en múltiples soluciones.

Usted puede incluir un proyecto en más de una solución. No creo que un proyecto tenga un concepto de la solución de la que forma parte. Sin embargo, otra alternativa es crear la primera solución en un lugar conocido y hacer referencia a los binarios compilados. Esto tiene la desventaja de que tendrá que hacer un poco de trabajo si desea hacer referencia a diferentes versiones en función de si está creando configuraciones de lanzamiento o de depuración.

No creo que pueda hacer que una solución realmente dependa de otra, pero puede realizar sus compilaciones automatizadas en un orden apropiado mediante scripts personalizados. Básicamente trate su biblioteca común como si fuera otra dependencia de terceros como NUnit, etc.

Puede usar comodines en línea utilizando la siguiente técnica (que es la forma en que la solución de @ Andomar se guarda en el .csproj)

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

Meter en:

    <Visible>false</Visible>

Si desea ocultar los archivos y / o evitar que el comodín se expanda si agrega o elimina un elemento de una carpeta 'elemento virtual existente' como se indicó MySisterProjectanteriormente.

Simplemente crearía un proyecto de biblioteca de clases separado para contener el código común. No necesita ser parte de ninguna solución que lo use. Consulte la biblioteca de clases de cualquier proyecto que lo necesite.

El único truco es que necesitará usar una referencia de archivo para hacer referencia al proyecto, ya que no será parte de las soluciones que se refieren a él. Esto significa que el conjunto de salida real tendrá que colocarse en una ubicación a la que pueda acceder cualquiera que construya un proyecto que lo haga referencia. Esto se puede hacer colocando el ensamblaje en un recurso compartido, por ejemplo.

Podría incluir el mismo proyecto en más de una solución, pero está garantizado que tendrá problemas en algún momento (las rutas relativas pueden volverse inválidas cuando mueve directorios, por ejemplo)

Después de años de luchar con esto, finalmente se me ocurrió una solución viable, pero requiere que uses Subversion para el control de la fuente (que no es algo malo)

En el nivel de directorio de su solución, agregue una propiedad svn: externals que apunte a los proyectos que desea incluir en su solución. Subversion extraerá el proyecto del repositorio y lo almacenará en una subcarpeta de su archivo de solución. Su archivo de solución simplemente puede usar rutas relativas para referirse a su proyecto.

Si encuentro más tiempo, explicaré esto en detalle.

Extraiga el código común en un proyecto de biblioteca de clases y agregue ese proyecto de biblioteca de clases a sus soluciones. Luego, puede agregar una referencia al código común de otros proyectos agregando una referencia de proyecto a esa biblioteca de clases. La ventaja de tener una referencia de proyecto en lugar de una referencia binaria / de ensamblaje es que si cambia la configuración de compilación para depurar, liberar, personalizar, etc., el proyecto de biblioteca de clase común se construirá también en función de esa configuración.

Es una buena idea crear una biblioteca de clase dll que contenga todas las funciones comunes. Cada solución puede hacer referencia a este dll independientemente, independientemente de otras soluciones.

De hecho, así es como se organizan nuestras fuentes en mi trabajo (y creo en muchos otros lugares).

Por cierto, Solution no puede depender explícitamente de otra solución.

Dos pasos principales involucrados son

1- Creando un dll C ++

En estudio visual

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.

Código de archivo de encabezado

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

Archivo Cpp

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

#include "first_dll.h"

namespace first_dll
{

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

 }

Mira esto

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

esta opción debería ser Dynamic Library (.dll) y construir la solución / proyecto ahora.

El archivo first_dll.dll se crea en la carpeta Debug

2- Vinculación en proyecto C #

Proyecto abierto C #

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

Agregue esta línea en la parte superior del proyecto C #

Using first_dll; 

Ahora se puede acceder a la función de dll usando la siguiente declaración en alguna función

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

Creé dll en el proyecto c ++ en VS2010 y lo usé en el proyecto VS2013 C #. Funciona bien.

Puede alojar un servidor NuGet interno y compartir las bibliotecas comunes que se compartirán en otros proyectos interna y externamente.

Más adelante en esta lectura

Si está intentando compartir código entre dos tipos de proyectos diferentes (es decir, proyecto de escritorio y un proyecto móvil), puede buscar en la carpeta de soluciones compartidas . Tengo que hacer eso para mi proyecto actual, ya que los proyectos móviles y de escritorio requieren clases idénticas que solo están en 1 archivo. Si sigue esta ruta, cualquiera de los proyectos que tienen el archivo vinculado puede realizar cambios y todos los proyectos se reconstruirán con esos cambios.

Hay un muy buen caso para usar "agregar enlaces de archivos existentes" al reutilizar código en proyectos, y es cuando necesita hacer referencia y admitir diferentes versiones de bibliotecas dependientes.

Hacer múltiples conjuntos con referencias a diferentes conjuntos externos no es fácil de hacer sin duplicar su código o utilizar trucos con el control del código fuente.

Creo que es más fácil mantener un proyecto para desarrollo y prueba unitaria, luego crear proyectos de 'compilación' usando enlaces de archivos existentes cuando necesite crear los ensamblajes que hacen referencia a diferentes versiones de esos ensamblajes externos.

Una forma más sencilla de incluir un archivo de clase de un proyecto en otro proyecto es agregar el proyecto en la solución existente y luego agregar la referencia DLL del nuevo proyecto en el proyecto existente. Finalmente, puede usar los métodos de la clase agregada al descalcificar usando la directiva en la parte superior de cualquier clase.

A partir de VisualStudio 2015, si mantiene todo su código en una solución, puede compartir el código agregando un proyecto compartido . Luego agregue una referencia a este proyecto compartido para cada proyecto en el que desee usar el código, así como las directivas de uso adecuadas.

Ahora puedes usar el proyecto compartido

Shared Project es una excelente manera de compartir código común en varias aplicaciones. Ya hemos experimentado con el tipo de proyecto compartido en Visual Studio 2013 como parte del desarrollo de aplicaciones universales de Windows 8.1, pero con Visual Studio 2015, es una nueva plantilla de proyecto independiente; y podemos usarlo con otros tipos de aplicaciones como consola, escritorio, teléfono, tienda de aplicaciones, etc. Este tipo de proyecto es extremadamente útil cuando queremos compartir un código común, lógica y componentes a través de múltiples aplicaciones en una sola plataforma . Esto también permite acceder a las API, activos, etc. específicos de la plataforma.

para más información revisa esto