Referencia del proyecto Vs File Reference?

Question

Las referencias se pueden agregar de dos maneras en un proyecto.

1. Proyecto de referencia.
2. Referencia de archivo.

Pero, ¿Cuándo usar Project y cuándo usar File reference?

Answer 1

No ha especificado pero supongo que te refieres a Visual Studio?

La principal diferencia entre una referencia de proyecto y una referencia de archivo es si hay actualizaciones activas disponibles o no. En una referencia de proyecto, podrá ver los efectos de las ediciones en un proyecto inmediatamente en el otro proyecto a través de elementos como Intellisense. Entonces, si, por ejemplo, agrega una clase llamada Foo, este tipo se mostrará inmediatamente en intellisense en cualquier proyecto que tenga una referencia de proyecto en ese proyecto.

Las referencias de archivo, por otro lado, solo pueden ver los cambios que están presentes en el disco. Se debe realizar una compilación y escribir bits en el disco para ver los cambios.

En general, es mejor usar una referencia de proyecto.

Otro ángulo que debe tenerse en cuenta son los idiomas relativos de los proyectos. Las referencias de Project to Project son de máxima utilidad si el lenguaje en ambos proyectos es el mismo. Si los idiomas son diferentes, tienden a tratarse más como referencias de archivos que como referencias de proyectos.

Answer 2

Utilice "referencia de proyecto" para agregar una referencia a los ensamblajes dentro de su solución.

Uso “referencia de archivo” para agregar una referencia a una solución asambleas transversales

Source

Answer 3

Al final, todas las referencias son referencias de archivos, Project Reference es solo una función de estudio visual, que hace referencia a un archivo que se está creando con su solución, por lo que siempre que construya una nueva construcción, la referencia se actualiza automáticamente sin que vayas a copiar & pegar los archivos

Answer 4

Una razón para que yo vaya por una referencia de archivo (incluso cuando tengo la fuente o creé el ensamblaje) es cuando ese ensamblaje en particular no cambia mucho (digamos una vez cada medio año). Solo para reducir el tiempo de compilación. Además, algunos proyectos incrementan automáticamente su número de versión (por ejemplo, intente incluir el proyecto AjaxControlToolkit en su solución).

Answer 5

acabo de ir a través de este ...

Hemos recibido, de un proveedor, cerca de 53 diferentes archivos # solución VS2005 C que crearon 63 .dlls de proyectos diferentes, todos los cuales son llamados por una solicitud por separado, comercial.

Todos los proyectos contenían referencias de archivos a los dlls de los otros proyectos.

Los problemas con este enfoque eran geniales: las dependencias entre soluciones eran casi imposibles de resolver, involucrando un lote lote de los comandos "findstr"; la funcionalidad de "búsqueda de definición" de VS no encontraría la fuente de archivos dlls con referencia a archivos, solo mostraría las definiciones de las funciones dentro de las DLL; la reconstrucción debido a los cambios era propensa a errores, engorrosa e implicaba abrir muchas soluciones diferentes para reconstruir todo el conjunto de dll.

Pasé semanas combinando los 53 archivos de solución diferentes en uno, luego pasé tiempo adicional cambiando todas las dependencias de archivos a las dependencias del proyecto. Ahora, cuando "encuentras la definición", te llevan a un archivo fuente. Ahora, cuando cambia un proyecto de bajo nivel, todos los proyectos dependientes se construirán cuando construya la (una) solución.

Realicé algunos cambios adicionales, pero el más práctico fue establecer todos los directorios de compilación de los proyectos separados en solutiondir/bin. De esa forma, todas las dlls terminan en un solo lugar.

Oh, sí: también configuré 'copy local' en 'no' para todos los archivos dlls de los proyectos a los que se hace referencia. De esta forma, cada dll aparece en solutiondir/bin a medida que se construye el proyecto y lo encuentran los siguientes proyectos para compilar.

El único problema que tenemos ahora es que si cambio un proyecto que se usa como fuente de datos para otro proyecto con Windows Form, Windows Form no se abrirá en Designer hasta que vuelva a compilar el proyecto que es el origen de datos para la forma. Un precio pequeño y pequeño para pagar por todos los beneficios de las referencias de proyectos. Además, tengo que crear la solución al momento de pagar desde svn porque los dlls no están en svn. En el caso anterior, el origen de datos .dll no está ahí para que el Diseñador lo encuentre.

Answer 6

Cuando se reconstruye un proyecto, todos los proyectos que lo referencian como proyecto también se reconstruyen automáticamente.

Esto no es cierto para las referencias de archivos.

Answer 7

En realidad, ambos métodos utilizan referencias de archivo. La referencia del proyecto es útil para VS para saber cuando el Proyecto VS referencia debe construir

s

Answer 8

utils referencias:

http://www.lostechies.com/blogs/chad_myers/archive/2008/07/15/project-anti-pattern-many-projects-in-a-visual-studio-solution-file.aspx

http://www.ssw.com.au/ssw/Standards/Rules/RulesToBetterLargedotNETProjects.aspx

http://blogs.msdn.com/b/ricom/archive/2004/10/18/244242.aspx

Answer 9

I' Hemos establecido específicamente nuestro equipo de desarrollo en el uso de referencias de archivo en lugar de un proyecto referecnes en la mayoría de los casos: Operamos en un dominio de alta integridad. Por lo tanto, cada componente que no sea directamente parte de este trabajo (es decir, cosas que se comparten en otros proyectos) no se debe cambiar de ninguna manera. Por lo tanto, la idea es (en un trabajo ideal que no sea greenfield) que tomemos versiones probadas, autorizadas y conocidas de los subcomponentes de un área de publicación de la red y los incluyamos en un área de componentes de la solución.

Esto tiene la intención de simplificar el mantenimiento y las pruebas, ya que debe evitar la proliferación de muchas versiones similares, todas con diferentes números de compilación o SVN.

La segunda razón (y es probablemente mi fondo C/C++) es que me gustaría saber que estoy usando todas las versiones de Debug o todas las versiones. No puedes hacer esto fácilmente en proyectos .NET. Construimos en un directorio components \ $ configuration $ y luego tenemos un paso posterior a la compilación para copiar desde components \ $ configuration $ al directorio de arriba. Todas las referencias de archivos corresponden a los archivos en el directorio de componentes, lo que significa (creo) que realmente tenemos compilaciones de depuración y liberación que se realizan a lo largo de la cadena.

Si realiza envíos externos creo que debe considerar que los archivos DLL que salen deben ser iguales para todos los usuarios, de lo contrario corre el riesgo de no poder depurar problemas más adelante (seguimiento de la configuración del código fuente a ejecutables entregados) .)

Answer 10

Me he encontrado con problemas en varios proyectos donde las referencias de archivos simplemente no lo cortan. Las referencias obsoletas causan problemas buku. Microsoft recomienda que utilizamos referencias de archivo sólo cuando sea necesario:

http://msdn.microsoft.com/en-us/library/ee817675.aspx

Answer 11

Uno de error (C1083) que tenía cuando se cambia a referencias (& eliminación relativa incluye) fue "no Header encontrado." Tenía:

• en las preferencias include: ../../src/module
• en el código fuente: #include "file.h"

---

Fijar la ruta relativa para que funcione:

#include "module/file.h"