Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 23
Оригинальное решение dll hell. А что, если захочется запустить обе версии одновременно? :)
Начиная с Windows XP, можно вообще не регистрировать dll-ки, а прописать необходимые ссылки на COM-dll в файле манифеста программы.
Это наиболее быстро и по максимуму труЪ.
Начиная с Windows XP, можно вообще не регистрировать dll-ки, а прописать необходимые ссылки на COM-dll в файле манифеста программы.
Это наиболее быстро и по максимуму труЪ.
программа ради которой это всё затеяно написана на vb6 :)
Так что манифесты это хорошо и так и надо делать, но в данном случае мне это никак не помогло бы :)
Так что манифесты это хорошо и так и надо делать, но в данном случае мне это никак не помогло бы :)
Странно, всегда думал, что манифест — это не только для .net-программ. mmm4vb6.atom5.com/ это тоже подтверждает: программа MakeMyManifest умеет сканировать vb6-проект и писать к нему манифест, чтобы тот работал без необходимости регистрации компонент.
Еще интересно, что у вас для программы на vb6 идет в комплекте утилитка на .net, для которой еще и fw нужен :) Но это уже оффтоп
Еще интересно, что у вас для программы на vb6 идет в комплекте утилитка на .net, для которой еще и fw нужен :) Но это уже оффтоп
спасибо.
не сказать, что очень юзабельно (ибо с такими задачами не сталкивался), но является полезной зарядкой для ума :)
не сказать, что очень юзабельно (ибо с такими задачами не сталкивался), но является полезной зарядкой для ума :)
Никогда не пишите подобные вещи на C#.
Потому что эти 30 строк адского платформ инвока превращаются в 4 строки кода на С++.
Потому что эти 30 строк адского платформ инвока превращаются в 4 строки кода на С++.
Ну как сказать… иногда пара строчек Path.Combine и простых операций со строками превращается в адские 20 строчек на Си. А если еще нужно прочитать/записать что-то в реестре, то даже не хочется думать, в сколько строчек RegOpenKey/RegQueryValue/RegCloseKey это превратится.
Короче говоря, надо выбирать инструмент по задаче. А простую безделицу (вроде той, о которой эта статья) можно писать на чем угодно/удобно.
Короче говоря, надо выбирать инструмент по задаче. А простую безделицу (вроде той, о которой эта статья) можно писать на чем угодно/удобно.
Я говорил про конкретную задачу.
Если по-вашему работа с реестром — это то же самое, что вызов DllRegisterServer — тогда простите, я видимо лишний на это празднике жизни.
Если по-вашему работа с реестром — это то же самое, что вызов DllRegisterServer — тогда простите, я видимо лишний на это празднике жизни.
Вы говорили про «подобные вещи» — это ни разу не «конкретная задача».
Работа с реестром была приведена для примера, что обычно делают такие «сервисные» утилиты. Точно так же там могла быть работа с WMI или какая-нибудь другая хрень. Я всего лишь оспорил ваше утверждение, что на Сях это всегда в разы компактнее, чем на Шарпе.
Работа с реестром была приведена для примера, что обычно делают такие «сервисные» утилиты. Точно так же там могла быть работа с WMI или какая-нибудь другая хрень. Я всего лишь оспорил ваше утверждение, что на Сях это всегда в разы компактнее, чем на Шарпе.
Это далеко не весь проект… Одной из подзадач была такая регистрация. Не было варианта написать на с++
Вообще это задача для батника.
Если все длл лежат в одной папке, то вообще одной строчкой решается.
И даже если там сотня длл-ок, то это все равно было бы в разы быстрее и нагляднее, чем писать отдельную программу (и потом документировать для последователей, на кой черт оно было нужно).
Если все длл лежат в одной папке, то вообще одной строчкой решается.
И даже если там сотня длл-ок, то это все равно было бы в разы быстрее и нагляднее, чем писать отдельную программу (и потом документировать для последователей, на кой черт оно было нужно).
не было бы в разы быстрее. Быстрее как раз так. При таком подходе как в статье не нужно для каждой длл создавать 2 процесса. Как минимум на этом экономится время.
Про наглядность — не спорю, но была задача оптимальности и на .NET
Про наглядность — не спорю, но была задача оптимальности и на .NET
Зато тратится время на P/Invoke, к тому же автоматически добавляется ограничение на разрядность библиотек.
Просто интересно: сколько всего было библиотек и сколько секунд выгадано за счет этого кода?
И сколько времени потрачено на поиск решения в гугле и написание собственного? И оно того стоило?
Просто интересно: сколько всего было библиотек и сколько секунд выгадано за счет этого кода?
И сколько времени потрачено на поиск решения в гугле и написание собственного? И оно того стоило?
Если подходить исключительно со стороны вопроса быстродействия: Вы думаете, что маршаллинг пары сотен байт станется медленнее, чем порождение процессов dllunreg/dllreg?
библиотек около 300… Итого — в начале разрегистровать страуюю длл, потом зарегистрировать новую — получаем около 600 процессов надо запустить…
Выигрыш в скорости раза в 5… Т.е. в варианте с запуском процессов оно работало минут 7, причём весь комп аццко тормозил, в варианте с этим кодом работает минуты 1.5… Т.е. ощутимо быстрее и менее тормознуто…
Времени было потрачно около 20 минут на написание… Ну и минут 40 на изучение проблемы со всех сторон…
Оно того стоило, потому что на машинах переход с версии на версию может осуществляться раз 10 в день…
Выигрыш в скорости раза в 5… Т.е. в варианте с запуском процессов оно работало минут 7, причём весь комп аццко тормозил, в варианте с этим кодом работает минуты 1.5… Т.е. ощутимо быстрее и менее тормознуто…
Времени было потрачно около 20 минут на написание… Ну и минут 40 на изучение проблемы со всех сторон…
Оно того стоило, потому что на машинах переход с версии на версию может осуществляться раз 10 в день…
Вот вам простой тест:
Теперь посчитаем оверхед на запуск двух тысяч процессов regsvr32:
Как видим, такое создание процессов действительно сопряжено с большим оверхедом — около 7 минут. Однако немного изменим способ запуска:
Отлично, оверхед уменьшен до 38 секунд. Это уже приемлемо, однако можно ли и этот результат улучшить? Специфика команды for такова, что выполняемая в ней операция меняет заголовок консоли. Если делать это пару тысяч раз, то (учитывая общую неторопливость консоли) это займет какое-то время.
Напишем теперь маленький cmd-файл:
По сути, здесь все то же самое, только в одном пакетно файле. Запустим:
Как видим, оверхед теперь составляет всего около 14 секунд на двух тысячах файлов. Как мне кажется, с этим можно смириться ;)
c:\windows\system32> dir *.dll
..... (много файлов) .....
1948 File(s) 878 145 314 bytes
0 Dir(s) 75 457 482 752 bytes freeТеперь посчитаем оверхед на запуск двух тысяч процессов regsvr32:
c:\windows\system32> echo %time% 15:04:32,91 c:\windows\system32> for %i in (*.dll) do @regsvr32 /s /? c:\windows\system32\> echo %time% 15:11:19,23
Как видим, такое создание процессов действительно сопряжено с большим оверхедом — около 7 минут. Однако немного изменим способ запуска:
c:\windows\system32> echo %time% 15:14:18,73 c:\windows\system32> for %i in (*.dll) do @start regsvr32 /s /? c:\windows\system32\> echo %time% 15:14:56,72
Отлично, оверхед уменьшен до 38 секунд. Это уже приемлемо, однако можно ли и этот результат улучшить? Специфика команды for такова, что выполняемая в ней операция меняет заголовок консоли. Если делать это пару тысяч раз, то (учитывая общую неторопливость консоли) это займет какое-то время.
Напишем теперь маленький cmd-файл:
@echo off echo %time% cd c:\windows\system32 for %%i in (*.dll) do @start regsvr32 /s /? echo %time%
По сути, здесь все то же самое, только в одном пакетно файле. Запустим:
C:\Users\xyz\Documents>test.cmd 15:27:35,35 15:27:49,52
Как видим, оверхед теперь составляет всего около 14 секунд на двух тысячах файлов. Как мне кажется, с этим можно смириться ;)
спасибо, очень интересно и очень круто!
Проблема ещё в том, что перерегистрация длл это только маленькая часть того, что делает утилитка… Нет смысла выносить маленький кусочек из неё в cmd…
Проблема ещё в том, что перерегистрация длл это только маленькая часть того, что делает утилитка… Нет смысла выносить маленький кусочек из неё в cmd…
а вы попробуйте сетапами ставить обновления, жизнь станет проще.
а вообще — используйте виртуализацию приложений (например Xenocode или ThinApp) и да прибудет с Вами счастие неизобретения велосипедов.
а вообще — используйте виртуализацию приложений (например Xenocode или ThinApp) и да прибудет с Вами счастие неизобретения велосипедов.
ну вы же вообще не в курсе для чего это приложение и как оно должно функционировать… Зачем давать советы не зная предмета разговора?
Я привёл код с определённой функциональностью, применяйте так, как вам нравится, но не стоит давать советы в предметной области о которой вы не имеете ни малейшего представления и считать при этом что вы дали умный совет.
Я привёл код с определённой функциональностью, применяйте так, как вам нравится, но не стоит давать советы в предметной области о которой вы не имеете ни малейшего представления и считать при этом что вы дали умный совет.
вам наглядно выше продемонстрировали что вы написали полный велосипед, и что эта же задача решается двумя строками на bat языке.
Вы хотите сказать что вашу систему нельзя виртуализировать? Нельзя даже в VM запихать?) В системе над которой работаю я около 3к dll-ок, а уж сколько в них COM классов никто даже не считал. Система работает как с аппаратурой (включая криптодевайсы) так и с внешними софтерными системами. И никаких проблем в виртуализации у нас нет.
Вы хотите сказать что вашу систему нельзя виртуализировать? Нельзя даже в VM запихать?) В системе над которой работаю я около 3к dll-ок, а уж сколько в них COM классов никто даже не считал. Система работает как с аппаратурой (включая криптодевайсы) так и с внешними софтерными системами. И никаких проблем в виртуализации у нас нет.
проблема не в том можно или нельзя и сколько тысяч длл… Проблема в том что количество версий на одной машине может быть и 20 штук и надо между ними быстро переключаться, кроме того, в каждой из версий могут постоянно обновляться неокторые длл, приходить скрипты для обновления некоторых элементов системы причём только для конкретной версии итд…
Запихать можно, но это не решение, потому что нужно иметь возможность создавать версии динамически… Каждый раз настраивать виртуализацию? Зачем… Каждый раз переписывать бат файл? Зачем? У проекта своя специфика и не вижу смысла тут её обсуждать… У вашего одна, у моего другая… Есть случаи когда и велосипед помогает.
Запихать можно, но это не решение, потому что нужно иметь возможность создавать версии динамически… Каждый раз настраивать виртуализацию? Зачем… Каждый раз переписывать бат файл? Зачем? У проекта своя специфика и не вижу смысла тут её обсуждать… У вашего одна, у моего другая… Есть случаи когда и велосипед помогает.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
regsrv32.exe на .NET / Register COM server from .NET