Esiste un modo per accedere al file delle impostazioni da un altro progetto? Ad esempio, ho una soluzione che contiene 2 progetti (li chiamiamo Proj1 e Proj2). Voglio accedere alle impostazioni dell'applicazione di Proj2 da Program.cs in Proj1. È possibile?Accesso al file delle impostazioni di un altro progetto
Opzione A: analizzare i valori di file di configurazione di l'altro gruppo (in cui sono memorizzate le impostazioni)
Opzione B: creare una classe pubblica in Proj2 che espone i valori necessari dalle sue impostazioni come proprietà statiche, poi fare riferimento all'assieme in Proj1 e consumare i valori da quella classe.
Opzione C: se si desidera visualizzare TUTTE le impostazioni, è possibile modificare l'accesso alla classe delle impostazioni da internal a public.
Sono sicuro che ci sono anche altri modi.
La risposta se si utilizza C#:
La risposta molto semplice è fare clic destro su proj2, selezionare la scheda impostazioni. In alto, troverai il modificatore di accesso della classe delle impostazioni: interna, cambialo in pubblico. Aggiungi un riferimento al proj2 nel proj1 per vedere la classe Impostazioni proj2. È tutto.
Ok, questo ha decisamente senso, ma come si dovrebbe cambiare queste impostazioni senza compilazione? Diciamo che si distribuisce il progetto A, con le impostazioni di riferimento del progetto B. Si desidera modificare le impostazioni dal progetto B, ma tutto ciò che si ha sono valori predefiniti compilati nella dll? Questa è l'unica spiegazione che riesco a trovare, dato che non esiste un file di configurazione distribuito o fuso con le impostazioni del progetto A. – mikus
Ho provato questo e funziona, ma ha la limitazione dichiarata da @mikus. Inoltre, se si utilizzano le trasformazioni XML (ad esempio con SlowCheetah), le modifiche delle trasformazioni non verranno visualizzate da Proj1, anche con una ricompilazione. –
Non funziona per me. – Patrick
io non ho provato questo metodo me stesso, ma piccolo trucco di Eric De Carufel può essere quello che ti serve:
http://blog.decarufel.net/2007/10/getting-access-to-settings-in-another.html
Il link originale sembra essere morto come lui è trasferita in un nuovo blog e cancellati vecchio contenuto.
Il contenuto originale è qui sotto:
Giovedi, 25 mese di ottobre, 2007
Una delle nuove funzioni di Visual Studio 2005 è il nuovo editor di proprietà . Con questo editor di proprietà puoi facilmente aggiungere impostazioni alla tua applicazione. Ma c'è un problema nel modo in cui è impelagato. Lascia che ti spieghi perché.
Di solito le impostazioni sono specifiche per un progetto. Quando aggiungi un'impostazione in un progetto, uno speciale strumento personalizzato associato al file delle impostazioni genera una nuova classe che puoi utilizzare per accedervi. Ciò che è buono in questa classe è che è fortemente digitato. Ma dietro la scena è solo ottenere una chiave da un file xml. Questa classe generata è impostata come "internal sealed". Ciò impedisce di accedere a qualsiasi altro assieme. Cosa succede se si desidera centralizzare dove si modificano queste impostazioni.
Dopo molti tentativi di esporlo ho trovato un modo rapido e semplice per farlo. Diciamo che abbiamo 2 progetti nella nostra soluzione: un motore e una WinApp. Ognuno ha le impostazioni, ma vogliamo che siano modificabili da WinApp. Ecco come appare.
Se si desidera accedere alle impostazioni del motore, ecco il trucco: aggiungere un file di collegamento.
Il file di collegamento verrà compilato come parte del progetto WinApp. La classe di impostazione sarà ancora interna e sigillata ma al progetto WinApp anziché a Engine.
Ecco il risultato finale:
Si noti che ho Addes un foler con lo stesso nome del mio progetto del motore. Ciò sarà utile se si desidera aggiungere impostazioni da molti progetti.
Con questo in posizione è possibile accedere al motore impostando la strada dalla classe del motore come dalla classe WinApp. Puoi omettere la parte "Motore" dalla tua classe motore perché dovresti trovarti nello stesso spazio dei nomi. Qui è quello che dovrebbe essere simile:
namespace WinApp { public partial class Form1: Modulo { Form1 pubblico() { InitializeComponent(); }
public void AccessConfig()
{
Engine.Properties.Settings.Default.EngineSetting = "test";
}
}
}
Link è morto – Kuffs
Trovato il contenuto originale che è stato collegato e copiato qui (il blog è morto) – Kildareflare
ho dovuto venire con un'altra soluzione oltre a quelli qui già assunti in quanto stavo usando tranforms XML (tramite SlowCheetah) sul App.config del mio progetto che contiene le impostazioni. Se non lo fai, ti consiglio una delle altre soluzioni.
Ho aggiunto una fase di post-produzione nel progetto di consumo (Proj1 nell'esempio) per copiare il file di configurazione dalla cartella di output di Proj2. Ciò assicurerà che la configurazione abbia le trasformazioni applicate. (Nel mio caso, Proj1 è una DLL, quindi se il vostro è un exe, cambiate le DestinationFiles da ".dll.config" a "exe.config".) Snippet da Proj1.csproj:
<Target Name="AfterBuild">
<Copy SourceFiles="..\Proj2\bin\$(Configuration)\Proj2.exe.config" DestinationFiles="$(TargetDir)\$(AssemblyName).dll.config" />
</Target>
Poi Ho creato un collegamento di Settings.settings da Proj2 ctrl + shift + trascinando il file su Proj1 (come nell'articolo del blog a cui si fa riferimento Kildareflare).
Potrei quindi fare riferimento alle impostazioni in Proj1 simile a: Proj2.Properties.Settings.Default.MySetting.
Nota: se si esegue questa operazione per test di unità come I am (Proj1 è una DLL di test) e si utilizza il runner di prova ReSharper, assicurarsi di configure it to run tests in separate AppDomains.
Riprenderò il contenuto del collegamento di @ Kildareflare per riferimento futuro. Funziona ancora in VS2015, ma per quanto mi riguarda penso di preferire "Opzione B" sopra.
Ottenere l'accesso alle impostazioni in un altro progetto
Una delle nuove funzioni di Visual Studio 2005 è il nuovo editor di proprietà. Con questo editor di proprietà puoi facilmente aggiungere impostazioni alla tua applicazione. Ma c'è un problema nel modo in cui è implementato. Lascia che ti spieghi perché.
Di solito le impostazioni sono specifiche per un progetto. Quando aggiungi un'impostazione in un progetto, uno speciale strumento personalizzato associato al file delle impostazioni genera una nuova classe che puoi utilizzare per accedervi. Ciò che è buono in questa classe è che è fortemente digitato. Ma dietro la scena è solo ottenere una chiave da un file xml. Questa classe generata è impostata come "internal sealed". Questo impedisce l'accesso da qualsiasi altro assembly. Cosa succede se si desidera centralizzare dove si modificano queste impostazioni.
Dopo molti tentativi di esporlo ho trovato un modo rapido e semplice per farlo. Diciamo che abbiamo 2 progetti nella nostra soluzione: un motore e una WinApp. Ognuno ha le impostazioni, ma vogliamo che siano modificabili da WinApp. Ecco come appare.
Se si desidera ottenere l'accesso alle impostazioni del motore qui il trucco: Aggiungere un file di collegamento.
Il file di collegamento verranno compilati come parte di progetto che WinApp. La classe di impostazione sarà ancora interna e sigillata ma al progetto WinApp anziché a Engine.
Ecco il risultato finale:
Si noti che ho aggiunto una cartella con lo stesso nome del mio progetto del motore. Ciò sarà utile se si desidera aggiungere impostazioni da molti progetti.
Con questo in posizione è possibile accedere al motore impostando la strada dalla classe del motore come dalla classe WinApp. Puoi omettere la parte "Motore" dalla tua classe motore perché dovresti trovarti nello stesso spazio dei nomi. Qui è quello che dovrebbe apparire come:
namespace WinApp
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
public void AccessConfig()
{
Engine.Properties.Settings.Default.EngineSetting = "test";
}
}
}
Questo non funziona per me. Sto ancora ricevendo "Impostazioni" inaccessibili a causa del suo livello di protezione " – Mugen
Dal Settings.Designer.cs è una classe internal, e non si vuole pasticciare con un file di codice generato, mi sento di raccomandare di aggiungere il secondario come un progetto "amico".
Da: C# "internal" access modifier when doing unit testing
Add seguente codice per l'opzione B 's AssemblyInfo.cs
using System.Runtime.CompilerServices;
[assembly:InternalsVisibleTo("Proj1")]
ho usato la
Proj2, che è stato il primo pensiero che ho avuto pure. Grazie! – KrisTripHo provato l'opzione C e non sembra funzionare. Mi viene assegnato un set separato di impostazioni per ogni progetto:/ – Patrick
L'opzione C ha funzionato per me come un incantesimo. –