Блокировка перекрестного процесса в С#

Я написал API, который будет использоваться в том же поле в (1) службе Windows, (2) веб-приложении и (3) приложении Windows Forms. Все они должны делиться очень небольшим набором общих данных (несколько ints, дата и строка, которую я мог бы добавить как свойства одного класса).

Каким механизмом блокировки я могу использовать кросс-процесс, чтобы три процесса могли безопасно делиться ресурсами и не запускаться в конфликты?

Нет баз данных, пожалуйста, ищите решение, которое не требует дополнительных зависимостей. Предпочтительно, решение будет использовать разделяемую память или файловую систему каким-либо образом.

Ответы

Ответ 2

Используйте объект EventWaitHandle для создания именованного события, которое каждый процесс может заблокировать или заблокировать. Работает в .NET 2.0 и более поздних версиях.

Ответ 3

Основываясь на вашем вопросе, это похоже на то, что вам нужно, это перекрестное общение. Таким образом, один из процессов содержит общие данные, а другим процессам необходимо получить доступ к этим данным.

Если это правильно, вы можете использовать простую блокировку процесса, например Монитор, для защиты общих данных и предоставления конечной точки WCF для обеспечения доступа к данным из другого процесса. Использование транспорта Named Pipe для обмена WCf будет очень эффективным для связи между процессами в одном и том же поле.

Не нужно было бы блокировать перекрестный процесс, если вы не использовали общий ресурс, такой как файл с отображением памяти, для совместного использования данных, но, честно говоря, это было бы громоздким и потребовало бы, чтобы вы обрабатывали многие вещи вручную, что WCF будет заботиться с тем преимуществом, которое вы могли бы в конечном итоге масштабировать в одном ящике до нескольких ящиков, если вам когда-либо понадобилось.

Ответ 4

Если все ваше приложение будет находиться на одной машине, вы можете использовать примитивы синхронизации между процессами, такие как именованные мьютексы и разделяемая память.

Но я думаю, что гораздо лучший подход - использовать что-то вроде служб WCF (которые могут находиться в службе Windows) и предоставлять всю необходимую информацию через указанный контракт. В этом случае все это приложение может находиться на разных машинах, но в любом случае это решение более чистое и надежное.

Ответ 5

Вы можете использовать MSMQ для предоставления общих очередей между вашими приложениями, причем одно из приложений действует как ведущий; служба Windows будет лучшим выбором, если она всегда работает.

Я использую System.Data.Sqlite для связи между службами и приложениями Windows. Даже если вы не сказали никаких баз данных, вы можете найти этот достойный компромисс. Это встроенная база данных без нагрузки администратора. Вы "отправляете" его, включая одну DLL в своих приложениях, и сохраняет ваши данные в одном файле.

Подумайте об этом как о постоянном файле, доступ к которому вы используете с помощью SQL-инструкций через ADO.Net; он даже имеет интерфейс LINQ. Вы получаете блокировку через стандартные транзакции (с откатом), а также шифрование. Вы можете изменять и просматривать его содержимое с помощью Visual Studio Service Explorer. Он работает на .Net 3.5 и .Net 4. И это с открытым исходным кодом без ограничений. Вы можете добавлять столбцы и таблицы без нарушения существующей функциональности. Поскольку развертывание так же просто, как добавление библиотеки DLL в решение, ее гораздо проще развертывать и поддерживать. А поскольку строка подключения указывает на файл, это позволяет легко удалять его с удаленных компьютеров. Возможно, это не так элегантно, как общие очереди или мьютексы, но его значительно упрощенные вещи для меня.