Czy istnieje sposób uzyskania dostępu do pliku ustawień z innego projektu? Na przykład mam rozwiązanie, które zawiera 2 projekty (nazwijmy je Proj1 i Proj2). Chcę uzyskać dostęp do ustawień aplikacji Proj2 z Program.cs w Proj1. czy to możliwe?Uzyskiwanie dostępu do pliku ustawień innego projektu
Odpowiedz
Wariant A: analizowania wartości z pliku konfiguracyjnego drugiego zgromadzenia (gdzie przechowywane są ustawienia)
Opcja B: stworzyć publiczną klasę w Proj2
że naraża koniecznych wartości z jego ustawieniami właściwości statycznych, a następnie odwołaj się do zestawu w Proj1
i użyj wartości z tej klasy.
Opcja C: Jeśli chcesz wyświetlić WSZYSTKIE ustawienia, możesz zmodyfikować dostęp do klasy ustawień od internal
do public
.
Jestem pewien, że istnieją również inne sposoby.
Odpowiedź, jeśli używasz C#:
Bardzo prostą odpowiedzią jest kliknięcie prawym klawiszem na proj2, wybierz zakładkę ustawień. Na górze znajdziesz modyfikator dostępu do klasy ustawień: internal, zmień ją na public. Dodaj odwołanie do proj2 w proj1, aby zobaczyć klasę ustawień proj2. To wszystko.
OK, to zdecydowanie ma sens, ale jak masz zmienić te ustawienia bez kompilacji? Powiedzmy, że wdrażasz projekt A z referencyjnymi ustawieniami projektu B. Chcesz zmodyfikować ustawienia z projektu B, ale wszystko, co masz, to wartości domyślne skompilowane do biblioteki dll? To jedyne wyjaśnienie, jakie mogę znaleźć, ponieważ nie ma pliku konfiguracyjnego wdrożonego lub połączonego z ustawieniami projektu A. – mikus
Próbowałem tego i działa, ale ma ograniczenie określone przez @mikus. Ponadto, jeśli używasz transformacji XML (np. Z SlowCheetah), zmiany z transformacji nie będą widziane przez Proj1, nawet z rekompilacją. –
Nie działa dla mnie. – Patrick
ja ale mały trick Eric De Carufel może być to, czego potrzebujesz nie Przetestowałem tą metodą:
http://blog.decarufel.net/2007/10/getting-access-to-settings-in-another.html
oryginalny link wydaje się być martwy, kiedy przeniósł się do nowego bloga i usunięte stara treść.
Oryginalna treść jest poniżej:
Uzyskiwanie dostępu do ustawień w innym projekcie
czwartek, 25 października 2007
jeden z nowych ciekawych funkcji Visual Studio 2005 to nowy edytor nieruchomość . Za pomocą tego edytora właściwości możesz z łatwością dodać ustawienia do swojej aplikacji. Ale to jest problem w taki sposób, w jaki został wprowadzony. Pozwól mi wyjaśnić, dlaczego.
Zazwyczaj ustawienia są specyficzne dla projektu. Po dodaniu ustawienia w projekcie specjalne niestandardowe narzędzie powiązane z plikiem ustawień generuje nową klasę, której można użyć, aby uzyskać do niej dostęp. To, co jest dobre w tej klasie, jest mocno napisane. Ale za sceną po prostu dostaje klucz z pliku xml. Ta wygenerowana klasa jest ustawiona jako "wewnętrznie zapieczętowana". Zapobiega to dostępowi z dowolnego innego zespołu. Co jeśli chcesz scentralizować miejsce edycji tych ustawień.
Po wielu próbach jego ujawnienia znalazłem szybki i łatwy sposób na zrobienie tego. Załóżmy, że mamy 2 projekty w naszym rozwiązaniu: Engine i WinApp. Każdy ma ustawienia, ale chcemy, aby były edytowalne z WinApp. Oto jak to wygląda.
Jeśli chcesz uzyskać dostęp do ustawień silnika, tutaj th trick: Dodaj plik łącza.
Plik linku zostanie skompilowany jako część projektu WinApp. Klasa ustawień będzie nadal wewnętrzna i zapieczętowana, ale do projektu WinApp zamiast do silnika.
Oto efekt końcowy:
Wskazówka I dodaje, że jest foler o tej samej nazwie co moim projekcie silnika. Będzie to pomocne, jeśli chcesz dodać ustawienia z wielu projektów.
Dzięki temu miejscu masz dostęp do silnika ustawiającego drogę z klasy silnika od klasy WinApp. Możesz pominąć część "Engine" z klasy silnika, ponieważ powinieneś znajdować się w tej samej przestrzeni nazw. Oto jak to powinno wyglądać:
nazw WinApp { public partial class Form1: Form { public Form1() { InitializeComponent(); }
public void AccessConfig()
{
Engine.Properties.Settings.Default.EngineSetting = "test";
}
}
}
Link jest już martwy – Kuffs
Znaleziono oryginalną zawartość, która została powiązana i skopiowana tutaj (blog jest już martwy) – Kildareflare
musiałem wymyślić inne rozwiązanie oprócz tych już podanych tutaj, ponieważ używałem konwertuje XML (przez SlowCheetah) na app.config mojego projektu zawierającego ustawienia. Jeśli tego nie robisz, polecam jedno z pozostałych rozwiązań.
Dodałem krok po kompilacji do projektu zużywającego (w przykładzie Proj1), aby skopiować plik konfiguracyjny z folderu wyjściowego Proj2. Zapewni to, że konfiguracja będzie miała zastosowane transformacje. (W moim przypadku proj1 jest dll, więc jeśli twój jest exe, zmień DestinationFiles z ".dll.config" na "") .exe.config urywek z Proj1.csproj:
<Target Name="AfterBuild">
<Copy SourceFiles="..\Proj2\bin\$(Configuration)\Proj2.exe.config" DestinationFiles="$(TargetDir)\$(AssemblyName).dll.config" />
</Target>
Następnie Stworzyłem łącze Settings.settings z Proj2 przez ctrl + shift + przeciągając plik do Proj1 (jak w artykule na blogu, do którego odnosi się Kildareflare
).
Mogłem wtedy porównać ustawienia w Proj1 podobne do: Proj2.Properties.Settings.Default.MySetting
.
Uwaga: Jeśli robisz to dla testów jednostkowych takich jak ja (Proj1 jest testową biblioteką DLL), i używasz testera ReSharper, pamiętaj o configure it to run tests in separate AppDomains.
Przekażę zawartość linku @ Kildareflare do przyszłego użytku. Nadal działa w VS2015, ale ja uważam, że wolę "Opcja B" powyżej.
Uzyskiwanie dostępu do ustawień w innym projekcie
jeden z nowych ciekawych funkcji Visual Studio 2005 jest nowy redaktor własność. Za pomocą tego edytora właściwości możesz z łatwością dodać ustawienia do swojej aplikacji. Ale jest problem w sposobie jego implementacji. Pozwól mi wyjaśnić, dlaczego.
Zazwyczaj ustawienia są specyficzne dla projektu. Po dodaniu ustawienia w projekcie specjalne niestandardowe narzędzie powiązane z plikiem ustawień generuje nową klasę, której można użyć, aby uzyskać do niej dostęp. To, co jest dobre w tej klasie, jest mocno napisane. Ale za sceną po prostu dostaje klucz z pliku xml. Ta wygenerowana klasa jest ustawiona jako "wewnętrznie zapieczętowana". To uniemożliwia dostęp z dowolnego innego zespołu. Co jeśli chcesz scentralizować miejsce edycji tych ustawień.
Po wielu próbach jego ujawnienia znalazłem szybki i łatwy sposób na zrobienie tego. Załóżmy, że mamy 2 projekty w naszym rozwiązaniu: Engine i WinApp. Każdy ma ustawienia, ale chcemy, aby były edytowalne z WinApp. Oto jak to wygląda.
Jeśli chcesz uzyskać dostęp do ustawień silnika tu podstęp: Dodaj plik łącza.
Plik link zostanie opracowana w ramach projektu, jak ty WinApp. Klasa ustawień będzie nadal wewnętrzna i zapieczętowana, ale do projektu WinApp zamiast do silnika.
Oto efekt końcowy:
Zauważ, że dodałem folder o takiej samej nazwie jak mojego projektu silnika. Będzie to pomocne, jeśli chcesz dodać ustawienia z wielu projektów.
Dzięki temu miejscu masz dostęp do silnika ustawiającego drogę z klasy silnika od klasy WinApp. Możesz pominąć część "Engine" z klasy silnika, ponieważ powinieneś znajdować się w tej samej przestrzeni nazw. Oto jak to powinno wyglądać:
namespace WinApp
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
public void AccessConfig()
{
Engine.Properties.Settings.Default.EngineSetting = "test";
}
}
}
To nie działa dla mnie. Wciąż otrzymuję komunikat, że "Ustawienia" są niedostępne ze względu na poziom ochrony " – Mugen
Od Settings.Designer.cs
jest klasa internal
i nie chcą zadzierać z wygenerowanego pliku z kodem, polecam dodać wtórnym jako projekt „przyjaciel”.
Od: C# "internal" access modifier when doing unit testing
Dodaj następujący kod do Proj2
„s AssemblyInfo.cs
using System.Runtime.CompilerServices;
[assembly:InternalsVisibleTo("Proj1")]
użyłem opcji B, która była pierwsza myśl miałem, jak również. Dzięki! – KrisTrip
Próbowałem opcji C i wydaje się, że nie działa. Dostaję oddzielny zestaw ustawień dla każdego projektu:/ – Patrick
Opcja C działa dla mnie jak urok. –