Доступ x86 COM от x64.NET
Вы можете попробовать с помощью решения ниже
$http({
method: 'POST',
url: url-post,
data: data-post-object-json,
headers: {'Content-Type': 'application/x-www-form-urlencoded'},
transformRequest: function(obj) {
var str = [];
for (var key in obj) {
if (obj[key] instanceof Array) {
for(var idx in obj[key]){
var subObj = obj[key][idx];
for(var subKey in subObj){
str.push(encodeURIComponent(key) + "[" + idx + "][" + encodeURIComponent(subKey) + "]=" + encodeURIComponent(subObj[subKey]));
}
}
}
else {
str.push(encodeURIComponent(key) + "=" + encodeURIComponent(obj[key]));
}
}
return str.join("&");
}
}).success(function(response) {
/* Do something */
});
3 ответа
Если компонент управляет x64-местным-жителем, он не может загрузить 32-битный незавершенный сервер COM, потому что это - неправильный вид процесса. Есть несколько возможных решений:
-
, Если бы Вы можете, постройте 64-битную версию кодекса COM (который, конечно, зарегистрировался бы в 64-битной регистрации). Это - самое чистое решение, но может не быть возможно, если у Вас нет кодекса для сервера COM.
-
Пробег Ваш компонент .NET как 32 бита x86, вместо x64. Я предполагаю, что Вы уже рассмотрели и отклонили этого по некоторым причинам.
-
Хозяин компонент COM использование из процесса суррогат COM DLLhost.exe. Это сделает звонки на сервер COM очень, намного медленнее (они теперь будут сообщениями Windows межпроцесса вместо родных вызовов функции), но в других отношениях прозрачно (Вы не должны делать ничего специального).
Это, вероятно, не будет выбором, если сервер потребует сделанного на заказ полномочного отрывного корешка вместо того, чтобы использовать нормальный oleaut32 один (очень редкий, хотя), так как не будет 64-битной версии доступной доверенности. Пока это может использовать обычное выстраивание OLE, Вы можете всего реестр это для суррогатной активации .
Я нашел это решение, , Контакт с 32-разрядными Компонентами Прежней версии в 64-разрядном Windows видит в статье:
•, Преобразовывающий тип проекта от незавершенного до из процесса
• Используя COM + как хост (эта работа для меня)
• Используя dllhost как суррогатный хост
Это - Ваш компонент COM, размещен в сервере COM (т.е. отдельный процесс) тогда, Вы не должны будете делать ничего специального, поскольку подсистема COM будет отдаленный Ваши требования от Вашего x64 приложения до приложения X86 и назад снова.
, Если Ваш компонент - незавершенный компонент COM тогда, Вы должны будете заново продумать вещи, поскольку 64-битный процесс не может использовать 32 бита в процессе комплектующие COM. Вы могли вынудить свой сервер работать под x86 так, чтобы Вы могли получить доступ к комплектующим (они оба будут 32-битными процессами). Если Вы не хотите делать это тогда, Вы должны будете видеть, укусил ли там x64 версию комплектующих COM, Вы используете.