вызов чужого COM-32бита из 64-битного приложения

[zubr]

Malaja, подумай, если бы любое приложение могло, используя класс Net Framework RegistrySecurity, писать в защищенные ветки реестра, то смысл вообще в системе безопасности и в контроле учетных записей в частности?
Инжект - это не класс, а внедрение кода и запуск его из одного приложения в другое. Эту технологию используют вирусы и антивирусные программы.

[Malaja]

zubr,

все это существует, тем не менее куча приложений инсталлирует что-то с тихим заходом в реестр..
Кроме всего прочего авторы решения уверяли, что у них получилось...

[zubr]

Malaja,
1. Не все ветки реестра требуют админских полномочий.
2. Не все приложения пишут в реестр, а только читают.
3. Если используется стандартный инсталлятор, то он является доверенным приложением и UAC его пропускает.
4. Настройки UAC у пользователей могут быть на самом низком уровне защиты или вообще отключен UAC.

[Джон]

все это существует, тем не менее куча приложений инсталлирует что-то с тихим заходом в реестр.

Ир, ключевое слово "инсталлирует", поэтому Ромка и советовал назвать экзешник setup, кстати без всякого юмора. Мне в одном проекте-инсталляторе пришлось отлавливать слова setup и install (даже в блоке описания), чтобы не появлялось злосчастное окошко подтверждения запуска от имени админа.

А ещё надо не забывать, что частенько инсталляторы работают от имени пользователя SYSTEM.

[Malaja]

зубр,
- к сожалению, мне надо менять именно те ветки, на которые нужны админ - полномочия...
- на машине клиента UAC  скорее всего установлен в состояние повышенной боевой готовности, поэтому на это надеяться нельзя.

Джон,
но тогда даже если я назову ехе - шник setup-ом, я не избавлюсь от того самого диалога..
Кстати, а как инсталлятор задает себе имя пользователя таким образом? Значит, есть способ?

Тут уже появилась идея - просто считать значениай нужных ключей, точнее, проверить, есть ли они в наличии. Если нет - создать программно рег - файл и выдать сообщение клиенту о том, что емуи сначала надо запустить этот файл, а потом повторно стартовать наш тул.
Но сначала надо добить тест - работает ли все правильно в случае измененного реестра... К сожалению, у нас последние два дня были проблемы с железом, поэтому тестировать было негде..

Добавлено через 16 часов, 3 минуты и 24 секунды:
Наконец-то заработал тестовый комп. Внесла ручками все предложенные изменения в реестр и попробовала загрузить com. Результат:
при загрузке com ошибка TYPE_E_LIBNOTREGISTERED

так что похоже, что это решение тупиковое...

придется рыть в направлении stub.. Я этим никогда не занималась, коллега тоже...

[Malaja]

Update:

"Я убью тебя, лодочник!" - сказали мы третьему коллеге, который дал нам неверно параметрированный проект...

решение 64 <->32 с помощью реестра работает! 
Хотя после загрузки com-а и конвертирования в тип нашего интерфейса, если посмотреть сам полученный объект, то можно увидеть ошибку TYPE_E_LIBNOTREGISTERED.

так что теперь будем решать вопрос - как изменять реестр.

[Malaja]

Update еще раз Я упоминала 2 способа решения проблемы - через реестр и с помощью нового процесса, который компилируем под х86.

Так вот, второе решение я, благодаря хорошему step-by-step - у, данному коллегой, сделала - таки работает! Во всяком случае длл загружается без всяких ошибок.
Я подвешу тестовый проект - сразу прошу прощения за то, что там ничего не вылизывалось, ибо делалось все в промежутках между другими заданиями (официально я этим не занималась, ибо проблему решили более простым путем )

Важно - сначала открыть ClientServer_Server - проект и почитать все пояснения в ServerStub.cs. Я попыталась записать все, что сделала.