.net — Проверка работоспособности Net Framework
Подскажите, пожалуйста, способ(ы) проверки наличия в системе установленных версий .NET Framework, и какой-либо надежный способ(ы) проверки их корректного функционирования.
В частности, пока очень нужна проверка версии 2.0 для Windows10-x64.
Пока в сети нашел несколько примеров на VBS (типа этого), но тестами их назвать сложно — там простая проверка ключей реестра. Хотелось бы чего-то более существенного.
О «более существенной» проверке
Нужна программа, которая последовательно делает вызовы из .NET (в соответствии с версиями), и если по каким-то причинам вызовы завершаются ошибкой — это должно отображаться в результатах.
Простой пример. .NET 3.5 установлен, но одна из динамических библиотек была удалена — пусть работа вируса, к примеру. По факту и каталоги есть, и в реестре все прописано — но работоспособность нарушена. Вот эту проверку я называю «более существенной».
Сам Microsoft рекомендует (по крайней мере про это статья на MSDN есть), как один из вариантов, смотреть в реестре.
To find .NET Framework versions by viewing the registry (.NET Framework 1-4)
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP
To find .NET Framework versions by viewing the registry (.NET Framework 4.5 and later)
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full
можно это проверять или через regedit.exe или через cmd, к примеру
reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP" | findstr "v2.0*"
выдаст:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v2.0.50727
Ну или через код, как в вашем варианте или как в статье с MSDN описано
UPD
Сборки лежат в GAC по пути %windir%\assembly для .
NET < 4. Можно пытаться их проверять по наименованию, например. Но зачем?
Вручную проверку можно выполнить с помощью утилиты netfx_setupverifier от MS. Правда, лично я, искал консольную утилиту для реализации автоматической проверки.
Зарегистрируйтесь или войдите
Регистрация через Facebook
Регистрация через почту
Отправить без регистрации
Почта
Необходима, но никому не показывается
Отправить без регистрации
Почта
Необходима, но никому не показывается
Нажимая на кнопку «Отправить ответ», вы соглашаетесь с нашими пользовательским соглашением, политикой конфиденциальности и политикой о куки
ASP.
NET Core и C# | Полное руководство ASP.NET Core и C# | Полное руководствоПоследнее обновление: 02.12.2022
Глава 1. Введение в ASP.NET Core
Что такое ASP.NET Core
Первое приложение на ASP.NET Core с .NET CLI
Первое приложение в Visual Studio
Глава 2. Основы в ASP.NET Core
Создание и запуск приложения. WebApplication и WebApplicationBuilder
Конвейер обработки запроса и middleware
Метод Run и определение терминального middleware
HttpResponse. Отправка ответа
HttpRequest. Получение данных запроса
Отправка файлов
Отправка форм
Переадресация
Отправка и получение json
Создание простейшего API
Загрузка файлов на сервер
Метод Use
Создание ветки конвейера.
Метод Map
Классы middleware
Построение конвейера обработки запроса
IWebHostEnvironment и окружение
Глава 3. Dependency Injection
Внедрение зависимостей и IServiceCollection
Создание сервисов
Получение зависимостей
Жизненный цикл зависимостей
Применение сервисов в классах middleware
Scoped-сервисы в singleton-объектах
Множественная регистрация сервисов
Глава 4. Маршрутизация
Конечные точки. Метод Map
Параметры маршрута
Ограничения маршрутов
Создание ограничений маршрутов
Передача зависимостей в конечные точки
Сопоставление запроса с конечной точкой
Сочетание конечных точек с другими middleware
Глава 5.
Статические файлыУстановка каталога статических файлов. UseStaticFiles
Работа со статическими файлами
Глава 6. Конфигурация
Основы конфигурации
Нефайловые провайдеры конфигурации
Конфигурация в файлах JSON, XML и Ini
Конфигурация по умолчанию и объединение конфигураций
Анализ конфигурации
Создание провайдера конфгурации
Проекция конфигурации на классы
Передача конфигурации через IOptions
Глава 7. Логгирование
Ведение лога и ILogger
Фабрика логгера и провайдеры логгирования
Конфигурация и фильтрация логгирования
Создание провайдера логгирования
Глава 8.
Состояние приложения. Куки. СессииHttpContext.Items
Куки
Сессии
Глава 9. Обработка ошибок
Обработка исключений
Обработка ошибок HTTP
Глава 10. Results API
Введение в Results API
Отправка текста и json в Results API
Переадресация в Results API
Отправка статусных кодов в Results API
Отправка файлов в Results API
Определение своего типа IResult
Глава 11. Web API
Пример приложения Web API
Глава 12. Работа с базой данных и Entity Framework
Подключение Entity Framework
Основные операции с данными в Entity Framework Core
Глава 13.
Введение в аутентификацию и авторизацию
Аутентификация с помощью JWT-токенов
Авторизация с помощью JWT-токенов в клиенте JavaScript
Аутентификация с помощью куки
HttpContext.User, ClaimPrincipal и ClaimsIdentity
ClaimPrincipal и объекты Claim
Авторизация по ролям
Авторизация на основе Claims
Создание ограничений для авторизации
Глава 14. CORS и кросс-доменные запросы
Подключение CORS в приложении
Конфигурация CORS
Политики CORS
Глобальная и локальная настройка CORS
Глава 15. URL Rewriting
Введение в URL Rewriting
Правила IIS для URL Rewriting
Применение правил Apache для URL Rewriting
Создание правил URL Rewriting
Глава 16.
Клиентская разработкаБандлинг и минификация
Пакетный менеджер Libman
Пакетный менеджер NPM
Глава 17. Кэширование
Кэширование с помощью MemoryCache
Распределенное кэширование. Redis
Сжатие ответа
Кэширование статических файлов
Глава 18. Мониторинг работоспособности приложения
Health Check Middleware
Статические файлы
Состояние приложения. Куки. Сессии
Клиентская разработкаYooMoney:
410011174743222
Перевод на карту
Номер карты:
4048415020898850
Microsoft Dot Net Framework 4.0 STIG
Обзор
| Версия | Дата | Количество найденных данных (15) | Загрузок9 | 1 | 2017-06-14
| CAT I (высокая): 0 | CAT II (средний): 13 | CAT III (низкий): 2 | Excel | JSON | XML |
|---|---|---|---|---|---|---|---|
07.2012 20| Применимо к системам и приложениям, использующим Фреймворк Microsoft .Net версии 4.0. |
Доступные профили
| Секретные | Общедоступные | Конфиденциальные | ||||||
|---|---|---|---|---|---|---|---|---|
| I — критически важные секретные | I — критически важные общедоступные | I — критически важные секретные | II — критически важные секретные | II — критически важные общественные | —20 III — Административная классификация | III — Административная общественная | III — Административная секретность |
Выводы (MAC III — административный секрет)
| Идентификатор обнаружения | Серьезность | Название | 907 Описание||
|---|---|---|---|---|
| V-30935 | Средний | . NET должен быть настроен для проверять строгие имена в сборках с полным доверием. | Параметр «bypassTrustedAppStrongNames» указывает, включена ли функция обхода, позволяющая избежать проверки строгих имен для сборок с полным доверием. По умолчанию функция обхода включена в… | |
| V-7061 | Средний | Состояние публикации программного обеспечения поставщиков доверия должно быть установлено на 0x23C00. | Операционные системы Microsoft Windows предоставляют функцию под названием Authenticode. Технология Authenticode и лежащие в ее основе механизмы подписи кода обеспечивают структуру для идентификации программного обеспечения… | |
| V-30926 | Medium | .NET CLR должна быть настроена на использование модулей шифрования, утвержденных FIPS. | Шифрование FIPS настраивается с помощью файлов конфигурации .NET. Существует множество файлов конфигурации, влияющих на различные аспекты поведения .Net. Файлы конфигурации . NET описаны ниже.
… | |
| V-30968 | Medium | Доверие должно быть установлено перед включением загрузки удаленного кода в .Net 4. | В .NET Framework версии 3.5 и более ранних версиях, если загружена сборка приложения код/объекты из удаленного расположения, эта сборка будет выполняться частично доверенно с предоставлением разрешений… | |
| V-18395 | Medium | Версии .Net Framework, установленные в системе, должны поддерживаться. | Неподдерживаемое программное обеспечение создает риски и нарушает политику Министерства обороны США. Приложения, использующие неподдерживаемые версии .NET, представляют значительный риск для хоста, сети и анклава в силу… | |
| V-7063 | Medium | Сертификаты разработчика, используемые с условием членства издателя .NET, должны быть одобрены со стороны ИАО. | Сборка .Net будет удовлетворять условию членства издателя, если она подписана цифровым сертификатом Authenticode X. 509v3 издателя программного обеспечения, который может быть проверен операционной системой Windows… Каналы TCP служб должны использовать аутентификацию и шифрование. | Удаленное взаимодействие .NET позволяет создавать широко распространенные приложения. Компоненты приложения могут находиться все на одном компьютере или могут быть разбросаны по всему анклаву. .NET-клиент… |
| V-7070 | Средний | Каналы HTTP служб удаленного взаимодействия должны использовать аутентификацию и шифрование. | Удаленное взаимодействие .NET позволяет создавать широко распространенные приложения. Компоненты приложения могут находиться все на одном компьютере или могут быть разбросаны по всему анклаву. Клиент .NET… | |
| V-31026 | Medium | Должна быть включена трассировка событий для Windows (ETW) для событий Common Language Runtime. | Трассировка событий собирает информацию о приложениях, использующих .NET CLR, и самой . NET CLR. Сюда входит информация, ориентированная на безопасность, такая как Strong Name и Authenticode… | |
| V-7067 | Medium | Ключи шифрования, используемые для условия членства в .NET Strong Name, должны быть защищены. | Условие членства со строгим именем требует, чтобы сборки-члены были определены со строгими именами. Строгое имя состоит из идентификатора сборки, простого текстового имени, номера версии и региональных параметров… | |
| V-30986 | Средний | Программное обеспечение, использующее .Net 4.0, должно быть идентифицировано, а соответствующие средства управления доступом настроены. | С появлением .Net 4.0 платформа .Net больше не настраивает и не применяет политику безопасности для приложений .Net напрямую. Эта задача теперь перенесена на уровень операционной системы, и необходимо создать резервную копию файлов CAS и конфигурации политик. | Успешный план аварийного восстановления требует, чтобы политика CAS и файлы конфигурации политики CAS были идентифицированы и включены в события аварийного резервного копирования и восстановления системы. Документация по… |
| V-7055 | Medium | Цифровые подписи, назначенные сборкам со строгими именами, должны быть проверены. | Строгое имя состоит из идентификатора сборки, простого текстового имени, номера версии и сведений о региональных параметрах (если они предоставлены), а также открытого ключа и цифровой подписи. Сильные имена служат для… | |
| V-30937 | Низкий | Приложения .Net, вызывающие NetFx40_LegacySecurityPolicy, должны применять предыдущие версии руководства .NET STIG. | Политика CAS зависит от версии среды выполнения .NET. Однако в .NET Framework версии 4 политика CAS по умолчанию отключена; его можно повторно включить с помощью параметра NetFx40_LegacySecurityPolicy на… | |
| V-30972 | Низкий | Параметры прокси-сервера .NET по умолчанию должны быть проверены и утверждены. | Платформу .Net можно настроить для использования другого прокси-сервера или полного обхода настроек прокси-сервера по умолчанию в браузере клиента. Это может привести к тому, что фреймворк использует прокси, которого нет… |
Зачем и как обновлять Microsoft .NET Framework до последней версии
Практически у каждого человека есть смартфон и он не представляет, как им живется было бы, если бы им пришлось вернуться, используя старый небьющийся Nokia 1310. И это потому, что они могут делать почти все, поскольку существуют тысячи приложений. И каждый день новые обновления доступны для большинства доступных приложений. Эти обновления включают исправления ошибок, исправления безопасности и, самое главное, новые функции. Пользователи смартфонов без колебаний устанавливают эти обновления, зная, что они призваны помочь им еще больше. Так почему же мы, разработчики, не должны делать то же самое, когда выходит новое обновление для программной среды и для инструментов, которые мы используем для разработки определенного приложения?
Обновление фреймворка включает в себя множество полезных функций, таких как удаление ошибок, обнаруженных в предыдущих версиях, исправление недостатков безопасности, повышение производительности и новые функции, облегчающие процесс разработки.
Установка последней версии Visual Studio, которая поставляется с последними версиями .NET Framework и .NET Core, недостаточна, необходимо внести некоторые изменения в проекты, а также для поддержки новейших функций, поставляемых с платформой.
В этой статье основное внимание будет уделено обновлению .NET Framework с версии 4.6.1 до 4.7.2 и всем шагам, которые необходимо выполнить, чтобы убедиться, что приложение по-прежнему работает должным образом после развертывания этого изменения.
Изменение целевой платформы проектов
В большинстве случаев все проекты необходимо обновить до желаемой целевой платформы, но в некоторых случаях некоторые проекты невозможно (легко) обновить до желаемой целевой платформы, поскольку это может эталонные пакеты, которые еще не поддерживаются последней версией .NET Framework.
Чтобы обновить целевую платформу для всех проектов, щелкните правой кнопкой мыши проект (по одному), щелкните свойства и на вкладке «Приложение» измените целевую платформу на нужную, как показано на следующем снимке экрана, и выберите «Да».
” во всплывающем окне, которое отображается после изменения фреймворка.
Перенацеливание пакетов
Простое задание версии .NET Framework, как описано выше, не приводит к обновлению целевой платформы упомянутых пакетов для соответствующего проекта.
Для этого откройте консоль диспетчера пакетов и выполните следующую команду:
PM> Update-Package -Reinstall
Это заставит диспетчер пакетов переустанавливать каждый пакет в каждом проекте без изменения версии целевого пакета, на который указывает ссылка. .NET Framework, выбранный для соответствующего проекта. Иногда это работает не так, как ожидалось, и его нужно запускать вручную. Этого можно добиться, выполнив следующую команду для каждого проекта:
PM> Update-Package -Reinstall -ProjectName Project.Name.Here
Исправление возможных ошибок сборки
После выполнения первых двух шагов вы можете собрать свое решение (Ctrl + Shift + B), а затем запустить приложение для уверен, что все работает нормально.
Мы столкнулись с некоторыми ошибками, которые нам нужно было исправить, чтобы решение было построено и запущено.
Первая ошибка заключалась в том, что у определенного пакета были установлены две версии (в нашем случае это System.Net.Http), и это потому, что текущая версия не была совместима с последней версией .NET Framework, поэтому была установлена более новая версия. Это можно легко исправить, удалив ссылку на более старую версию пакета из файлов Web.config или App.config, в зависимости от типа проекта.
Вторая ошибка, с которой мы столкнулись, заключалась в том, что определенный пакет не может быть найден, и пакет с проблемой был System.Net.Http.Formatting. Небольшое гугление показало, что этот пакет больше не поддерживается, но теперь является частью Microsoft.AspNet.WebApi.Client, поэтому установка этого пакета решила проблему.
В зависимости от пакетов, используемых в проекте, могут возникать некоторые другие ошибки, но их можно легко исправить, как и вышеперечисленные, поскольку другие разработчики наверняка сталкивались с такими проблемами и задокументировали, как им удалось их исправить.
Если все в порядке, вы можете перейти к следующему шагу.
Установите последнюю версию .NET Framework на серверную машину
Последняя версия Visual Studio поставляется с последней версией .NET Framework, в нашем случае Visual Studio 2019 и .NET Framework 4.7.2, поэтому приложение будет работать на вашей машине. Но это не значит, что он будет работать и на серийной машине.
Перед развертыванием обновленного приложения на определенной машине вы должны убедиться, что там также установлена последняя версия .NET Framework и что приложение будет работать так же, как и на вашей машине разработки. Исключительно для этой цели Microsoft создала статью: Как определить, какие версии .NET Framework установлены. Если установленная версия более старая, вам необходимо скачать и установить нужную версию (в нашем случае .NET Framework 4.7.2) отсюда. После завершения этого шага вы можете перейти к следующему шагу.
Редактировать конвейеры CI/CD
Ручное развертывание последней версии приложения в нужной среде (тестовой, рабочей) требует времени, поэтому мы используем конвейеры Azure Dev Ops для автоматизации этого процесса (это также занимает несколько минут, но тем временем разработчик может заняться чем-то другим, например, создать резервную копию базы данных).