именно для разработки приложений и в первую очередь для ПО Autodesk
ИМХО
В контексте разработки ПО слово "переход" наверное не совсем правильно... При разработке ПО чем больше вариантов ОС учитывается, тем лучше. Ведь конечный пользователь имеет своё, индивидуальное мнение на тему того, какую ОС ему использовать и с этим придётся считаться, если ты ориентируешься не только на доменные машинки своей организации.
Да и не факт, что не будет так: сегодня принято решение использовать везде в компании такую версию ОС, а через год, по каким-то другим соображениям, вдруг будет принято решение об использовать другой версии.
Т.о. в идеале, разработчику нужно иметь отдельную виртуальную машинку под каждую версию ОС (Win7-Win10), в т.ч. и под каждую разрядность, с установленными на них последними пакетами обновлений. На эти же машинки устанавливаешь утилиты удалённой отладки от Майкрософт.
На основе этих машинок должны (опять же - в идеале) иметься полные клоны, на которых устанавливаются все версии интересующих тебя продуктов Autodesk. Т.е. отдельная машинка под интересующий тебя набор AutoCAD, отдельная под набор Revit и т.п. и т.д. Причём вариантов таких машинок так же два: x86 и x64. Не забываешь при этом "расшарить" каталоги, в которые будут помещаться результаты компиляции твоего кода для Debug-режима
Затем, создавая связанные клоны, можно использовать их для тестирования.
Аналогичная ситуация и с виртуальной машинкой для разработки ПО (т.е. той, на которой ты будешь писать код): на эту вирт. машинку ставишь нужный тебе набор SDK, IDE и разных дополнительных программ, нужных тебе в процессе работы (WiX, Help and Manual, SandCastle, ReSharper, .Net Reflector и т.п.). На этой же машинке подключаешь сетевые диски, указывающие на каталоги в сети или на физ. машине, в которых будешь хранить исходники своих проектов.
Т.е. обозначенные выше вирт. машинки - это шаблоны, на основе которых ты, в процессе своей работы будешь создавать связанные клоны. На связанных клонах ничего важного хранить не нужно, дабы в любой момент такой клон можно было бы безболезненно заменить другим.
Для выполнения работы ты создаёшь связанный клон нужной тебе машинки. Ты пишешь код на одной вирт. машинке а отладка по факту выполняется на другом клоне, где установлен нужный тебе (для данного проекта) набор версий интересующего тебя ПО (например, AutoCAD) - это выполняется при помощи механизма Remote Debugger. Это позволяет тебе быстро переключаться между отладочными машинками, например с x86 на x64; или с AutoCAD на BricsCAD, ZWCAD, nanoCAD. Кроме того, такой подход позволяет тебе не "зас*рать" машинку, на которой ты пишешь код, огромным количеством софта, не относящимся к разработке, но относящимся к целевому продукту, под который ты пишешь код. Как следствие - компьютер будет меньше тормозить и на нём не будут возникать разного рода конфликты настроек или библиотек целевого ПО.
Кроме того, такой подход позволяет тебе в пакетном режиме запускать интеграционные тесты, которые будут выполняться последовательно на разных виртуальных машинках. Т.е. ты нажимаешь F5 и происходит последовательное тестирование твоего кода для AutoCAD 2009-2017 x86, AutoCAD 2009-2017 x64, nanoCAD 6-8 x64, nanoCAD 5-8 x64, BricsCAD 12-15 x86, BricsCAD 12-15 x64. Это если ты пишешь свой код так, чтобы его можно было компилировать под разные CAD системы. Даже если это не так, то пакетное тестирование версий AutoCAD x86 и x64 - это тоже не мало...
Пока выполняются тесты, ты можешь попить кофе, а вернувшись - просмотришь HTML отчёты о результатах тестирования для каждой машинки.
Повторюсь, что связанные клоны хороши тем, что в случае чего их можно быстро удалить и создать новые (если вдруг на машинке что-то перестанет работать или станет работать "как-то не так"). Процесс удаления старого и создания нового связанного клона занимает несколько секунд.
В прошлом я уже показывал как это всё работает, в т.ч. и на видео.
