Добрый день, уважаемые господа. У меня возник такой вот вопрос.
Можно ли (и если да, то как) удалить .NET Framework полностью, то есть абсолютно? Вычистить весь этот мусор, все каталоги (Microsoft.NET, assembly, etc), все ключи реестра, все исполняемые файлы. Все версии фреймворка, включая те, которые идут в поставке ОС. Операционная система — Windows 7.
Поиск в интернетах особо много информации не дал, кроме индусских советов на сайте микрософта наподобие "сними галочку в компонентах виндовс" и страшилок от непонятных советчиков на парочке форумов "у-у-у, не делай так, у тебя все сломается". Если сломается, то хотелось бы услышать обоснованный ответ — ЧТО ИМЕННО сломается.
Большое спасибо.
P.S. Если раздел не тот, прошу модераторов меня извинить и перенести тему в нужный.
Здравствуйте, AlexRK, Вы писали:
ARK>Добрый день, уважаемые господа. У меня возник такой вот вопрос.
ARK>Можно ли (и если да, то как) удалить .NET Framework полностью, то есть абсолютно? Вычистить весь этот мусор, все каталоги (Microsoft.NET, assembly, etc), все ключи реестра, все исполняемые файлы. Все версии фреймворка, включая те, которые идут в поставке ОС. Операционная система — Windows 7.
Предлагаю еще в %windir% удалить WinSxS, SoftwareDistribution и Installer.
ARK>Поиск в интернетах особо много информации не дал, кроме индусских советов на сайте микрософта наподобие "сними галочку в компонентах виндовс" и страшилок от непонятных советчиков на парочке форумов "у-у-у, не делай так, у тебя все сломается". Если сломается, то хотелось бы услышать обоснованный ответ — ЧТО ИМЕННО сломается.
Весь треш и угар лежит в %windir%\Microsoft.NET и %windir%\assembly\
Перемещаем эти папки в temp и переименовываем ветку реестра HKLM\SOFTWARE\Microsoft\.NETFramework в HKLM\SOFTWARE\Microsoft\no.NETFramework или удаляем.
ARK>Большое спасибо.
Лучше всего пробывать в витруалке там есть savegame (в виде snapshot-ов)
Здравствуйте, kov_serg, Вы писали:
_>Предлагаю еще WinSxS удалить.
Это отдельный вопрос.
_>Весь треш и угар лежит в %windir%\Microsoft.NET _>Перемещаем эту папку в temp и переименовываем ветку реестра HKLM\SOFTWARE\Microsoft\.NETFramework в HKLM\SOFTWARE\Microsoft\no.NETFramework или удаляем. _>Лучше всего пробывать в витруалке там есть savegame (в виде snapshot-ов)
Ну, хотелось бы услышать что-то более детальное, нежели "попробуй грохнуть папку и узнаешь".
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, kov_serg, Вы писали:
_>>Предлагаю еще WinSxS удалить.
ARK>Это отдельный вопрос.
_>>Весь треш и угар лежит в %windir%\Microsoft.NET _>>Перемещаем эту папку в temp и переименовываем ветку реестра HKLM\SOFTWARE\Microsoft\.NETFramework в HKLM\SOFTWARE\Microsoft\no.NETFramework или удаляем. _>>Лучше всего пробывать в витруалке там есть savegame (в виде snapshot-ов)
ARK>Ну, хотелось бы услышать что-то более детальное, нежели "попробуй грохнуть папку и узнаешь".
Я предлагаю не грохнуть, а переместить или хотябы переименовать. Зачем сжигать мосты?
Здравствуйте, AlexRK, Вы писали:
ARK>Можно ли (и если да, то как) удалить .NET Framework полностью, то есть абсолютно? Вычистить весь этот мусор, все каталоги (Microsoft.NET, assembly, etc), все ключи реестра, все исполняемые файлы. Все версии фреймворка, включая те, которые идут в поставке ОС. Операционная система — Windows 7.
Здравствуйте, Ikemefula, Вы писали:
ARK>>Можно ли (и если да, то как) удалить .NET Framework полностью, то есть абсолютно? Вычистить весь этот мусор, все каталоги (Microsoft.NET, assembly, etc), все ключи реестра, все исполняемые файлы. Все версии фреймворка, включая те, которые идут в поставке ОС. Операционная система — Windows 7.
I>Снеси просто саму винду.
Да я бы с радостью, но лучше-то ничего нет. Все оси раздутые от лишнего мусора. Мак у меня тоже есть, так в нем в системных каталогах тоже полный ахтунг.
Мне от операционной системы ничего не надо, кроме графической оболочки и возможности запускать некоторые программы. Для этого ее размер по современным меркам вполне может уложиться в несколько сотен мегабайт, ИМХО.
Здравствуйте, AlexRK, Вы писали:
ARK>Да я бы с радостью, но лучше-то ничего нет. Все оси раздутые от лишнего мусора. Мак у меня тоже есть, так в нем в системных каталогах тоже полный ахтунг. ARK>Мне от операционной системы ничего не надо, кроме графической оболочки и возможности запускать некоторые программы. Для этого ее размер по современным меркам вполне может уложиться в несколько сотен мегабайт, ИМХО.
Здравствуйте, IID, Вы писали:
ARK>>Да я бы с радостью, но лучше-то ничего нет. Все оси раздутые от лишнего мусора. Мак у меня тоже есть, так в нем в системных каталогах тоже полный ахтунг. ARK>>Мне от операционной системы ничего не надо, кроме графической оболочки и возможности запускать некоторые программы. Для этого ее размер по современным меркам вполне может уложиться в несколько сотен мегабайт, ИМХО.
IID>ReactOS — то что доктор прописал.
Здравствуйте, AlexRK, Вы писали:
ARK>Добрый день, уважаемые господа. У меня возник такой вот вопрос.
ARK>Можно ли (и если да, то как) удалить .NET Framework полностью, то есть абсолютно? Вычистить весь этот мусор, все каталоги (Microsoft.NET, assembly, etc), все ключи реестра, все исполняемые файлы. Все версии фреймворка, включая те, которые идут в поставке ОС. Операционная система — Windows 7.
Здравствуйте, AlexRK, Вы писали:
ARK>Добрый день, уважаемые господа. У меня возник такой вот вопрос.
ARK>Можно ли (и если да, то как) удалить .NET Framework полностью, то есть абсолютно? Вычистить весь этот мусор, все каталоги (Microsoft.NET, assembly, etc), все ключи реестра, все исполняемые файлы. Все версии фреймворка, включая те, которые идут в поставке ОС. Операционная система — Windows 7.
Удалить можно, но сломается куча программ внутри винды, всякие там Event Viewer, IIS и пр. В винде достаточно много управляемого кода. Может поискать поиском по *.exe файлом строку BSJB на предмет того, является ли exe-ник управляемым кодом или нет.
Здравствуйте, iHateLogins, Вы писали:
HL>Удалить можно
Ручным удалением? Или, может, есть более продвинутый вариант.
HL>Удалить можно, но сломается куча программ внутри винды, всякие там Event Viewer, IIS и пр.
Иис не нужен. А вот без эвент вьюера это нехорошо...
HL>В винде достаточно много управляемого кода. Может поискать поиском по *.exe файлом строку BSJB на предмет того, является ли exe-ник управляемым кодом или нет.
Во, спасибо за совет. Надо все проверить, сегодня гляну.
Здравствуйте, iHateLogins, Вы писали:
HL>Может поискать поиском по *.exe файлом строку BSJB на предмет того, является ли exe-ник управляемым кодом или нет.
Попробовал ща. Действительно, есть некоторые экзешники с такой строкой. Но почти все лежат в каталоге дотнета. В system32 лежит всего три штуки — какие-то левые "Narrator.exe", "OxpsConverter.exe", "TsWpfWrp.exe". Какой-то шлак, по-моему. А, кстати, журнал событий "eventvwr.exe" — не содержит вхождений "BSJB".
В общем, вроде как выглядит не так уж плохо, вопреки множественным утверждениям из инета, что дотнет прочно пустил корни в винде. Хз, может, конечно, в 8 и 10 он укоренился сильнее, но они меня не интересуют.
Здравствуйте, iHateLogins, Вы писали:
HL>Удалить можно, но сломается куча программ внутри винды, всякие там Event Viewer, IIS и пр. В винде достаточно много управляемого кода. Может поискать поиском по *.exe файлом строку BSJB на предмет того, является ли exe-ник управляемым кодом или нет.
Может правильнее — искать при помощи ildasm.exe?
А когда всё найдешь — то и сам ildasm.exe удалишь (он ведь из того же самого теста сделан)
Здравствуйте, AlexRK, Вы писали:
ARK>Можно ли (и если да, то как) удалить .NET Framework полностью, то есть абсолютно? Вычистить весь этот мусор, все каталоги (Microsoft.NET, assembly, etc), все ключи реестра, все исполняемые файлы. Все версии фреймворка, включая те, которые идут в поставке ОС. Операционная система — Windows 7.
Не верю, что это возможно в актуальной виде.
Разница вот в чём: до какой-то версии Windows (XP, кажется), дотнетовский ехешник запускался как обычный, и сам грузил .NET компоненты.
После — уже на этапе загрузки РЕ образа .NET детектится и идёт по своей ветке.
(не помню точно за ХР, в 2003/ХР х64/Vista уже точно есть .NET поддержка как неотъемлемая часть загрузчика, х64 образы не умеют грузить себя сами)
Выковырять .NET из ntdll / загрузчика будет затруднительно.
Если же идти по сценарию использования старых версий, то всё просто — взять чисты старый дистрибутив.
Да, Assembly используются и нативными компонентами, например рантайм к некоторым версиям студии — нативная assembly.
И да, есть возможность смешивания .NET кода и обычного, так что потом можно удивиться, как какое-нибудь, казалось бы тяжелое нативное приложение, вроде офисного или там IDE, использует в своих потрохах дотнет.
Здравствуйте, Alexander G, Вы писали:
AG>Разница вот в чём: до какой-то версии Windows (XP, кажется), дотнетовский ехешник запускался как обычный, и сам грузил .NET компоненты. AG>После — уже на этапе загрузки РЕ образа .NET детектится и идёт по своей ветке. AG>(не помню точно за ХР, в 2003/ХР х64/Vista уже точно есть .NET поддержка как неотъемлемая часть загрузчика, х64 образы не умеют грузить себя сами) AG>Выковырять .NET из ntdll / загрузчика будет затруднительно. AG>Да, Assembly используются и нативными компонентами, например рантайм к некоторым версиям студии — нативная assembly.
Спасибо за информацию. А нет ли где-то более подробного описания этой кухни? Беглое гугление ничего не дало.
AG>И да, есть возможность смешивания .NET кода и обычного, так что потом можно удивиться, как какое-нибудь, казалось бы тяжелое нативное приложение, вроде офисного или там IDE, использует в своих потрохах дотнет.
Там кратко описано как работает CLR Loader Stub.
Тот самый, который загружает .NET в ту систему, где дотнет не тесно интегрирован.
Там утверждается, что эта тесная интеграция начиная с XP:
In Windows XP and above, the OS loader knows natively what to do with .NET executable assemblies, and fires up an instance of the CLR.
У меня нет более авторитетного источника, сам что-то сомневаюсь, моя память подсказывает, что в XP x86 таки ещё не было нативной поддержки .NET в загрузчике.
Факт, что в 2003/XP x64/Vista и новее .NET нативно встроен в загрузчик.
У 2003 и Vista есть 64-битные версии, где CLR Loader stub не требуется, а 32-битные версии работают в этом аспекте точно также.
(Но из этого не следует, что в XP x86 .NET нативно встроен в загрузчик, потому что XP x64 на самом деле на кодовой базе 2003)
Факт также, что в 95/98/ME/NT/2000 его нет, потому что дотнет появился позже.
Здравствуйте, AlexRK, Вы писали:
ARK>Это пофиг. Тяжелые приложения не нужны (совсем).
Прощайте:
вижуалка, оффис, современные многопользовательские игры, и многое, многое другое
Здравствуйте, AlexRK, Вы писали:
ARK>Спасибо за информацию. А нет ли где-то более подробного описания этой кухни? Беглое гугление ничего не дало.
Нормального источника я тоже не нашел. Собственно, если собирать по крупицам, то: Running Code
In Microsoft Windows XP and Windows Vista, the operating system loader checks for managed modules by examining a bit in the COFF header. The bit being set denotes a managed module.
Также было упоминание в книге "Inside Microsoft .Net Assembler"
COMIMAGE_FLAGS_ILONLY (0x00000001) The image file contains IL code only, with no embedded native unmanaged code except the startup stub. Because common language runtime–aware operating systems (such as Windows XP) ignore the startup stub, for all practical purposes the file can be considered pure-IL. However, using this flag can cause certain ILAsm compiler–specific problems when running under Windows XP. If this flag is set, Windows XP ignores not only the startup stub but also the .reloc section. The .reloc section can contain relocations for the beginning and end of the .tls section as well as relocations for what is referred to as data-on-data (that is, data constants that are pointers to other data constants). Among existing managed compilers, only the MC++ compiler and linker and the ILAsm compiler can produce these items. The MC++ compiler and linker never set this flag because the image file they generate is never pure-IL. Currently, the ILAsm compiler is the only one capable of producing pure-IL image files that might require a .reloc section. To resolve this problem, the ILAsm compiler, if TLS-based data or data-on-data is emitted, clears this flag and sets the COMIMAGE_FLAGS_32BITREQUIRED flag instead.
С другой стороны, если почитать, например Hosting Overview, то вроде как по шагам описывается, как инициализируется хост для .Net приложений, но не понятно, должен ли это делать stub в самом приложении (как это было исходно), или аналогичные действия может проделать сам загрузчик.
В любом случае, у .Net исполнимого файла должна быть ссылка на MSCorEE.dll из которой экспортируется CLRCreateInstance (для .Net 4)
И теоретически, можно найти все зависимые от .Net приложения, поискав, кто ссылаетсян на эту библиотеку, и импортирует данную функцию.
Только искать нужно именно по зависимостям, а не по тексту, а как это сделать быстро, я не очень представляю, если честно.
