The InAttribute isn't needed anyway as you are passing in a valuetype - it is always in (although obviously changing it to an out isn't going to work). The In/Out attributes are only used (in managed C++) to give hints to the marshaller on what needs to be copied when. In C# you get an added bonus in that the compiler enforces some stuff for out types versus ref types, but it is just the compiler - the .NET CLR doesn't care.
Unfortunately there really isn't a solution here. As I mentioned earlier, the problem is that each node knows what type it is expecting (and version is key because it is a strongly named assembly). So when the SetMode is called, we can't do the data conversion because we can't find the type. Also, because LV is using Assembly::LoadFrom() (see
http://detritus.blogs.com/lycangeek/2005/03/labview_and_ass.html and the subsequent posts), .NET won't use the version policies.
So, in Constellation, when we switch to using Assembly::Load() instead, you can use the .NET version policies to tell the .NET CLR to treat any request for assembly version X as a request for Y. You can even have the version policy updated as part of your build script if you wanted. Thus you can work around this problem. Hmmm, sounds like a good topic to post on in my blog...
It is actually a tough problem to solve for all cases. Consider the flip side: Your production system is spec'ed at .NET 1.1. On your development machine you have .NET 2.0 installed. When LV starts up on the dev machine, it only has access to the .NET 2.0 framework - you can't load 1.1 framework assemblies. You obviously don't want us to automatically convert the VI to be all .NET 2.0 based and thus make it impossible for you to modify the VI and send back to production.
Anyway, I know I just through a bunch of low level .NET stuff around here - if you or anyone reading this post would like me to go into more details on this, please feel free to post a question or just email me at
bloggingbrian@gmail.com.
