Компилятор .NET - доступ / отражение метаданных сборки CLR из неуправляемого C ++ - PullRequest
2 голосов
/ 13 февраля 2010

У меня есть компилятор, предназначенный для среды выполнения .NET (CLR). Текущая версия компилятора написана на стандартном C ++ (неуправляемом). В настоящее время компилятору не хватает поддержки ссылочных сборок во время компиляции, поэтому я «импортирую» библиотеки .NET с помощью утилиты-генератора заглушек, написанной на .NET, которая отображает любую сборку и выдает заглушку для нее на моем собственном языке. , Я предварительно генерирую заглушки для всех сборок .NET, которые я использую. Во время компиляции мой компилятор компилирует заглушки для заполнения таблиц символов и т. Д., Чтобы он мог разрешать типы и методы из .NET API. Это моя версия «использования». Однако это было временно, и теперь я хочу добавить фактическую директиву using или import для компилятора. Мне нужно получить доступ к метаданным / информации о типе в ссылочных сборках во время компиляции.

Мой вопрос: мне нужны предложения о том, как получить доступ к метаданным сборки CLR из неуправляемого C ++. Или мне нужно обоснование, чтобы преобразовать его в управляемое приложение C ++ и использовать поддержку отражения .NET. Цель чистого C ++ состоит в том, что я также могу компилировать в Linux для Mono, плюс у меня также есть частичные бэкэнды для другой среды выполнения, кроме CLR.

Ответы [ 2 ]

3 голосов
/ 13 февраля 2010

Я думаю, что это делается CoCreateObject () из класса CLSID_CorMetaDataDispenser, запрашивая интерфейс IID_IMetaDataDispenser. IMetaDataDispenser :: OpenScope () позволяет открывать метаданные сборки. Запросите IID_IMetaDataAssemblyImport, у него есть несколько методов для итерации метаданных.

Не упустите .NET 4.0, он не за горами, и я уверен, что формат метаданных изменился. Хотя это должно быть проблемой только для генерации метаданных, чтение должно быть обратно совместимым, если вы получаете версию интерфейсов 4.0. <cor.h> имеет CLSID для коклассных метаданных конкретной версии.

Я предполагаю, что вас не интересует Ирония.

1 голос
/ 13 февраля 2010

Это из статьи MSDN 'CLR Inside Out: API хостинга CLR', август 2006 г.

int main(int argc, _TCHAR* argv[])
{
    // Bind to the runtime.
    ICLRRuntimeHost *pClrHost = NULL;
    HRESULT hrCorBind = CorBindToRuntimeEx(
        NULL,   // Load the latest CLR version available
        L"wks", // Workstation GC ("wks" or "svr" overrides)
        0,      // No flags needed
        CLSID_CLRRuntimeHost,
        IID_ICLRRuntimeHost,
        (PVOID*)&pClrHost);

    // Construct our host control object.
    DHHostControl *pHostControl = new DHHostControl(pClrHost);

    // Notify the CLR that this host implements hosting managers.
    pClrHost->SetHostControl(pHostControl);

    // Now, start the CLR.
    HRESULT hrStart = pClrHost->Start();

    // Load an assembly and execute a method in it.
    HRESULT hrExecute = pClrHost->ExecuteInDefaultAppDomain(
        pwzAssemblyPath, pwzAssemblyName,
        pwzMethodName, pwzMethodArgs,
        &retVal);
}

Существует еще одна MSDN 'AdvancedМетоды, позволяющие избежать и обнаружить тупики в приложениях .NET, апрель 2006 г., с разделом «Разоблачение через API-интерфейс хостинга», который также может помочь в объяснении того, как использовать API-интерфейсы для хостинга из кода C / C ++.

Надеюсь, это поможет, С уважением, Том.

...