Namespacing objects in a build makes them "different"

[crelf]

I've got a simple application: There's a "Caller" (a built application that the user opens) and a "Callee" VI on disk that the framework opens - nothing too difficult about that so far.  The Caller has an object in it where I set some stuff, then I want to pass the object to the Callee through it's connector pane:

Then, when called, the Callee displays the stuff to the user:

When I run this in the development environment, it works fine.  When I build it, it works fine too.

When I build the Caller application, if I include dependancies (read: subVIs) in the Caller and Callee that are the same (read: have the same name), calling the Callee from the built Caller won't work: it errors out with the Callee being "broken" (it's not really broken, there's just a namespace collision, so it refuses to load it).  And I'm cool with that - the solution is to namespace the dependancies in the build, which is fine.

So "what's the problem?!?" I hear you ask!

All this worked great until I started trying to pass an object from the Caller to the Calle through the connector pane.  (I think) Since the class is namespaced differently in the built Caller to the non-built Callee, I get

Error 1031 occurred at Open VI Reference in Caller.vi
Possible reason(s): LabVIEW:  VI Reference type does not match VI connector pane. VI Path: C:\Users\christopher_relf\Desktop\Passing Objects between name-spaced application instances\Callee\Code\Callee.vi

...which, as you can imagine, sucks.  I totally understand why it's happeneing, and even agree that this is the way it should be, but that doesn't help me complete my application.
I want to pass an object between a namespaced-exe Caller and a VI Callee - I don't want to deconvolute the object's data to an intermediary (like a variant or string I guess) and rebuild it to a copy of the object on the other side (unless I really have to - but I can't think of a generic way to do it that I like right now).

Does anyone have any bright ideas?  Hopefully I'm missing something easy, right?

I've included an example below.

//Crossposted to LAVA.

[crelf]

PS: I was able to implement a solution in a way that's outside the context of this discussion, although I'd still like to see a solutio to this question.

[Cameron-T]

What version of LabVIEW are you using?

[crelf]

2011SP1

[Cameron-T]

This is similar to a bug that was reported for LabVIEW 2009. It was supposed to have been fixed in LabVIEW 2009 SP1 and should still be fixed in later versions of LabVIEW. I would like to try to build your application in LabVIEW 2009 SP1 and see if it still has that error. Can you post the specifics of your build so that I can recreate it?

Cameron T.

[crelf]

The source and build are attached in a zip to the original post.

[Cameron-T]

It seems like this is being figured out pretty well on the LAVA thread you referenced in your first post. I see that NI Employees are also involved. I recommend you continue the dialogue on LAVA to find an acceptable solution.

Cameron T

[crelf]

Thanks Cameron - I appreciate you taking a look at it.