C# к C++ / CLI к Системе DLL C. IO.FileNotFoundException
SPXSpeechConfiguration *speechConfig = [[SPXSpeechConfiguration alloc] initWithSubscription:speechKey region:serviceRegion];
[speechConfig setPropertyTo:@"True" byId:SPXSpeechServiceResponseRequestDetailedResultTrueFalse];
После проб и ошибок, по-видимому, SPXSpeechServiceResponseRequestDetailedResultTrueFalse уже реализовано, так как он возвращает детали после установки свойства True. может быть, документация должна изменить метод комментария, который its already implemented с некоторыми шагами, как его настроить, вместо not implemented yet.
6 ответов
Ответ для GUI, кроме изменения выходных настроек, был добавлением Шага Перед сборкой
copy $(ProjectDir)..\Debug\BackingStore.* $(TargetDir)
Ответ для Тестовых проектов должен был добавить недостающий DLL к вкладке Deployment testrunconfig. Можно или сделать так путем прямого редактирования LocalTestRun.testrunconfig по умолчанию (появляется в Решении под Объектами Решения), или щелкните правой кнопкой по Solution и Add новая конфигурация тестового прогона, которая затем появится в соответствии с основным меню Test.
Спасибо за ответы на этом ТАК вопрос на тестовых конфигурациях для продвижения меня к ответу.
Является C и C++ DLLs в том же каталоге как блок C#, который это выполняет?
Вам, вероятно, придется изменить Ваши выходные настройки проекта так, чтобы блок C# и другой DLLs все закончили в той же папке.
Я часто использовал Зависимость Walker в случаях как это; это - проверка работоспособности, которая показывает, что все зависимости могут на самом деле быть найдены.
После того как Ваше приложение работает, можно также хотеть испытать Монитор Процесса на коде, который Вы выполняете, для наблюдения, на какие DLLs ссылаются, и где они расположены.
Это - интересная дилемма. Я никогда не слышал о проблеме, загружающей собственный.DLLs из C++ / CLI после вызова в него от C# прежде. Я могу только предположить, что проблема как @Daniel L предложена, и что Ваш.DLL просто не находится в пути, который может найти загрузчик сборок.
Если предложение Daniel не удается, я предлагаю, чтобы Вы попытались статически связать собственный код C с C++ / программа CLI, если Вы можете. Это, конечно, решило бы проблему, поскольку.DLL будет затем полностью поглощен в C++ / CLI.DLL.
Удостоверьтесь, что целевая система имеет корректный MS Визуальное время выполнения C, и что Вы случайно не создаете C dll со временем выполнения отладки.
Причина, по которой это происходит, заключается в том, что вы либо загружаете DLLMAIN из управляемого кода, прежде чем CRT получит возможность инициализироваться. У вас может не быть никакого управляемого кода, он может быть выполнен НЕПОСРЕДСТВЕННО или КОСВЕННО из-за действия уведомлений DllMain. (См .: Expert C ++ / CLI: .Net для программистов Visual C ++, глава 11 ++.)
Или у вас вообще нет собственной точки входа, но вы связались с MSVCRT. CLR автоматически инициализируется для вас с помощью параметра / clr, эта деталь вызывает большую путаницу и должна быть принята во внимание. DLL смешанного режима на самом деле задерживает загрузку среды CLR за счет использования горячего исправления всех vtables управляемых точек входа в ваших классах.
Эта тема связана с рядом проблем инициализации класса, блокировка загрузчика и задержка загрузки CLR иногда немного сложны. Попробуйте объявить global static и не использовать #pragma managed / unmanaged, изолируйте свой код с помощью / clr для каждого файла.
Если вы не можете изолировать свой код от управляемого кода и у вас возникли проблемы (после того, как вы взяли некоторые из эти шаги), вы также можете подумать о том, чтобы самостоятельно разместить CLR и, возможно, предпринять усилия по созданию диспетчера домена, который обеспечит ваше полное «в цикле» событий времени выполнения и начальной загрузки.
Именно поэтому , он не имеет ничего общего с вашим путем поиска или инициализацией. К сожалению, программа просмотра журналов Fusion не так сильно помогает (это обычное место для поиска проблем привязки сборки .NET CLR, а не обходчика зависимостей).
Статическая компоновка также не имеет ничего общего с этим.
Та же проблема при переходе на 64-битную Vista. Наше приложение вызывало Win32 DLL, что сбивало с толку целевую сборку приложения. Чтобы решить эту проблему, мы сделали следующее:
- Перейти к свойствам проекта;
- Выберите вкладку «Сборка»;
- Измените параметр «Цель платформы:» на x86;
- Перестроите приложение.
Когда я перестрою запустил приложение, оно сработало.