Linking to C++/CLI Static Libraries

So I had this weird problem where I was building a C++/CLI static library that included managed and unmanaged code. I had an unmanaged class that called static functions from a managed class (this is known as mixed mode) and was compiling the whole thing with /clr. When I was building another mixed mode .dll that called the mixed static library, I was getting linker errors to the functions in the static lib's managed classes. I found this on microsoft.public.dotnet.general newsgroup:


Hi all,

I have a .NET solution with several projects in it. One project is a "utilities" project that is compiled into a static library. It contains managed and unmanaged C++ in several files. So I am compiling using managed extensions. This project compiles successfully.

Another project in the solution, BrassControls, is dependent on the Utilities project. It uses several of the classes in Utilities. However, it fails at linking. I get the following error when building the BrassControls project [ -- the class BrassVersion is in the Utilities project]:

LINK : error LNK2020: unresolved token (06000050) Brass.BrassVersion::.ctor
LINK : error LNK2020: unresolved token (06000051) Brass.BrassVersion::.ctor
LINK : error LNK2020: unresolved token (06000052) Brass.BrassVersion::Finalize
LINK : error LNK2020: unresolved token (06000053) Brass.BrassVersion::ToString

These relate to the functions in the Brass::BrassVersion class. This is the only class in the Utilities project that is a __gc class.

I have verified that the project dependencies are set so that BrassControls is dependent on Utilities. But for some reason it can't "see" the tokens associated with BrassVersion.

Both projects are compiled using managed extensions. Both are using the same run-time library.

Can anyone help me figure this out?
Thanks,
Matt.


Ah-ha! This was exactly my problem. Unfortunately, the newsgroup didn't have an answer and it took me a few more hours to find it. The answer is easy... on the .dll that includes the static library, make sure the Linker option for the .dll "Use Dependency Inputs" is set to "Yes". I guess for unmanaged classes it would include them, but for managed classes it wouldn't, so I was getting a linker error (LNK2020) for unresolved tokens. It took me forever to figure this out and really pissed me off. I found the answer here.

Making C#, C++/CLI, and C++ play nicely together

One of my favorite pastimes is to get different computer languages to interoperate. Can't we all just get along?

So one thing I wanted to do was use C# windows forms (and other stuff) with C++ code. The first thing I needed to find out was how to debug such a monstrosity in Visual Studio. Here's how you set up your project to step from C# into C++ land seamlessly:
Debugging in Visual Studio .NET

So the other weird thing I ran into was linker errors. I was trying to reference a mixed code .dll (compiled with /clr) from another native code .dll. Doing Properties->Linker->Input->Additional Dependencies for the project and adding the .dll causes a linker error: LNK1302. Apparently you have two options: compile the .dll with /clr:safe OR include every stupid .obj file for every .cpp file that you have in the .dll you want to include. Another option that I found was to give up on the .dll thing, and just make a statically linked library (change the configuration to produce a .lib instead) for the mixed-code library and then include this in the other native code .dll. Then, I can include the Additional Dependency without difficulty. My project compiles and works as expected for now, though I read somewhere you can get weird initialization problems sometimes when you have mixed-mode libraries. I'll be on the lookout for that gotcha, but for now using .lib's seems to work for me.

In summary, I have C#->C++/CLI .dll -> C++ & C++/CLI .lib
I say C++ & C++/CLI .lib because in some .cpp files I use .NET types (declared as a public ref class), and in others I do not (these are declared as public class).

C++/CLI is very weird... it's sort of like a computer version of Esperanto.

Anyway, this pdf file has some useful general info on C++/CLI etc:
link It's from a book, Expert C++/CLI

XPath, C#, .NET, and namespaces.

So I was trying to use XPath to search this XML document I'm working with using System.Xml in C#/.Net. The obvious thing to use for me was the method SelectSingleNode(). I had read around that you had to be very careful with default namespaces using XPath 1.0 in .Net. In summary, all namespaces must have a prefix, even the default one. You just have to make a prefix up for the default namespace. I chose the imaginative "default" prefix.

Anyway, these were the first couple lines of my XML doc:


<?xml version="1.0" encoding="utf-8"?>
<Specification Standard="802.16e Cor2, 2007" VersionDate="2007-06-21" Company="Sanjole Inc." Author="Min Xu" xmlns="http://sanjole.com/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:msxsl="urn:schemas-microsoft-com:xslt" xsi:schemaLocation="http://sanjole.com/ Sanjole.xsd">


So I have a default namespace. I used the following code, which didn't work:

XmlDocument xmlSpecDoc = new XmlDocument();
xmlSpecDoc.Load(xmlSpecFileName);
XmlNamespaceManager nsmgr = new XmlNamespaceManager(xmlSpecDoc.NameTable);
nsmgr.AddNamespace("default", "http://sanjole.com");
nsmgr.AddNamespace("xsi", "http://www.w3.org/2001/XMLSchema-instance");
nsmgr.AddNamespace("xsl", "http://www.w3.org/1999/XSL/Transform");
nsmgr.AddNamespace("msxsl", "urn:schemas-microsoft-com:xslt");
XmlElement root = xmlSpecDoc.DocumentElement;
XmlNode messageNode = root.SelectSingleNode("/default:Specification", nsmgr);


This returned a messageNode of null, even though it's obviously in the document.

Can you find the bug? Me neither, but my colleague found it... look closely at the default namespace. Give up? It should have been:

nsmgr.AddNamespace("default", "http://sanjole.com/");

That's right... watch your trailing "/"'s. I'm won't reveal how long I was messing with this. Let's just say it was in the range of "hours".