Как исправить фатальную ошибку C1113: #using не удалось на Mylib.lib - PullRequest
4 голосов
/ 27 января 2010

У меня есть проект, который использует C ++ / CLI для реализации GUI и некоторую фоновую обработку для общения с датчиком. У меня есть все это работает и много сообщений, которые мы используем для связи с датчиком, находится в .dll. Проблема в том, что я хотел бы объединить библиотеку в основной исполняемый файл, чтобы не беспокоиться о распространении .dll.

У меня есть демонстрационный проект, который отлично работает с использованием .lib, но когда я пытаюсь переключить тело мани-кода для создания .lib вместо .dll, я получаю следующую ошибку:

1>------ Build started: Project: MyTool, Configuration: Debug Win32 ------
1>Compiling...
1>stdafx.cpp
1>.\stdafx.cpp : fatal error C1113: #using failed on 'c:\projects\MyTool\debug\MyLib.lib'

Немного погуглив предполагает, что это происходит, когда вы не применили переключатель MSIL, но он определенно присутствует в проекте библиотеки.

У меня есть смесь управляемого и неуправляемого кода как в моем демонстрационном проекте, так и в реальной работе, поэтому я действительно изо всех сил пытаюсь понять, в чем здесь проблема.

Любые предложения будут очень благодарны!

Ответы [ 3 ]

7 голосов
/ 28 января 2010

Я догадываюсь немного, но я подозреваю, что проект "MyTool" имеет проект "MyLib" в качестве одной из своих "ссылок" (меню "Проект" >> Свойства >> Общие свойства >> Ссылки).

Когда вы изменяете тип проекта MyLib на LIB вместо DLL, вам необходимо удалить «MyLib» из ссылок проекта. Затем вы обновляете зависимости проекта решения (меню «Проект» >> «Зависимости проекта ...»), чтобы MyTool зависел от MyLib.

0 голосов
/ 04 июня 2016

Если вы ссылаетесь на DLL в смешанном режиме (управляемый / собственный), вы можете получить эту ошибку. Что не следует делать, если в проекте используется CLR, даже если один из исходных файлов этого не делает. Но в любом случае, если это так, попробуйте удалить ссылку из Project | Properties | Common Properties | References, а затем повторно добавить ее.

0 голосов
/ 06 июня 2011

Я тоже столкнулся с этим. Причиной его неудачи было то, что я компилировал свою собственную / управляемую C ++ DLL для целевой .NET 4.0. И DLL, которую я использовал, была .NET 2.0 DLL. Как таковой он терпел неудачу, хотя пути и имена файлов выстроились идеально. В этом случае сообщение об ошибке совершенно не помогло. Я решаю это путем обновления независимой библиотеки DLL до .NET 4.0. Чтобы обе сборки использовали одну и ту же платформу .NET.

...