2011-12-19 17 views
5

Pracuję nad projektem, a gdy go urósł, zdaję sobie sprawę, że dwie części, których nie można połączyć, są wzajemnie zależne.csc.exe i zespoły współzależne

Nazwijmy te dwie części: a.exe i b.dll. b.dll zapewnia implementację, która pozwala programowi a.exe na pobieranie danych, ale chcę, aby był on samodzielnym zestawem, dzięki czemu można go łatwo zmienić, aby plik a.exe komunikował się z różnymi źródłami danych.

Jednak podczas gdy do odniesienia do pliku b.dll wymagany jest plik a.exe, plik b.dll wymaga kilku funkcji, które są nieodłączną częścią pliku a.exe.

Odkąd kompilowałem - aby przetestować - jak pisałem ten projekt, oba pliki a.exe i b.dll istnieją i mogę skompilować plik b.dll z a.exe i a.exe przeciwko b.dll, ale w jaki sposób/mógłbym kiedykolwiek odbudować oba te źródła?

+0

W jaki sposób nie otrzymałeś błędu zależności cyklicznej od Visual Studio? – Oded

+0

@Oded Używa kompilacji wiersza poleceń - możesz ją iteracyjnie budować i tworzyć zależności cykliczne - ale sprawia, że ​​nigdy nie będziesz mógł przeprowadzić czystej odbudowy (bez ekstremalnych trudności). –

+0

@ReedCopsey - Myślałem, że może to robić, ale chciałem potwierdzenia z OP. Jak już powiedziałeś, w tym scenariuszu czysta kompilacja jest niemożliwa. – Oded

Odpowiedz

2

Invoke csc.exe, kompilacji źródła dla a.exe i b.dll do pliku a.exe, wywołaj csc.exe, co mpile źródło b.dll do b.dll i odniesienie do a.exe, a następnie wywołaj csc.exe po raz ostatni, skompiluj źródło dla a.exe w pliku a.exe i odniesienie b.dll.

4

Ogólnie rzecz biorąc, byłoby dobrym pomysłem, aby to zmienić i przenieść współdzielone zależności do ich własnego zespołu (c.dll). W ten sposób zarówno plik a.exe, jak i plik b.dll mogą odwoływać się do pliku c.dll, a także uniknąć tej zależności cyklicznej.

+0

Jeśli jednak to zrobiłem, w tej sytuacji mogę sobie tylko wyobrazić to c.dll byłoby zależne od a.exe i b.dll. Funkcji nie można prawidłowo oddzielić od kodu w pliku b.dll i a.exe. –

+1

@RobertAllanHenniganLeahy Twoim celem powinno być oddzielenie tego. Spróbuj zaprojektować interfejs API, aby go odłączyć. Nie ma powodu, aby wszystkie typy były od siebie zależne. Zawsze można zdefiniować interfejs w pliku c.dll, który jest uruchamiany przez a.exe lub b.dll w celu zapewnienia funkcjonalności lub korzystania z delegatów, itp. Takie zależne zależności zawsze można obejść ... –

+0

Wydaje mi się, że nie widzę należy unikać współzależności tylko w celu jej uniknięcia, zwłaszcza gdy proponowane metody potencjalnie zwiększają złożoność i rozmiar oraz potencjalnie obniżają wydajność. Pomyślałem jednak o łatwym przejściu poza ten problem - wywołaj csc.exe, skompiluj źródło plików.exe i b.dll do pliku a.exe, wywołaj csc.exe, skompiluj źródło dla pliku b.dll w pliku b.dll i odniesienie do pliku a.exe, a następnie wywołaj polecenie csc.exe po raz ostatni, skompiluj źródło pliku a.exe w pliku a.exe i odwołaj się do pliku b.dll. –

5

chciałbym byłaby systemu na trzy zespoły:

  • a.exe - Główne EXE nic nie powinno odwoływać się do tego
  • b.dll - Jak masz go dzisiaj, ale nie odwołać a.exe, odwołuje C.dll
  • C.dll - powinno zawierać wspólne części/elementów, które zarówno a i b muszą odnosić
+0

b.dll zawiera tylko jedną klasę - nazwijmy to DataSource - a.exe zawiera bibliotekę klas, ale jedyną wymaganą przez b.dll jest klasa o nazwie Server, która jest głównym składnikiem pliku a.exe . –

Powiązane problemy