Подозреваю, что процесс-производитель успел закончиться и закрыть семафор, прежде чем второй к нему обратился. Потому что ничто не мешает ему это сделать. Чтобы можно было понаблюдать процесс синхронизации глазами - воткните вызовы Sleep между захватом и освобождением семафора.
PS Создание и закртытие файла с результатом следует поместить между захватом и освобождением семафора, иначе у вас семафор от конфликтов при работе с файлом не защищает.
PPS Вообще-то, для подобных задач обычно используются мьютексы (их ещё иногда называют "двоичные семафоры": видел такое название в старых книгах). Но если преподаватель велел использовать семафоры на ресурс в количестве 1 - таки придется использовать семафоры: логика работы будет та же самая, а скорость в учебном примере не важна.
2. Запускать mstsc с ключом /f (он же /fullscreen) не пробовали?
А еще в команде mstsc можно указать файл первым параметром подключения (RDP-файл), в котором может быть сохранено имя пользователя (насчет пароля - не помню уже, но, кажется, он умеет брать пароль из сохраненнных в системе паролей).
Это да: переменная (ссылочного типа) - это ссылка на экземпляр объекта.
Но при таком понимании переменную "объявляют" (и это во время выполнения практически бесплатно), а "создают" - экземпляр (а вот это таки небесплатно, так как напрягает распределитель памяти) . Я решил, что автор имел в виду второй вариант, потому как не хотел "создавать" что-то там, а потому ответил именно так. Но, возможно, я ошибся в понимании намерений автора.
Kaminasta, мне вряд ли от этого будет легче, потому что телеграмными ботами я не занимался и заниматься не собираюсь. Я тут отвечал чисто на более частный вопрос про то, откуда взялась ошибка.
А в рамках этого вопроса я вижу, что свойство CallbackQuery есть лишь у объекта типа Update (передаваемого как параметр в HandleCallbackAsync) , а не у TelegramBotClient - и это ответ, почему вам выдается такое сообщение об ошибке. То есть, вы просто пытались привязать клавиатуру не в том месте и не в то время, да ещё и к переменной не того типа.
Ну, а ответ на более общий вопрос - как привязывать кнопку в том месте, в то время и к какой переменной - ищите сами (поэтому я и пишу комментарий, а не ответ). Мой очень беглый поиск в интернете вывел меня на вариант привязки через свойство ReplyMarkup объекта (его тип смотреть лень), возвращаемого методом SendMessage. Может быть, вам это поможет. А может - и нет, не знаю.
Вам же написали черным по-русски: нет у вашего bot, нам неведомого (в отрывках кода его нет), но имеющего тип TelegramBotClient метода/свойства/события с именем CallbackQuery.
Вот и ищите в описании той билиотеки (нам опять-таки неведомой - телепатов на этой неделе не ожидается) описание этого типа, и какие свойства он имеет. Хотя бы - посмотрите в IDE какие методы/свойства/события есть у этого класса: хорошие IDE это умеют, например Visual Studio показывает это по F12.
Подсказка: нужную вам функцию может реализовывать не единственная билиотека, и вы, похоже, подсмотрели в интернетах подсказку не под ту библиотеку или не под ту версию. А какая у вас библиотека/версия - это нам, не владеющим телепатией и ясновидением, опять-таки не ясно. Поэтому рекомендуется всегда указывать это информацию в вопросе, если используется что-то, кроме стандартных средств .NET
Вадим, из опыта и из общего понимания, как работают ссылки: они импортируют метаданные(информацию о типах и т.п.) из таблицы экспорта сборки (dll, или, в случае .NET Framework - на exe), а в этой таблице содержатся метаданные только для того, что входит в состав этой сборки, метаданных об импортируемых сущностях там нет.
Читал я об этом ещё в книгах по изначальному .NET Framework, но не вижу, что в .NET Core что-то поменялось (тем более, что поддержка пакетов и в .NET Framework была добавлена)
Во-первых, ваша цитата не имеет отношения к вопросу: в ней речь идет о контроллере домена в AD, а не о сервере куда ставится Exchange (ставить его на контроллер домена MS крайне не рекомедует - в такой схеме там есть очень неприятные нюансы).
Во-вторых, а не могли бы вы воздержаться от демонстрации ваших предпочтений и просто ответить на вопрос - не первым попавшимся ответом из поиска, а цитатой из системных требований для сервера Exchange? А то в таком виде из вашего ответа невозможно извлечь пользу.
tits, роль репликации DNS устанавливать не надо: та связанная с репликацией DFS часть, которая требуется для репликации SYSVOL, входит и в состав роли AD Directory Services. Что может окзаться полезным (не в вашем случае - у вас репликация не используется - а вообще) - так это установить средства упраления ролью DFS: нам есть кое-что, что может быть полезным и для контроля/починки репликации SYSVOL.
Ой, а как же наш сертификат? А он в тыкву, понимаете, превратился...
Не порите чушь - ей больно. Для проверки подписи закрытый кюч не нужен, от слова "совсем". А для создания новых подписей просто создается новый сертификат. У пользователя, понимаете ли, сертификатов может быть несколько - и в соотвествующем атрибуте в AD это учтено: он - многозначный. Для восстановления ключей шифрования в AD CS (это - название для инфраструктуры PKI на базе Windows) централизованный механизм тоже есть, я про него написал выше. И в давние времена - примерно те же, когда Vadims Podans писал про PKI - я его использовал, для реализации S/MIME в связке Exchange/Outlook. Да, восстановить ключ без помощи администратора было непросто (это делалось с командной строки через cerutil), но механизм был и работал.
Но том применении, которое нужно автору вопроса шифрование (и как следствие - восстановление ключей) не требуется.
PS Вообще-то, стандартно в Windows для решения задачи автора есть AD Rights Management Services, но что-то мне подсказывает, что MS не стала заморачиваться созданием клиентов для сторонних систем, так что это решение до сих пор годится только для сетей чисто на базе Windows, и в наше время наличия большого числа мобильных клиентов мало кому подойдет. Поэтому я про нее в ответе даже не упоминал.
PPS
Есть предположение, что Вы и про Windows знаете ровно столько же и оснастки CA никогда живьем не видели.
Вы таки ошибаетесь. Но к сути вопроса этот ваш argumentum ad personam отношения не имеет, так что подробности опускаю. Короче, завязывайте троллить.
CityCat4, ещё раз повторяю: "вы просто не умеете их готовить".
Подпись старым сертификатом проверяется его публичным ключом, содержащемся в сертификате.
Эти публичные ключи содержатся в самих сертификатах. И хранятся, как минимум, на выпускающем CA и вполне доступны через его API. Кроме того, сертификаты пользователя по умолчанию публикуются в AD (там есть для этого специальный атрибут в стандартной схеме, начиная с Win2K3). Где ещё хранятся сертификаты - это зависит от ПО, используемого для создания подписи. Например, в некоторых вариантах септификат может быть встроен в сам подписанный документ (не знаю, правда, возможно ли такое в формате PDF). Ну, а сертификат выпускающего CA, чтобы эти старые сертификат было проверить, тоже нужно хранить где-то ещё. По умолчанию он тоже хранится в AD. Однако для работы со сторонними клиентами, про AD не знающими, он обычно хранится ещё и на веб-ресурсе, URL которого указан в расширении(т.е. поле) AIA выпущенных сертификатов. Но этот URL надо дополнительно указать в настройках CA А вот URL сертификата CA в AD там есть по умолчанию.
Закрытого ключа сертификата на CA может и не быть. И вообще-то, для большинства применений он просто вообще не должен передаваться на CA. Потому что иначе в случае компроментации CA компроментируются все цифровые подписи документов.
Есть правда вариант применения, когда требуется восстановление закрытого ключа - для получения доступа к зашифрованным документам. Такая функция в CA дя Windows тоже есть, и для ее реализации закрытый ключ, естественно, передается. Но он всегда и передается, и хранится в зашифрованном виде, причем, при хранении - шифруется ключом, которого на CA нет. Но для сертификатов, используемых для подписи, требование восстанавливать закрытый ключ - излишнее.
А BitLocker тоже не так страшен, если уметь его готовить. Там на случай аварии можно настроить, к примеру, пароль восстановления, и даже - сохранять информацию для восстановления доступа к диску в AD.
Короче, завязывайте тут с демонстрацией эффекта Даннинга-Крюгера. Я вот, к примеру, не знаю, чем и как реализуются решения тех же самых задач на Linux - вот и не высказываюсь про него. Если вы знаете - опишите вкратце (или дайте ссылки на описание), автору вопроса это может пригодиться. Решение все равно выбирать и реализовывать ему, не нам с вами.
"Вы просто не умеете их готовить". Для CA в AD можно настроить шаблоны сертификатов (многие нужные уже есть) с автоматической или ручной выдачей сертификатов по шаблонами автоматическую подачу заявок на сертификаты.
Для подписи документов нужнj по минимому всего лишь наличие бита digitalSignature в атрибуте KeyUsage (в интерфейсе обычно называется как-то типа "Цифровая подпись" для атрибута "Использование ключа". А нужно ли что-то специфическое в атрибуте EKU - это пот программы зависит. Например, сертификаты для веб-сервера с HTTPS отлично воспринимаются браузерами без EKU вообще.
Короче, автору, скорее всего, подойдет стандартный шаблон Пользователь (User). И для него вполне можно настроить автоподачу заявки. Насколько я знаю, в этом мало что поменялось со времен Win2K3, так что до сих пор можно пользоваться рекомендациями от Vadims Podans
В самом начале загрузки можно перейти в меню (раньше это была клавиша F8) выбрать режим загрузки с протоколированием. В этом режиме на экран пишутся имена драйверов. Попробуйте загрузиться в этом режиме и посмотреть, где именно сбивается загрузка.
makaron710, во-первых, в каких условиях должен работать но не работает скрипт: с командной строки или в планировщике ("Назначенные задания")?
Во-вторых, попроб1уте поставить перед именем скрипта команду, которая его выполняет: для работы в консоли используйте cscript.exe (есть ещё wscript.exe, с работой в окне)