2009-06-22 14 views

Respuesta

3

No hay razón, de verdad. Podría ser que Visual Studio esté configurado para mostrar archivos que no están en el proyecto (difícil de distinguir de la imagen) y que los dll estén en el directorio principal. El texto es bastante claro que el resto de ficheros son

  • bass.dll
  • bassenc.dll
  • lame.exe

El .NET pasa a ser con los otros en la misma directorio y necesita agregarlo como referencia.

0

Si un ensamblado (Bass.Net.dll en su caso) contiene clases que desea utilizar, debe agregar una referencia a ese ensamblado a su proyecto.

+0

bien entiendo por qué está en la Referencia, pero no por qué se agrega como un archivo en el proyecto. – Mat

+0

Lo siento, no entendí bien la pregunta. Sí, es suficiente agregarlo como referencia, tenerlo "agregado como un archivo" no es importante. Y, por supuesto, debe estar en la misma carpeta que el ejecutable más tarde cuando implemente su aplicación. – Groo

0

No tiene sentido lo mejor que puede hacer es conseguir todos sus dependenicies y almacenarlos en una carpeta separada y sólo hacen referencia a ellos no les copian a su solución;)

+0

A veces tiene sentido tener una copia local de la DLL. –

1

Tener aquellos en el directorio del proyecto y la salida permite que el código de ejecución final haga referencia a ellos sin ningún problema que se ejecute en diferentes máquinas.

Suena como si pusieran las referencias dlls en el directorio del proyecto, las referencias desde allí y también las incluyan en el proyecto. De esta forma, cuando se copia el directorio del proyecto, el dll de referencia se copiará con él. Además, si falta el dll de referencia, el proyecto se quejará en Visual Studio.

2

En Windows, una DLL es dynamic link library, que empaqueta un conjunto de funcionalidades programáticas. En este ejemplo, bass.dll expone las características y funcionalidades relevantes para el procesamiento de audio a través de este archivo (y cualquier archivo del que dependa). Para utilizar esta funcionalidad, necesita la referencia en la solución, para que Visual Studio pueda link it en tiempo de compilación. Normalmente, el archivo DLL se copiará en el directorio de salida cuando se genere la aplicación.

Eso es todo lo que se necesita para que el código funcione correctamente, el resto es solo una preferencia o convención. Algunas personas prefieren tener todos los archivos que existen en el directorio del proyecto en la solución, de modo que Solution Explorer refleje el sistema de archivos. Normalmente, querrá tener bibliotecas de las que su aplicación dependa en algún lugar de la jerarquía de su directorio de soluciones para que toda la aplicación esté empaquetada (por ejemplo, hacer que el control del código fuente sea más fácil). No querrás poner esta biblioteca en el directorio BIN o en cualquier directorio que genere Visual Studio, para evitar eliminaciones accidentales. En cualquier caso, tener la referencia es la parte importante, el archivo que está en el proyecto o la solución no es necesario.

Normalmente, querrá mantener las bibliotecas externas fuera de sus directorios de origen, por lo que en realidad no recomendaría esta estructura.Yo tiendo a usar una estructura como esta, pero, de nuevo, esto es todo preferencia:

  • Fuente: código y archivos de proyecto Fuente
  • Bibliotecas: DLL
  • Soporte: código o proyectos diversos, pero en realidad no parte de la aplicación (quizás scripts de implementación)
0

Es realmente difícil adivinar por qué alguien más hizo algo, pero si realmente tuviera que adivinar, diría que el tipo pensó en incorporar los dlls necesarios como recursos para asegúrese de que esté disponible para la aplicación. He visto esta técnica utilizada para incrustar fuentes o sonidos y no estoy seguro si funciona en absoluto con dlls; pero es solo una suposición.
Por supuesto, la mejor manera de asegurarse de que los archivos estuvieran disponibles hubiera sido crear un proyecto de implementación, con Visual Studio u otra herramienta de instalación loke Wise o InnoSetup, solo por nombrar algunos.

0

Esto realmente podría ser una buena idea en muchas circunstancias. En mi opinión, hay 3 tipos de dependencias

  1. Conjuntos de la biblioteca estándar .Net. Nunca los incluya localmente.
  2. Conjuntos que espera que otros desarrolladores instalen como parte de un paquete de instalación de MSI o exe. Esto generalmente significa que tienen una firma fuerte y una copia en el GAC.
  3. Conjuntos que no espera que otros desarrolladores instalen a través de un instalador MSI o exe. Tal vez porque tiene un tercero o una biblioteca interna que no está en el GAC.

En el tercer caso, lo más simple es almacenar una copia de la DLL en el repositorio de origen.

Cuestiones relacionadas