Дистанционная работа или WCF для новой разработки (между двумя приложениями.NET на той же машине) использующие интерфейсы?

WCF - это то, что вам нужно, особенно проверьте привязку Net Named Pipe к WCF. Это обеспечит очень быстрое межпроцессное взаимодействие на одном компьютере.

Если вы ориентируетесь на Windows Server 2008 для производственного развертывания, вы можете использовать IIS 7 в качестве среды размещения. Ознакомьтесь с Расширьте свои службы WCF за пределы HTTP с помощью WAS .

Существует много информации о типах для начала работы с WCF. Ознакомьтесь с:

• Начало работы с WCF Tutorial
• WCF Essentials

Если у вас возникли проблемы с началом работы, опубликуйте любые конкретные ошибки или примеры, вы могли бы продемонстрировать это, и я уверен, что кто-то здесь может помочь!

Использовались оба.

Однозначно пойти с WCF.

Удаленное взаимодействие плохо документировано и болезненно. По сравнению с WCF намного проще. Не уверен, что у вас возникли проблемы, но существует масса документации по WCF.

Я только что переключил программу с удаленного взаимодействия на WCF и наткнулся на кучу вещей, которые раньше работали без проблем в удаленном взаимодействии, но вызывали проблемы в wcf:

• Класс CallContext - это прошло. Я использовал это для передачи некоторой информации, например, о текущем выбранном языке и некоторой информации о пользователе. В WCF мне пришлось создать MessageInspector, чтобы добавлять заголовки с этой информацией к каждому запросу.
• Исключения больше не передаются без изменений. Вместо этого вам нужно использовать FaultException и FaultContracts.
• Прокси-серверы не кажутся такими легковесными. Мне нужно избавиться от них, а не просто оставлять их для сборки мусора, иначе моя служба зависнет. (На самом деле это не так просто, как вызвать Dispose для правильного завершения прокси-сервера, вам нужна довольно сложная последовательность try, catch, наконец, это вызывает Close и Abort для различных типов исключений.) Необходимость закрытия прокси вызывает небольшую проблему, когда я хочу, чтобы моя инфраструктура IoC управляла прокси.

Я не говорю, что вы должны использовать удаленное взаимодействие, я ' m просто говорю, что есть причины рассмотреть возможность удаленного взаимодействия. Это определенно проще настроить и приступить к работе.

Думаю, вы можете возразить, что я столкнулся с некоторыми из этих проблем только потому, что я не использовал лучшие практики в своей программе удаленного взаимодействия. :-P

Думаю, вы можете возразить, что я столкнулся с некоторыми из этих проблем только потому, что я не использовал лучшие практики в своей программе удаленного взаимодействия. :-P

Думаю, вы можете возразить, что я столкнулся с некоторыми из этих проблем только потому, что я не использовал лучшие практики в своей программе удаленного взаимодействия. :-P

Вот один шаблон для выполнения вещей, подобных удаленному взаимодействию с WCF:

• 3 проекта: сервер, клиент, shared.dll
• сервер и клиент оба ссылаются на shared.dll
• put интерфейс службы с [ServiceContract] в shared.dll
• помещает класс реализации службы на сервер
• не использует интерфейсы для ваших типов данных
• создает простые типы DataContract только с той логикой, которую вы хотите разделять между клиент и сервер (например, проверка)
• поместите ваши типы данных DataContract в shared.dll
• Не используйте NetDataContractSerializer (как вы, кажется, делаете в своем коде)

Конечно, есть вариации на эту тему. Например, вместо общей dll вы можете совместно использовать файлы кода между серверным и клиентским проектами с #if для разной компиляции.