2015-12-10 18 views
1

У меня есть два проекта: P1 и P2.Ссылка в двух проектах

P1 имеет Ссылка из P2.

поэтому я могу получить доступ P2's methods от P1. Но что, если я хочу получить доступ к P1's methods от P2, то как я могу получить к ним доступ?

Я знаю, что не могу добавить P1's ссылку в P2?

Если это возможно? Если да, то как?

+3

Вы не можете просто создать ссылку, вы правы. Там _might_ будет способом использования отражения или чего-то другого, но разумным способом является просто переместить общую логику в третий проект P3 и ссылку P3 из P1 и P2. –

ответ

3

Как указывали другие, круговые ссылки являются проблемой. Он не может скомпилировать P2 до того, как он скомпилировал P1, но если P1 зависит от P2, он не может скомпилировать P1 до тех пор, пока P2 не будет скомпилирован ... У вас проблема?

Теперь решения:

  • легкий путь: Создать разделяемую библиотеку, где вы положили в вашем общем коде P1 и P2. На этот общий проект можно ссылаться как на P1, так и на P2.

  • Лучшее решение: создайте интерфейс, который вы определяете в общей библиотеке. Основывайте свои «ссылки» на P2 в P1 на общем интерфейсе, а не на фактическую реализацию. Таким образом, у вас есть лучшее тестовое решение, и проще заменить части вашего кода.

+1

хорошо объяснил :) –

2

Короткий ответ: нет способа добавить P1 в качестве ссылки в проекте P2, поскольку это создаст циклическую зависимость, которая не допускается. Рассмотрим рефакторинг вашего кода и разработку приложения по-другому. Один из способов - представить еще один проект, содержащий ссылки на оба проекта.

1

Вы не можете ссылаться на P1 из P2, потому что это создаст циклическую зависимость. Круговая зависимость указывает на плохой дизайн. Из этого выходят пути, например, вы можете реорганизовать общий код в другой проект.

3

Другой способ добиться этого, чтобы иметь P1 ссылочный P2 в качестве проекта решения, но имеют ссылочный P2 P1 только его выходной DLL или EXE.

Вы теряете проверку кросс-проекта/зависимостей, но это позволяет вам перекрестно ссылаться.

Я должен был сделать это с помощью долговременного приложения WinForms, которое изначально было написано на VB, но через несколько лет перешло на C#. Все новые Windows Forms были написаны на C#, который не мог быть тем же проектом, что и формы VB, но некоторые формы VB, необходимые для вызова новых форм C# и Vice verca.

EDIT 1

Одним из недостатков является то, что, если P2 ссылается P1, как это проект вывода DLL/EXE, а затем, когда вы очищаете/восстановить решение, там ошибка, вы находитесь в положении, в котором вывод DLL/EXE больше не существует и не может быть воссоздан до устранения ошибки, но решение больше не может быть построено, так как у него отсутствует ссылка.Нехорошее место быть, поэтому не забудьте периодически копировать свою выходную DLL/EXE, чтобы вы могли выйти из этого, если это когда-нибудь случится.

+0

ohh .. Я определенно попробую этот подход –

+0

Двунаправленно соединяя две сборки вместе, вы сделали это так, чтобы сборки никогда не работали друг с другом (теряя возможность повторного использования кода), но альтернатива заключается в дублировании логики (нарушение DRY), если вы хотите поделиться чем-то вроде ведения журнала (и отображения информации о состоянии) между приложением и DLL. Концептуально, например, dll не должно зависеть от приложения, использующего его, но, с другой стороны, наличие двух отдельных файлов журналов делает менее понятным, что «выполнение X в приложении вызвало Y в DLL». – jrh

+0

... в коде C/C++, который я видел, такого рода цепочку не всегда можно избежать, и это не так уж редко, это может быть просто связано с тем, почему вы сделали отдельную DLL, в первую очередь, IIRC Quake 3 сделал что-то подобное для связи между его (сменными) компонентами двигателя. – jrh