The type or namespace could not be found

问题:

I'm currently trying to convert a WiX 3.5 custom actions project in Visual Studio 2008 to WiX 3.7 and Visual Studio 2012 and I'm getting the following exception:

The type or namespace name 'MyNamespace' could not be found (are you missing a using directive or an assembly reference?)

The dll is definitely referenced and Visual Studio 2012 has no problem seeing the namespace. Everything under the namespace even pops up in Intellisense, but when I build it I'm getting this exception.

Anyone have an idea of what's going on here?

Additional Info:

The namespace I'm referencing is a .Net 2.0 library and the custom actions project is a .Net 2.0 project.

EDIT:

After further investigation, I'm getting this warning, which I'm guessing is the root of the problem:

The primary reference "MyNamespace, Version=8.5.1.20, Culture=neutral, PublicKeyToken=f593502af6ee46ae, processorArchitecture=MSIL" could not be resolved because it has an indirect dependency on the .NET Framework assembly "mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" which has a higher version "4.0.0.0" than the version "2.0.0.0" in the current target framework.

Why is it trying to use mscorelib 4.0 when this is a 2.0 project?

回答1:

So it turned out that the dll being reference, while compiled to target the .Net 2.0 framework, was being compiled with the 4.0 compiler. Switching the project to compile with the 3.5 compiler solved the problem.

回答2:

This may be completely unrelated but I had a similar issue yesterday. I had accidentally copied a class file (.cs) from one solution into another solution. Clearly, I hadn't added the references to the other solutions.

回答3:

In our case, while the referenced dll was targeting .Net 4.0, it had its own reference to a .Net 4.5.2 dll. The referenced 4.0 framework target led us to believe that 4.5 or 4.5.1 were sufficient to handle things, but they weren't—the referencing project had to be 4.5.2 to handle the dll and all its references.

This was clearly an error on the part of the dll maker.