Ибрагим Галимов, ответ я вам оставил, со ссылкой на документацию MS.
А в целом, раз вы совсем новенький - то следовать завету Ильича: учиться, учиться и учиться.
Не разводите паранойю. Динамические библиотеки для C/C++ используются по умолчаниюдля того, чтобы не включать библиотеки времени выполнения - языковую, MFC и пр. - в каждую программу, раздувая тем самым общий объем программ на диске.
Но если ваша пранойя вас таки победила, то собирайте свои программы с билиотеками времени выполнения статически - такая возможность в VS была издавна - и будет вам щастье.
А как это делается в уиндоуз? Подозреваю, что никак!
В Windows разрешения на папку могут наслеловаться файлами и папками внутри этой папки - более того, почти все устанавливыемые через упрощенный интерфейс разрешения на папки - они именно такие, наследуемые.
Но стандартная схема разрешений в *nix (owner/group/world) - она очень не похожа на схему разрешений Windows (на основе ACL), так что нет особо смысла спрашивать "как там в Windows" для ответа на исходный вопрос .
Что, 20 непустых строк вместо 19 - это теперь называется "попроще"?
PS. В решение так и просятся шаблонные строки (а то и шаблонные функции). Но JS - это не мой язык, потому так сразу не напишу
Подозреваю, что процесс-производитель успел закончиться и закрыть семафор, прежде чем второй к нему обратился. Потому что ничто не мешает ему это сделать. Чтобы можно было понаблюдать процесс синхронизации глазами - воткните вызовы 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 - вот и не высказываюсь про него. Если вы знаете - опишите вкратце (или дайте ссылки на описание), автору вопроса это может пригодиться. Решение все равно выбирать и реализовывать ему, не нам с вами.
А в целом, раз вы совсем новенький - то следовать завету Ильича: учиться, учиться и учиться.