Добрый день, уважаемые господа. У меня возник такой вот вопрос.
Можно ли (и если да, то как) удалить .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 приложения, поискав, кто ссылаетсян на эту библиотеку, и импортирует данную функцию.
Только искать нужно именно по зависимостям, а не по тексту, а как это сделать быстро, я не очень представляю, если честно.
Здравствуйте, AlexGin, Вы писали:
ARK>>Это пофиг. Тяжелые приложения не нужны (совсем). AG>Прощайте: AG>вижуалка, оффис, современные многопользовательские игры, и многое, многое другое
Большое спасибо.
AG>Тот самый, который загружает .NET в ту систему, где дотнет не тесно интегрирован. AG>Там утверждается, что эта тесная интеграция начиная с XP: AG>
AG>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.
AG>У меня нет более авторитетного источника, сам что-то сомневаюсь, моя память подсказывает, что в XP x86 таки ещё не было нативной поддержки .NET в загрузчике.
Но тут возникает такой вопрос, а нужен ли дотнет при старте системы? Ну да, "OS loader knows natively what to do with .NET executable assemblies", но это вроде как не означает, что без дотнета система работать не будет.
Впрочем, направление дальнейших изысканий ясно.
UPD. Пардон, неверно понял предложение про загрузчик (думал, речь идет о загрузке системы, а речь о загрузчике приложений). Впрочем, это ничего не меняет.
Здравствуйте, Михаил Романов, Вы писали:
МР>С другой стороны, если почитать, например Hosting Overview, то вроде как по шагам описывается, как инициализируется хост для .Net приложений, но не понятно, должен ли это делать stub в самом приложении (как это было исходно), или аналогичные действия может проделать сам загрузчик. МР>В любом случае, у .Net исполнимого файла должна быть ссылка на MSCorEE.dll из которой экспортируется CLRCreateInstance (для .Net 4) МР>И теоретически, можно найти все зависимые от .Net приложения, поискав, кто ссылаетсян на эту библиотеку, и импортирует данную функцию. МР>Только искать нужно именно по зависимостям, а не по тексту, а как это сделать быстро, я не очень представляю, если честно.
Ну, самый интересный вопрос — будет ли сама система работать и грузить unmanaged код (а не .NET приложения, которые не нужны ).
Здравствуйте, AlexRK, Вы писали:
ARK>UPD. Пардон, неверно понял предложение про загрузчик (думал, речь идет о загрузке системы, а речь о загрузчике приложений). Впрочем, это ничего не меняет.
Да, PE Loader, где PE это Portable Execuable, нативные и дотнетовские, 32 и 64 битные, EXEшники и DLLки. EXEшники прежде всего.
Загрузчик для нативных EXEшников была, есть, и будет в NTDLL.
С учётом того, что система сама знает что делать с .NET EXEшником, можно предположить такие варианты:
Ядро не знает про .Net, но NTDLL знает, и он уже грузит MSCorEE.dll. Самый логичный вариант. NTDLL не знает про .Net, но ядро знает, так что ядро сразу запускает не загрузчик из NTDLL, а что-то иное. Дурацкий вариант, если честно. NTDLL то всё равно нужна, и её загрузочный код должен отработать.
И ядро, и NTDLL знают про .Net. Громоздкий, но реалистичный вариант.
Все варианты, в общем, сводятся к тому, что "совсем вычистить" будет сложно.
Upd: ниже по ветке сообщение от okman, где подтверждается, что загрузчик в XP знает о .Net и есть в NTDLL специфичные для .Net функции.
Здравствуйте, AlexRK, Вы писали:
ARK>Ну, самый интересный вопрос — будет ли сама система работать и грузить unmanaged код (а не .NET приложения, которые не нужны
Достоверно ответить не смогу.
Подозреваю, что да — будет.
Но единственный приходящий на ум способ хотябы примено понять, чем это обернется — тот что я привел выше, т.е. вручную вычислить зависимости.
Здравствуйте, Alexander G, Вы писали:
AG>... AG>У меня нет более авторитетного источника, сам что-то сомневаюсь, моя память подсказывает, что в XP x86 таки ещё не было нативной поддержки .NET в загрузчике.
Поддержка была.
В Windows XP загрузчик во время выполнения функций ntdll!_LdrpInitialize и ntdll!LdrpInitializeProcess
определяет .NET-приложение по наличию директории "CLR header" (индекс 0xE), после чего вызываются функции
ntdll!LdrpCorValidateImage (видимо, какие-то проверки) и ntdll!LdrpCorReplaceStartContext (подмена стартового
адреса в стеке на CorExeMain).
Это все было проверено на самой обычной WinXP-SP2-x86 без установленных .NET Framework, версия ntdll — 5.1.2600.2180.
Здравствуйте, Михаил Романов, Вы писали:
МР>В любом случае, у .Net исполнимого файла должна быть ссылка на MSCorEE.dll из которой экспортируется CLRCreateInstance (для .Net 4)
Мои опыты показали, что 32 битное C# консольное приложение импортирует только _CorExeMain, а 64 битное консольное C# приложение вообще ничего не импортирует.
Впрочем, по структуре файла .Net не очень сложно определить — ImageDirectoryEntryToData с параметром IMAGE_DIRECTORY_ENTRY_COM_DESCRIPTOR должна что-то хорошее возвращать для .Net
(Да, нет никакого COM Decriptor в Image Directory, но зато есть .Net Metadata вместо него).
Здравствуйте, okman, Вы писали:
O>Поддержка была.
O>В Windows XP загрузчик во время выполнения функций ntdll!_LdrpInitialize и ntdll!LdrpInitializeProcess O>определяет .NET-приложение по наличию директории "CLR header" (индекс 0xE), после чего вызываются функции O>ntdll!LdrpCorValidateImage (видимо, какие-то проверки) и ntdll!LdrpCorReplaceStartContext (подмена стартового O>адреса в стеке на CorExeMain).
O>Это все было проверено на самой обычной WinXP-SP2-x86 без установленных .NET Framework, версия ntdll — 5.1.2600.2180.
Возможно, потому что SP2, мне кажется, в "чистой" её нет.
(Вообще разные SP иногда сильно меняли подобные внутренности системы)
Здравствуйте, Alexander G, Вы писали:
AG>... AG>Возможно, потому что SP2, мне кажется, в "чистой" её нет.
Скорее всего, так и есть. WinXP зарелизили в 2001-ом году, а первая версия .NET вышла в 2002-ом.
По логике вещей, поддержку .NET в ntdll добавили в SP1 для Windows XP, т.к. он тоже вышел в 2002-ом.
Но проверить, увы, не на чем, т.к. WinXP без SP еще попробуй найди
Здравствуйте, AlexRK, Вы писали:
ARK>Ну, самый интересный вопрос — будет ли сама система работать и грузить unmanaged код (а не .NET приложения, которые не нужны ).
А, если цель уже в том, чтобы сломать все .NET приложения, а не совсем вычистить весь .NET, то, по идее, поддержка .NET в загрузчике мешать не будет.
Все зависимости в NTDLL.DLL на MSCorEE.dll динамические, иначе почему в нативных приложениях MSCorEE.dll нет.
Здравствуйте, Alexander G, Вы писали:
ARK>>Ну, самый интересный вопрос — будет ли сама система работать и грузить unmanaged код (а не .NET приложения, которые не нужны ).
AG>А, если цель уже в том, чтобы сломать все .NET приложения, а не совсем вычистить весь .NET, то, по идее, поддержка .NET в загрузчике мешать не будет. AG>Все зависимости в NTDLL.DLL на MSCorEE.dll динамические, иначе почему в нативных приложениях MSCorEE.dll нет.
Ну, не совсем так, цель — вычистить дотнет в той степени, в какой это возможно.
И, кстати, я нашел вроде как рабочий способ — утилита NTLite. Позволяет выкорчевать и дотнет, и трезубец, и кучу другого мусора.
Здравствуйте, flаt, Вы писали:
ARK>>И, кстати, я нашел вроде как рабочий способ — утилита NTLite. Позволяет выкорчевать и дотнет, и трезубец, и кучу другого мусора.
F>Что такое трезубец?
Здравствуйте, AlexRK, Вы писали:
ARK>И, кстати, я нашел вроде как рабочий способ — утилита NTLite. Позволяет выкорчевать и дотнет, и трезубец, и кучу другого мусора.
Здравствуйте, Ночной Смотрящий, Вы писали:
ARK>>И, кстати, я нашел вроде как рабочий способ — утилита NTLite. Позволяет выкорчевать и дотнет, и трезубец, и кучу другого мусора.
НС>Может уже тогда сразу Nano Server, не?
Честно говоря, не слышал вообще о таком. Интересно посмотреть.
Upd. А, оно без графического интерфейса — не подходит.
Кстати, на форуме NTLite народ ужал размер установленной Win 7 до одного гигабайта, с сохранением графического интерфейса и работы с сетью. Как раз то, что надо.
А вообще винда без .Net'a, это как мороженное без молока, стейк без мяса, птица без крыльев (Linux не в счёт), танк без пушки и тд...
Не нужна она тебе Ставь MS-DOS!
Здравствуйте, AlexRK, Вы писали:
ARK>Так ведь все приложения его используют — браузеры, файловые менеджеры, игры...
Ну так приложения, я так понял, тебе не особо нужны. Без дотнета и движка IE отвалится изрядная часть. Ну отвалится еще какое то количество, подумаешь. Lynx должен работать, а остальное не нужно.
Здравствуйте, Ночной Смотрящий, Вы писали:
ARK>>Так ведь все приложения его используют — браузеры, файловые менеджеры, игры...
НС>Ну так приложения, я так понял, тебе не особо нужны. Без дотнета и движка IE отвалится изрядная часть.
Не, приложения нужны. Но я не использую приложений, зависимых от дотнета и движка ие.
Здравствуйте, Ночной Смотрящий, Вы писали:
ARK>>Не, приложения нужны. Но я не использую приложений, зависимых от дотнета и движка ие.
НС>Ну так чего останавливаться на полпути?
Я не останавливаюсь на полпути. Цель — выкинуть всё для меня лишнее, а не абсолютно всё.
Здравствуйте, AlexRK, Вы писали:
ARK>Во-первых, хрюшу нельзя купить легально.
Можно. МС разрешает даунгрейд. За подробностями гугли "microsoft downgrade rights"
ARK>Во-вторых, хрюшу совсем мало какой софт и хард сейчас поддерживают.
Напомню: >> Мне от операционной системы ничего не надо, кроме графической оболочки и возможности запускать некоторые программы.
Здравствуйте, IID, Вы писали:
ARK>>Во-вторых, хрюшу совсем мало какой софт и хард сейчас поддерживают. IID>Напомню: >>> Мне от операционной системы ничего не надо, кроме графической оболочки и возможности запускать некоторые программы. IID>
Некоторые мои проги (кое-какие игрушки) хрюшу не поддерживают.
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, kov_serg, Вы писали:
_>>Я предлагаю не грохнуть, а переместить или хотябы переименовать. Зачем сжигать мосты?
Ops>Зачем, если сам же советуешь виртуалку со снимком?
Очень просто возможно придётся это делать итерационно, поэтому лучше иметь возможноть быстро откатится и продолжить. В самой винде этот .net "нафиг не нужон", а вот сторонний софт активно юзает, но если такой не использовать то всё будет норм.
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, Iron Monkey, Вы писали:
IM>>Мож тебе просто хрюшу поставить безо всяких FW и прочих свистелок?
ARK>Во-первых, хрюшу нельзя купить легально.
А нафига вам легально. Легально и .net выпиливать нельзя.
ARK>Во-вторых, хрюшу совсем мало какой софт и хард сейчас поддерживают.
Брехня. Ставим виртуалку и в ней несколько winxp
Здравствуйте, AlexRK, Вы писали:
ARK>Можно ли (и если да, то как) удалить .NET Framework полностью, то есть абсолютно? Вычистить весь этот мусор, все каталоги (Microsoft.NET, assembly, etc), все ключи реестра, все исполняемые файлы. Все версии фреймворка, включая те, которые идут в поставке ОС. Операционная система — Windows 7.
Не уверен, что опыт Windows XP будет применим на Windows 7, но расскажу.
На Windows XP можно без проблем удалить .Net, ничего не ломается (ни сама ОС, ни её загрузка, ни программы из стандартной поставки (выше говорили-предполагали, что Event Viewer поломается; в Windows XP не поломался)).
Как выше уже сказали, также нужно ручками удалить директории C:\WINDOWS\Microsoft.NET\ и C:\WINDOWS\assembly\ , т.к. при деинсталляции они остались (и были пухленькие). Удаление их тоже никак функционирование ОС и программ не поломало.
Также я запускал CCleaner, который нашёл огромную кучу ссылок в реестре на внутренности выше обозначенных директорий, несмотря, что процедуры деинсталляции отработали полностью и нормально. Удаление этих ключей в реестре это программой никак и ничего не поломало.
У меня в тот момент на том компьютере было ровно 2 программы, которым требовался .Net 2.0 (KeePass, Eyes Relax), поэтому вообще никакого дискомфорта не ощутил от удаления .Net'а на том компьютере. Эти 2 программы были т.н. портабельными, т.е. все свои сборки держали при себе. Инсталлируемые программы в C:\WINDOWS\assembly\ закидывают свои сборки, поэтому после удаления C:\WINDOWS\assembly\, если потом .Net заново установить, полагаю, что инсталлированные ранее .Net-приложения работать перестанут.
Ускорения Windows XP не последовало. Всё работало, как и раньше.
Заново .Net поставился и работал без проблем. Портабельные .Net-приложения тоже.
Удалялся .Net для отладки утилиты Ngen из стандартной поставки .Net.
