How do I fix fatal error C1113: #using failed on 'Mylib.lib'

I have a project which uses C++/CLI to implement a GUI and some background processing to talk to a sensor. I've got that all working and a lot of the comms stuff which we u开发者_JAVA百科se to communicate the the sensor sits in a .dll. The problem is that I'd like to combine the library into the main executable to avoid having to worry about distributing .dlls.

I've got a demo project which works fine using a .lib but when I try and switch the mani code body to produce a .lib instead of .dll I get the following error:

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'

A bit of googling suggests this happens when you've not got the MSIL switch applied, but it's definitely in there in the library project.

I have a mixture of managed and unmanaged code in both my demo project and the real thing so I'm really struggling to see what the problem is here.

Any suggestions would be very gratefully received!

---

I am guessing a bit, but I suspect the "MyTool" project has the "MyLib" project as one of its "references" ("Project" menu >> Properties >> Common Properties >> References).

When you change the type of the MyLib project to a LIB instead of a DLL, you need to remove "MyLib" from the project references. You then update the project dependencies of the solution ("Project" menu >> "Project Dependencies...") so that MyTool depends on MyLib.

---

If you are linking to a mixed mode (managed/native) DLL you may get this error. Which you shouldn't if the project uses CLR even if one of the source files doesn't. But anyway, if that is the case, then try removing the reference from Project|Properties|Common Properties|References and then re-adding it.

---

I also ran into this. The reason it was failing was because I was compiling my native/managed C++ DLL to target .NET 4.0. And the DLL I was #using was a .NET 2.0 DLL. As such it was failing, even though the paths and file names lined up perfectly. In this case the error message was absolutely of no help at all. I solve it by updating the independent DLL to .NET 4.0. So that both assemblies were using the same .NET framework.