Cannot easily create "mscorlib.fp" from.NET Framework 2.0, too many names are too long

[JumperBones]

Hello all CVI adventurers,

After searching this CVI forum, I am surprised that I seem to be the first one to encounter this...

If you point the CVI 8.0.1 .NET Controller Wizard at "mscorlib" version 2.0.0.0 in the Global Assembly Cache (which I need to support a set of .NET assemblies in my application), the following events occur:

1.) It notices that I am creating a .NET controller for the mscorlib, advises me it will take a long time for CVI to browse and compile a CVI wrapper for this assembly, and that CVI ships with one with the same name already in the samples/dotnet directory.  But it also advises me that it may not be the correct version I would want (the one that ships in the CVI samples directory is for version 1.0.5000.0, and I need the one for .NET Framework 2.0), and offers the oprions of cancelling r continuing.

2.) So I said for it to continue, and after a full ten mintues or more of CVI browsing and compiling this assembly, it hung before it could create the object file because of truncation in many of the function names (becase they are too long and  the names became duplicated as a result).

So I looked at the names it reported as being too long, and there are a LOT of them.  Way too many to hand-edit.

I am dead in the water now, unless anyone has already got past this issue and is willing to offer their mscorlib.fp package to the rest of us.

Or is there a way to limit which portions of the assembly is "wrapped", as the ActiveX Controller Wizard allows you to do?

Please help,

Jumper Bones

[JumperBones]

...replying to my own posting from yesterday...

I took the time this morning to actually hand-edit each of the "mscorlib" 2.0.0.0 names that were to long for the CVI 8.0.1 .NET controller wizard to handle (there were dozens and dozens of them).  It then created the Function Panel, C-source and C-header files, and then stopped when it tried to compile this new instrument driver into the current (empty) project window.  I saved the errors into a text file from the wizard's attempt at compiling this driver.  Interestingly enough, all the errors were in the header file.

It would be great if someone at NI or where-ever could assist me with completing this, I feel I'm amost there.

Let me know if I should be calling in a support ticket number, or if I should work it out here for all to view.

I can attach the 3 files it created, plus the error list I saved, in a ZIP file to my next posting here.

The ZIP is only 2.3 MB, but explodes to over 40 MB.

In case anyone is curious, I am running WinXP Pro SP2 with all the latest Microsoft patches and updates as of yesterday.

Jumper Bones

[Mohan]

Hi,

I was able to run CVI 8.0.1 and generate wrapper for mscorlib version 2.0 on my system. I did get the warning/errors dialog from the .NET Controller Wizard with a list of .NET methods it could not generate function panels for as the names were too long. But note that these functions are available in the source and header files; it is just that the names were too long for the FP file. You can still call these functions in your code. If you got errors other than the above, say from the CVI compiler, please do post the errors in this thread. Renaming the identifiers can be tricky because it could result in duplicates or other conflicts - I typically avoid this as I do not care much about the lack of a few function panels.

It did take a long time to compile - this is mainly because the CVI compiler generates a lot of extra information (browse, debug, etc) in debug configuration. Unfortunately CVI cannot process events during this phase, and so appears to hang but it is really just compiling. You can make this considerably faster if you change the build configuration to Release before running the .NET Controller Wizard. Another time-consuming issue you should look out for is the following: if the instrument (.fp) is attached to the source (this what happens by default) then CVI will recompile the source each time it loads the FP and this will again take a really long time in debug configuration. To avoid this, open the generated source in CVI and use the Option >> Create Object File item to generate a .obj file in Release configuration, and then edit the instrument (Instrument >> Edit) and detach it and reattach it to the object file.

By the way, CVI 8.1 ships with the wrapper for mscorlib version 2.0. But this wrapper would not work with CVI 8.0.1 because it uses the newer CVI 8.1 functions for supporting generics.

[JumperBones]

Mohan,

I was looking for a reason to upgrade to version 8.1, and your statement that it has version 2.0 of the mscorlib has prompted me to begin downloading it as I write this.  Funny how this update was not in my Developer Suite SSP CD set for November 2006, because it seems it came out in that time-frame (it must have missed the CD-production deadline to their vendor in Ireland by barely a week or so).

I am attaching the ZIP archive of my failed attempt that I mentioned in my earlier posting (above).

Even though I will not need to finish it after I do this upgrade, there may be others who must stick with 8.0.1 who would like us to bring this solution to closure.  I will work on it with you if you want in my other seat of CVI 8.0.1 that I won't upgrade yet...

