HOWTO: вызов интерфейса управляемого C # из неуправляемого C ++ в WindowsCE Compact Framework - PullRequest
6 голосов
/ 12 мая 2009

У меня есть обширный неуправляемый код Windows CE 5 C ++, который предоставляет пользовательский интерфейс, который я хочу использовать в новом продукте, комбинируя его с большим количеством более новой бизнес-логики и коммуникационной логики, написанной на управляемом C # в Windows CE 6 и Compact Framework. .

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

Я нашел статью, в которой описано, как использовать COM в качестве моста в мире Windows, но у меня возникают трудности с его применением в .NET CF под WinCE. В прошлом я импортировал библиотеки типов и использовал вызовы COM (CoInitialize (), CoCreateInstance ()) для получения указателей на интерфейсы на других платформах Windows, и в настоящее время я придерживаюсь этой стратегии: использование COM непосредственно в неуправляемая библиотека C ++ для доступа к интерфейсам C # в моей управляемой библиотеке, при условии, что такая же возможность предоставляется в WinCE.

Вот моя проблема: библиотека типов. Он недоступен из моей управляемой библиотеки C #, так как я использовал его в прошлом с помощью оператора '#import "SomeCPPLibrary.dll". Я полагаю, что он похоронен в сборке .dll, хранится не так, как в прошлом, и, следовательно, не доступен напрямую через #import самой библиотеки. Я думаю, что я могу #import typelib, но я не могу найти способ извлечь typelib из моего управляемого .dll, и в то время как я смог бы собрать вместе файл определения интерфейса (.idl) и использовать midl.exe платформы чтобы сгенерировать из него .tlb, нет никакой гарантии, что мой .idl, а следовательно, и полученный .tlb действительно будет соответствовать тому, что находится в моем C # .dll. Я даже не знаю, работает ли платформа midl.exe таким образом, но предполагаю, что это так.

  1. Я лаю не на том дереве? Можно ли использовать управляемый интерфейс C # в неуправляемом C ++ через соответствующий интерфейс COM?

  2. Делает ли установка атрибута [assembly: ComVisible (true)] в своем файле AssemblyInfo.cs доступными все интерфейсы в управляемой сборке через COM в неуправляемом мире через GUID, который определяет AssemblyInfo.cs, или нужно сделать что-то еще?

  3. Как мне получить typelib из управляемого .dll, чтобы моя неуправляемая библиотека C ++ могла его импортировать?

  4. Я попытался добавить свой управляемый проект библиотеки C # в качестве ссылки в неуправляемый проект библиотеки C ++, но, похоже, это не помогло. Является ли такая ссылка вообще актуальной в данной ситуации?

  5. Есть ли лучший подход к решению основной проблемы вызова управляемого кода C # из неуправляемого мира C ++? Что-то, о чем я только что читал, - это библиотека в смешанном режиме с уровнем управляемого перевода для преодоления неуправляемого / управляемого пробела. Я не уверен, что это хорошая стратегия, так как скорость ответа на вызов является важным фактором, но, возможно, она будет лучше в долгосрочной перспективе, поскольку в какой-то момент я планирую переписать пользовательский интерфейс на управляемый C # и, таким образом, приложить все усилия для пользовательский интерфейс, а не хулиганство с более постоянной логикой бизнеса / связи? Независимо от ответа на этот вопрос, я все же хотел бы решить проблему использования COM, хотя бы по какой-то другой причине, кроме любопытства.

Ответы [ 2 ]

3 голосов
/ 12 мая 2009

Я попытался вызвать C # из C ++ в WinCE. Я не верю, что Compact Framework предоставляет поддержку COM, поэтому вы не можете использовать ComVisible (true).

Я также не смог найти способ размещения .NET в C ++, потому что опять-таки функциональность не была представлена ​​в Compact Framework.

Мое решение состояло в том, чтобы создать приложение-заглушку на C # и обмениваться данными с хостом C ++ через Msg Queues. Это также решает проблему с маршалингом данных. Производительность для моего использования в порядке. Самая большая стоимость - это время запуска заглушки, которое вам все равно придется заплатить, если вы завершили приложение на C #.

2 голосов
/ 12 мая 2009

Вы лаете не на то дерево. Для того чтобы нативный код вызывал управляемый код, нативный код должен ускорять механизм исполнения CLR. Это известно как CLR Hosting , и оно не поддерживается в CF. Это означает, что вы просто не можете этого сделать - даже с помощью творческого взлома (поверьте мне, я старался изо всех сил).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...