Роман Безруков, есть альтернатива: не перевыпускать сертификат, а добавить имя DNS из него в файл hosts (%SystemRoot%\system32\drivers\etc\hosts , без расширения, если нет - создать такой файл, можно для этого скопировать hosts.sam из той же папки): нужно добавить строчку 127.0.0.1 имя-DNS-из-сертификата
IMHO так проще. А кроме того, это имя еще может быть прописано в проекте и обращение https://localhost/ может не сработать
CityzenUNDEAD, см. мой предыдущий комментарий плюс мой свежий ответ к вашему предыдущему вопросу.
Это, конечно, не ответ, но, надеюсь, это наведет вас на решение.
Василий Банников, похоже, автор вопроса пытается дальше решать свою предыдущую задачу. К сожалению, он ее целиком не огласил, потому только после этого вопроса, увидев в нем IQueriable, я осознал, что ему надо эту задачу решить для данных из БД, и это меняет дело - у многих БД есть для этого специальный механизм - recursive CTE. И это я написал в том запросе.
Другое дело, что EF с LINQ, через которые он, кажется (но это неточно - автор скуп на подробности) пытается решать задачу, средсдств для использования recursive CTE, кажется, не предоставляют, и нужно писать и как-то подключать SQL-запрос самому.
В перечисленных вами случаях обойтись-то как раз можно:
- используйте тип Зависимость? вместо Зависимость
- используйте тип IEnumerable<Зависимость> вместо Зависимость и выбирайте нужную
- используйте IOptionsSnapshot<Зависимость>: объект зависимости будет создаваться в момент обращения и жить только в рамках ограниченной области (т.е., по-простому - во время обработки одного запроса).
Но места, где без Service Locator не обойтись, таки есть: либо они лежат вне области применимости фреймворков, либо (зачастую) там, где не получается что-то сделать чисто через конструктор и требуется передать делегат.
Но, таки да, теоретики говорят, что Dependency Injection - хорошо, Service Locator - плохо. Правда, потом может случиться, как с "четыре" и "две" - вместо "плохо" станет "лучше". К примеру, на моей памяти с комментариями так и случилось.
solarkaaa, нет, не завершится: в Windows запускающий процесс никоим образом не владеет запускаемым, и ссылка на него в структуре данных, связанной с процессом - чисто информационная.
Об этом можно прочитать в книге Windows Internals. У нее есть несколько изданий и есть их русские переводы "Внутреннее устройство Microsoft Windows". В русском переводе 6-го издания про это написано на стр.22.
Вы через редактор локальной политики (gpedit.msc) смотрите, наверное - т.е. в оснастке Group Policy Object Editor, нацеленной на локальный компьютер? Так там показываютсят (и меняются) настройки из объекта локальной политики, а настроки результирующей политики не показываются (ЕМНИП, раньше в Win2K показывались, но с тех пор много воды утекло).
А настройки результирующей политики в аналогичном виде можно увидеть в консоли rsop.msc (в оснастке Resultant Set of Policy.
Drno, ага, вы вспомнили правильное слово. Чего бы вам раньше было его не вспомнить, до того, как отвечать? Или вы были не в курсе, что эта функциональность часто встраивается в почтовые сервера?
В любом случае, ваш ответ вводит людей в заблуждение, а это нехорошо.
Вы знаете недостаточно. Например, в MS Exchange возможность перенаправления сообщений для конкретных получателей на другой (другого типа) сервер - это штатная возможность (делается с помощью почтового домена внутренней ретрансляции и контактов для этих конкретных получателей). В древнем sendmail это тоже делается - через alias в sendmail.cf. То же можно сделать в и чуть менее друвнем MDaemon. Это - те решения, которые я реально делал.
А так, подозреваю, эта функциональность есть во множестве других почтовых серверов.
Игнат Соколов, нет, надо писать e:Имя_файла.cs. Да ещё, возможно, и полный путь до нужного каталога от корня диска E: придётся добавить - если у вас текущий каталог для диска E: - другой (Windows, соблюдая традиции DOS, хранит текущий каталог для каждого диска).
Ну, или перед запуском команды переходите в нужный каталог.
Клиенты и MX - это две разницы. MX - это про доставку почты в конкретный домен, а клиентам надо отправлять почту, причем - во все домены. Поэтому клиенты на MX-записи обычно не смотрят: у них есть свои настройки, указывающие на почтовый сервер, который будет заниматься маршрутизацией почты (разве что, при своей автонастройке посмотреть могут).
Не распространяйте заблуждения.
1. Windows уже давным-давно умеет скрывать недоступные общие папки целиком и отдельные папки внутри общих папок (называется это access- based enumeration)
2. Общая папка с парольным доступом здесь неуместна, потому что речь идет уже о доступе разных пользователей.
Короче, прежде чем давать советы, учите матчасть.
Правильный вопрос, как известно, содержит половину ответа. А ваш вопрос ее не содержит. Например, вы не указали значение чего надо вытащить - хотя бы на уровне того, где вы его видите (на экране, в файле и т.п.).
Пожалуйста, дополните ваш вопрос этой и другими подробностями, которые вам могут показаться нужными.
Иначе нам тут придется дожидаться телепата, который прочитает нужные для ответа данные прямо в вашем мозгу, или ясновидящего, который сможет увидеть их в своем хрустальном шаре.
PS Мой комментарий такой язвительный по форме потому, что мне показалось, что вы даже не взяли на себя труд подумать над вопросом, а решили напрячь сообщество, не напрягаясь сами. Если я ошибаюсь, то приношу свои извинения за форму. Но содержания это не отменяет: для ответа на ваш вопрос данных недостаточно.
Дык, я разве про учетные записи пользователей писал? Я писал про учетные записи компьютеров - надеюсь, разницу понимаете?
Но вообще-то, мне чисто для себя хочется поинтересоваться, про какие ключи вы тут пишете: с этого места, пожалуйста, поподробнее - если можете, конечно.
PS А если в целом, то при восстановлении КД в сущестующую и функциоирующую AD все обновления содержимого БД AD реплицируются на восстановленный КД, и любые ключи в этой БД будут ровно те же. Но чтобы это произошло, КД долже быть способен аутентифицироваться на другом КД для репликации, и тут как раз вступает в действие срок жизни пароля: если он истек и был поменян после резервного копирования, то будут проблемы (впрочем, решаемые - этот пароль сбросить и переустановить можно, процедура в документации описана).
Drno, а зачем вообще какие-то ещё (опенсорсные или нет) сторонние решения, когда есть решение, уже входящиев состав ОС - не задумывались, а?
В частности, комерческие же решения нужны, чтобы снизить трудозатраты на функционирование информационной системы. Именно за это снижение трудозатрат предприятия готовы платить деньги их производителям.
Но я писал не об этом, а о том, что использование решений для резервного копирования, не поддерживающих AD специально, может просто нанести вред. Вы за предложенные вами решения готовы отвечать, что они AD поддерживают? Или вам главное, что они идеологически правильные - опенсорсные.
Под "ключами шифрования", если я правильно понял, имеются в виду пароли учетных записей компьютеров домена. Они, да, переоически меняются (по умолчанию - раз в 30 дней), впрочем AD всегда хранит и предыдущую копию. Но по истечении 30 дней может потребоваться сбрасывать паролиучетных записей компьютеров (особенно - восстанавливаемого КД),. Кроме того, в AD есть и другие ограничители времени: время годности данных DFSR (для репликации SYSVOL), по умолчанию - 90 дней (если его в последних версиях не поменяли), и время жизни захороненных (удаленных) объектов в базе AD, по умолчанию - 180 дней.
Так что нельзя просто так вязть и сделать один раз резервную копию AD и на этом успокоиться. Резервную копию нужно делать регулярно, не реже чем раз в месяц.
Ваш совет - вредный, годится только для сетей с ровно одним контроллером домена. Потому что база AD - распределенная, ее узел нельзя просто так взять и скопировать, а вотом восстановить. Почему так - ищите и читайте материалы на тему "USN rollback".
PS Не нравится встроенное средство архивации Windows - используйте коммерческое решение. Только деньги за него заплатите ;-).
Что именно вы делали перед тем, как прийти к такому выводу?
PS portproxy - это не NAT.