Я начну с ПРЕДУПРЕЖДЕНИЕ : не создавайте компоненты .Net, которые будут загружаться в IE. Задайте себе вопрос: «Что произойдет, если другое приложение сделает то же самое и использует другую версию CLR?». IE не гарантирует какой-либо порядок загрузки различных COM-компонентов, в которых он нуждается, поэтому нет гарантии, что ваша версия CLR будет загружена в процессе к тому времени, когда IE позвонит вам.
Теперь о вашей проблеме. В вашем сценарии есть несколько проблем:
- .Net изначально не поддерживает создание COM-компонентов вне процесса. Да, его можно создать, выполнив кучу хаков и ручную регистрацию; однако, это не простая задача и требует глубоких знаний о том, как работает COM;
- Учитывая вышесказанное, вы действительно можете создать .Net DLL и использовать атрибут ComVisible, чтобы предоставить классы, необходимые для COM. Как вы упомянули, вам нужно зарегистрировать его, используя
RegAsm.exe, чтобы IE мог использовать его;
- , поскольку вы хотите, чтобы основная функциональность вашего менеджера загрузок была в автономном исполняемом файле, вам придется использовать механизм межпроцессного взаимодействия с поддержкой .Net. .Net Remoting, вероятно, является самым простым способом его реализации и в большинстве случаев должен соответствовать вашим требованиям. Альтернатива заключается в реализации функции загрузки в процессе. Тем не менее, помимо соображения, что теперь вы можете легко подключить процесс IE, если вы не будете осторожны прислушиваться к его уведомлению о выходе (которое само по себе требует много работы), есть также целая энчилада с защищенным режимом IE7 +, который серьезно ограничивает возможности вашего внутрипроцессного кода (ограниченный доступ к файлам, доступ к реестру, API Windows и другие ограничения);
- Есть определенные сложности, возникающие из модели процессов IE8 и IE9. Помимо процесса верхнего кадра, IE8 / 9 создает пул процессов и распределяет между ними вкладки. Я не знаю, какой процесс попытается создать ваш COM-компонент, и будет ли он по одному на вкладку, на процесс или на весь сеанс IE (охватывающий несколько процессов), поэтому вы должны быть готовы к тому, что у вас может быть несколько экземпляры в нескольких процессах, запущенных одновременно. Если это так, вам придется выяснить, как обеспечить, чтобы связь между компонентом COM in-proc и исполняемым файлом не сериализовывалась по одному экземпляру за раз, иначе вы можете повлиять на работу пользователя для просмотра. (Простым сценарием может быть страница с несколькими ссылками на скачивание, и пользователь щелкает правой кнопкой мыши по каждой ссылке и выбирает
Open in new tab, таким образом запуская несколько загрузок на нескольких вкладках одновременно);
- даже если в сеансе IE имеется один экземпляр, экземпляры IE с повышенными правами запускаются в отдельном сеансе от экземпляров IE обычного пользователя по соображениям безопасности. Есть интересное осложнение, что ваш вызов .Net Remoting из COM-компонента in-proc в сеансе IE с повышенными правами приведет к тому, что вторая копия вашего исполняемого файла будет также повышена. Таким образом, ваш менеджер загрузки должен быть готов к тому, что два процесса могут получить доступ к одной и той же очереди загрузки;
- начиная с IE7, защищенный режим IE (по умолчанию) будет перехватывать любые вызовы, которые приводят к запуску нового процесса, и отображать диалог для пользователя. Единственный способ избежать этого - зарегистрировать тихую политику повышения IE для вашего процесса. Политики повышения прав зарегистрированы в
HKEY_LOCAL_MACHINE, что означает, что вам понадобится установщик или хотя бы простой скрипт для пользователей, которые будут запускаться от имени администратора;
- , даже если вы решите не использовать политику повышения прав и жить с неудачным опытом этого диалога, чтобы зарегистрировать свой менеджер загрузок в IE, вам все равно придется писать в куст реестра HKEY_LOCAL_MACHINE, иначе IE не узнает об этом и не буду его использовать. Другими словами, вам все еще нужен какой-то инсталлятор или скрипт развертывания;
- IE довольно агрессивно измеряет производительность кода, который выполняется в потоке пользовательского интерфейса, и завершает фоновые потоки при выходе из процесса. Таким образом, независимо от того, какие функции у вас есть в компоненте in-proc, вам придется балансировать между тем, чтобы быть максимально быстрым в потоке пользовательского интерфейса (что означает меньше работы, или вы будете влиять на пользовательский опыт), и выполнять работу в фоновых потоках (что означает быть готовым, что вы можете быть убиты без уведомления в любой момент);
Я думаю, что этот список охватывает основные проблемы, которые вам придется решить. Самая большая проблема, с которой вы столкнетесь, заключается в том, что многие особенности модели процесса IE плохо документированы в MSDN, и практически нет примеров реализации этого сценария в управляемом коде (а из тех, которые существуют, большинство из них старые и не являются обновлен для IE8 / IE9, а некоторые даже не будут работать в IE7).