Yes, I learned the trick of creating and keeping the object file side-by-side with the FP file (or having the DLL in the path) when opening a project with an FP in it a long time ago.  It seems the priority for automatic attachment goes from DLL, to OBJ, to C-source, when you have more than one of those available to the FP file.  Yet I have never found where this was fully documented in the CVI manual set (remember those?) or in the new CVI help file.

I never thought about switching to release mode before running the .NET or ActiveX wizards.  (Doh!)

Speaking of DLLs, one of the issues I'm sure to encounter after we get past this OBJ hurdle is creating a DLL from all this wrapper-code.  I can't tell you how many times I got the errors on the "ODL" file that prevent me from going all the way to the finish-line in creating a DLL from the FP file when selecting Options>>Create DLL Project.

I've even hand-edited those ODL-file errors to complete the DLL creation process using the command-line executable that CVI puts on your clipboard when this happens.  I would love to learn of any tricks you might know in this area if we run into that with this one...

Thanks for your awesome reply, I gave you 5 out of 5 stars for it...

Jumper Bones

[Mohan]

Hi,

I am attaching the fixed files and the compiled obj file (release configuration, MSVC compatibility mode). Basically, I had to globally replace System_Char to unsigned short and System_Byte to char, and fix up the body of System_IO_UnmanagedMemoryStream_Get_PositionPointer. These errors are not present in the CVI 8.1 generated files. Also, the PositionPointer property is not exposed in 8.1 as this property is a .NET pointer - CVI 8.1 does not support .NET pointer parameters. CVI 8.0.1 was incorrectly exposing this. Hope this helps.

[JumperBones]

Thank you Mohan,

Everything is working fine for me.  I was able to get the your version 8.0.1 of "mscorlib20.fp" working fine, along with creating the DLL for it as well.  I have a question related to this CVI .NET Controller wizard:

I have custom .NET assemblies that our company has created that I have been able to use the .NET controller wizard on, and have been able to create instrument driver DLLs.  For those components, it would be desirable (but not necessary) to create a type library for these CVI DLLs, but when I try to do that it stops when it tries to process the ODL file.  An example of where it typically gets caught is on the third line of the ODL file when it enounters its first typedef.

typedef [public] struct __BWS_BwsApiException *BWS_BwsApiException;

The problem is the "[public]" definition, but I am not sure how to get past that.  Could you assist me?

JB

[Mohan]

Hi,

I am assuming that you are building a DLL using the generated wrapper files and using the generated .fp file as input for the typelibrary. You are probably exporting the DLL symbols using the generated header file. I tried doing this with the wrapper files in the WebServer dotnet example and ran into two issues:

1) The generated wrappers use struct pointer type definitions to make the handles type-safe. But CVI does not seem to support functions with structs and struct pointers when exporting typelibraries.

2) The FP Class name for each wrapped .NET class is the same as the handle type name. This causes a type redefinition when compiling the ODL.

You can workaround item 2) simply by renaming the FP classes (say by adding a "Class" suffix) in the .fp file.

To workaround 1) you can hack the generated header file and change the handle type-definitions to int typedefs. For example:

typedef int WebServiceX_USZip instead of typedef struct __WebServiceX_USZip * WebServiceX_USZip

And you must also change the CDotNetHandle typedef in cvidotnet.h to:

typedef int  CDotNetHandle;

I do not recommend doing the above as it involves changing the library and generated files and losing type-safety of handles. A better approach is to wrap the generated functions in another API that does not use structs, struct pointers, etc - the above hack achieves the same but at the considerable expense of messing up library and generated files.

A type library is normally used when you have to call the DLL from another language (not C/C++). If this is the case, you may want to consider calling the underlying .NET assembly directly in that language rather than going through the CVI generated wrappers. Even if .NET is not directly supported, you can wrap your .NET assembly as a COM (ActiveX) server with typelibrary and call it from your other language/environment. I think this is a considerably cleaner approach.

[JumperBones]

You are correct in assuming I am building a DLL using the generated wrapper files and using the generated .fp file as input for the type library.

And since this .NET application I am trying to create a type library for has hundreds of functions exposed via the header file, I obviously will not be performing those hacks.  However, I can see in the future there will be times where I might decide to do this in other situations.

I thank you for your replies, you have been most helpful,

JB