Trouble with enum type from .NET assembly in Labview

[thfwong]

I ran into a problem using assembly from Labview 7.1.  In my .NET assembly I defined an enum data type which I use in one of the interface's method.  This works well until I updated the enum type and got the following runtime error,

------------------------------------------------------------------
Value cannot be null.
Parameter name: types in my.vi
------------------------------------------------------------------

The resolution is to reselect  the method and recreate all the indicator/control/constant of that enum type.

My question is how does Labview handles .NET assembly enum type ?
Is there something I can do in my assembly code (managed C++)  and/or Labview code to automatically update the enum type in Labview ?

Thanks.

[Lycangeek]

LV attempts to convert .NET enums into LV enums where possible. There may have been a problem there.

Another thing to consider is whether the version of the assembly changed and whether your assembly is stored in the GAC.

Either way, could you post the enum definition? I'm curious to try this out.

[thfwong]

Hi Brian,

I registered the assembly in GAC and have incremented my version number in file AssemblyInfo.cpp.   Here is declaration for the enum and a class that uses it,

-----------------------------------------------------------------------------------------------------------------------------------------------------------------

typedef public __value enum OperatingMode

{

ResetMode,

DownloadMode,

NormalOperatingMode

//TestMode  /* removed in production release */

} OperatingMode;

public __gc class IFoo : public IDisposable

{

public:

IFoo ();

~IFoo ();

//*** Functions that uses OperatingMode ***//

Void SetMode([InAttribute] OperatingMode mode);

OperatingMode QueryMode();

};

// end class IFoo

-----------------------------------------------------------------------------------------------------------------------------------------------------------------

Regards,

Tony Wong

Nortel Networks

[Lycangeek]

I thought that might be what was going on. When you are dealing with the GAC, version numbers become the new DLL Hell.

Basically the way it works in .NET is that any assembly that is signed (doesn't actually have to be in the GAC) is called Strongly Named. When this happens, you must ask for the EXACT same version for .NET tells you it can't find the file. When you drop down the various nodes in the LV diagram we store the full name (version included) of the assembly. When we try to convert the LV data to .NET data, we take a look at what the .NET type was when you wrote the VI. This tells us to look for the previous version of the assembly. Since .NET is not forgiving in this case, it says it doesn't know anything about that type. Thus the conversion fails.

If you had not signed the assembly, then we would be loading the assembly based on the file location, not on the version and the problem would not show up. If you can, when you are going to be making changes to the assembly, keeping the version the same or working outside of the GAC would make life easier.

[thfwong]

Actually I increment the version everytime I release my assembly and I only see this problem when the enum type changes.   When I open up Labview it would detect the old version is no longer in the GAC and would popup a message to warn me to reselect the assembly.  If the interface signature didn't change than I can run the VI without any issue.  If a method was deleted and/or changed than Labview would show a "broken arrow" and I can click on the "broken arrow' button and Labview would bring up the broken code.   With enum type Labview does not detect the change and I would have to run the VI and get the previously mentioned runtime error to find the problem.   Ideally a "broken arrow" is more desirable because I would not have to exercise all test cases (both norminal and exception) to relink my VI's with the assembly.

[Lycangeek]

That isn't the experience I've been having. Question - do you remove the older version of the assembly from the GAC when you install the new one?

[thfwong]

I remove the old version from the GAC before registering the new version into GAC.  I do this from within my Visual Studio Project Pre-Build Event and Post_Build Event so it gets done everytime I recompile my assembly object project.

[Lycangeek]

Okay. Let's see if we can't sync up on this so that I know I am doing the same steps.

You build a strongly named assembly, say 1.0, and put it into the GAC.

You then build a VI using that, specifically the enum

You then close LV, build a 1.1 version of the assembly with no changes to the enum. Put that into the GAC, removing the old one.

You then load the VI in LV and are told that you should add 1.0 to the ref list because we can't find it.

What then?

[Lycangeek]

For extra clarification, I do what I just posted. Attached is what the VI looks like.

When I get the error for the 1.1 version, I select the constructor node, right click and say "Select Constructor". I then go and pick the same type out of the 1.1 version of the assembly.

Even when this is done - absolutely no change between 1.0 and 1.1, the SetMode node breaks. If I do an inplace replace of the SetMode, everything works.

[thfwong]

Looks like I have this problem even if I don't change the enum type if the enum type is used as [InAttribute].  It works OK if it is used as [OutAttribute].  Is there a way to get around this issue so I can increment the version number without having to recreate all the control/constant/indicator for enum type ?