¿Hay alguna manera de acceder al archivo de configuración desde un proyecto diferente? Por ejemplo, tengo una solución que contiene 2 proyectos (vamos a llamarlos Proj1 y Proj2). Quiero acceder a la configuración de la aplicación de Proj2 desde Program.cs en Proj1. es posible?Acceder al archivo de configuración de otro proyecto
Opción A: analizar los valores de archivo de configuración del otro conjunto (donde se almacenan los ajustes)
Opción B: crear una clase pública en Proj2 que expone los valores necesarios de su configuración como propiedades estáticas, a continuación, Haga referencia al ensamblaje en Proj1 y consuma los valores de esa clase.
Opción C: si desea exponer TODAS las configuraciones, puede modificar el acceso de la clase de configuración de internal a public.
Estoy seguro de que hay otras formas también.
La respuesta si está utilizando C#:
La respuesta muy simple es hacer clic derecho en proj2, elija la pestaña de configuración. En la parte superior, encontrará que el modificador de acceso de la clase de configuración es: interno, cámbielo a público. Agregue una referencia al proj2 en el proj1 para ver la clase de configuración de proj2. Eso es todo.
Ok, esto definitivamente tiene sentido, pero ¿cómo se supone que debes cambiar estas configuraciones sin compilación? Digamos que despliega el proyecto A, con la configuración referenciada del proyecto B. ¿Desea modificar las configuraciones del proyecto B, pero todo lo que tiene son los valores predeterminados compilados en el dll? Como esa es la única explicación que puedo encontrar, ya que no hay un archivo de configuración implementado o fusionado con la configuración del proyecto A. – mikus
Intenté esto y funciona, pero tiene la limitación establecida por @mikus. Además, si usa transformaciones XML (por ejemplo, con SlowCheetah), Proj1 no verá los cambios de las transformaciones, incluso con una recompilación. –
No funciona para mí. – Patrick
no he probado este método de mí mismo, pero pequeño truco de Eric De Carufel puede ser lo que necesita:
http://blog.decarufel.net/2007/10/getting-access-to-settings-in-another.html
El enlace parece estar muerta ya que se ha trasladado a un nuevo blog y borrado contenido antiguo
El contenido original es el siguiente:
Jueves, 25 de octubre 2007
Una de las nuevas características interesantes de Visual Studio 2005 es el nuevo editor de propiedades . Con este editor de propiedades, puede agregar fácilmente la configuración a su aplicación. Pero hay un problema de la forma en que se ve obligado a hacerlo. Déjame explicarte por qué.
Por lo general, las configuraciones son específicas de un proyecto. Cuando agrega una configuración en un proyecto, una herramienta personalizada especial asociada con el archivo de configuración genera una nueva clase que puede usar para acceder a ella. Lo que es bueno acerca de esta clase es su fuerte tipado. Pero detrás de la escena solo está obteniendo una clave de un archivo xml. Esta clase generada se establece como "interna sellada". Esto evita que se acceda desde cualquier otro ensamblaje. ¿Qué sucede si quiere centralizar dónde edita estas configuraciones?
Después de muchos intentos de exponerlo encontré una forma rápida y fácil de hacerlo. Digamos que tenemos 2 proyectos en nuestra solución: un motor y un WinApp. Cada uno tiene configuraciones, pero queremos que sean editables desde WinApp. Esto es lo que parece.
Si desea obtener acceso a la configuración del motor aquí truco: Agregar un archivo de enlace.
El archivo de enlace se compilará como parte del proyecto de WinApp. La clase de configuración seguirá siendo interna y sellada, pero para el proyecto de WinApp en lugar de Engine.
Aquí está el resultado final:
Aviso que Addes un foler con el mismo nombre que mi proyecto del motor. Esto será útil si desea agregar configuraciones de muchos proyectos.
Con esto en su lugar puede acceder a su motor estableciendo el camino desde su clase de motor como desde su clase de WinApp. Puede omitir la parte "Motor" de su clase de motor porque debe estar en el mismo espacio de nombres. Esto es lo que debe ser similar:
espacio de nombres WinApp { public partial class Form1: Formulario { public Form1() { InitializeComponent(); }
public void AccessConfig()
{
Engine.Properties.Settings.Default.EngineSetting = "test";
}
}
}
El enlace está ahora muerto – Kuffs
Encontró el contenido original que se vinculó y se vinculó aquí (el blog ahora está muerto) – Kildareflare
que tenía que llegar a otra solución, además de las ya indicadas aquí porque estaba usando XML (tranforms través SlowCheetah) en el App.config de mi proyecto que contiene la configuración. Si no está haciendo esto, le recomiendo una de las otras soluciones.
Agregué un paso posterior a la compilación en el proyecto consumidor (Proj1 en el ejemplo) para copiar el archivo de configuración de la carpeta de salida de Proj2. Esto asegurará que la configuración tendrá las transformadas aplicadas. (En mi caso, Proj1 es una DLL, por lo que si el suyo es un exe, cambie la DestinationFiles de ".dll.config" a "exe.config".) Fragmento de Proj1.csproj:
<Target Name="AfterBuild">
<Copy SourceFiles="..\Proj2\bin\$(Configuration)\Proj2.exe.config" DestinationFiles="$(TargetDir)\$(AssemblyName).dll.config" />
</Target>
Entonces Creé un enlace de Settings.settings desde Proj2 mediante ctrl + shift + arrastrando el archivo a Proj1 (como en el artículo del blog al que hace referencia el Kildareflare).
Pude entonces hacer ajustes de referencia en Proj1 similares a: Proj2.Properties.Settings.Default.MySetting.
Nota: Si está haciendo esto para pruebas unitarias como I am (Proj1 es una DLL de prueba), y está utilizando el corrector de prueba ReSharper, asegúrese de configure it to run tests in separate AppDomains.
Volveré a publicar el contenido del enlace de @ Kildareflare para referencia futura. Todavía funciona en VS2015, pero creo que prefiero la "Opción B" de arriba.
Conseguir acceso a la configuración en otro proyecto
Una de las nuevas características interesantes de Visual Studio 2005 es el nuevo editor de propiedades. Con este editor de propiedades, puede agregar fácilmente la configuración a su aplicación. Pero hay un problema en la forma en que se implementa. Déjame explicarte por qué.
Por lo general, las configuraciones son específicas de un proyecto. Cuando agrega una configuración en un proyecto, una herramienta personalizada especial asociada con el archivo de configuración genera una nueva clase que puede usar para acceder a ella. Lo que es bueno acerca de esta clase es su fuerte tipado. Pero detrás de la escena solo está obteniendo una clave de un archivo xml. Esta clase generada se establece como "interna sellada". Esto evita el acceso desde cualquier otro ensamblaje. ¿Qué sucede si quiere centralizar dónde edita estas configuraciones?
Después de muchos intentos de exponerlo encontré una forma rápida y fácil de hacerlo. Digamos que tenemos 2 proyectos en nuestra solución: un motor y un WinApp. Cada uno tiene configuraciones, pero queremos que sean editables desde WinApp. Esto es lo que parece.
Si desea obtener acceso a la configuración del motor aquí el truco: Añadir un archivo de enlace.
El archivo de enlace se compilará como parte del proyecto como se WinApp. La clase de configuración seguirá siendo interna y sellada, pero para el proyecto de WinApp en lugar de Engine.
Aquí está el resultado final:
Tenga en cuenta que he añadido una carpeta con el mismo nombre que mi proyecto del motor. Esto será útil si desea agregar configuraciones de muchos proyectos.
Con esto en su lugar puede acceder a su motor estableciendo el camino desde su clase de motor como desde su clase de WinApp. Puede omitir la parte "Motor" de su clase de motor porque debe estar en el mismo espacio de nombres. Esto es lo que debe ser similar:
namespace WinApp
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
public void AccessConfig()
{
Engine.Properties.Settings.Default.EngineSetting = "test";
}
}
}
Esto no funciona para mí. Todavía estoy recibiendo ''Configuración' es inaccesible debido a su nivel de protección' – Mugen
Desde Settings.Designer.cs es una clase internal, y no quieren meterse con un archivo de código generado, lo recomendaría para agregar la secundaria como un proyecto de "amigo".
Desde: C# "internal" access modifier when doing unit testing
Agregar código siguiente a la Proj2 's AssemblyInfo.cs
using System.Runtime.CompilerServices;
[assembly:InternalsVisibleTo("Proj1")]
utilicé la opción B, que fue el primer pensamiento que tuve también. ¡Gracias! – KrisTrip
He intentado la opción C y parece que no funciona. Se me da un conjunto de configuraciones por separado para cada proyecto:/ – Patrick
La opción C funcionó para mí como un amuleto. –