Using Labview 8 with MS Visual Studio .net 2003 to create .lsb file

[anotherStefan]

Hi guys,

I am the one in charge of the VIs for the MATRIX VISION grabber cards. I started another thread on this issue (VS2005 compiled CINs result in linker warnings under LV 8 ) but this one seems more lively...

I think I found out what caused the problem, but so far I have no idea what the actual reason is. The reason I work with CINs rather then DLL nodes is rather simple: The functions I am calling belong to C++ interface, which is exported by a DLL. However C++ code can't even called easily when A DLL has been build with one compiler and an application shall be build using another compiler. However this is no problem as the interface exported consists of pure virtual interface classes with NO data members. Anyway back to the problem:

A while ago I converted all the CIN projects from VS6 to VS2005 and started to use VS2005 to compile the code. I tested it using my old LV 5 version and LV 6.i and both worked fine. However under LV 8 I got something like a 'Code Interface Node: LabVIEW subroutine link error'. The help isn't really helpful here as it doesn't tell me what the actual problem is. Has there been a code breaking change in the way LV expects CIN nodes internal structure.

Another possibility might be that VS2005 made error during the conversion of the project as this seems to be more like a beta release to me after reading through several newgroups and having worked with it for some month now...

Anyway to help the poor user I will now recompile all the stuff with VS6 again and then (horrible work) will reload all the *.lsb-files into their CINs (is there some script/command line tool to do that?).

However I would really like to get some answers to these effects...

Stefan

[anotherStefan]

I have modified all the workspaces now and recompiled every *.lsb file using VS 2003 instead of VS 2005. Afterwards I reloaded the generated *.lsb files back into the CINs (I HATE doing this) and build a new installer.

Surprise, surprise: These VIs now work again with LV 8...

I uploaded the stuff including VS 2003 workspaces on our website. You can get your copy from here: http://www.matrixvision.de/functions/count.php?url=products/software/LabVIEW/LabVIEW_SDK.exe

In order to build the stuff (if anyone likes to find out why this doesn't work with LV 8 and VS 2005 (so far this is the only combination I am aware of that does NOT work) you also need this package from our website: http://www.matrixvision.de/functions/count.php?url=products/software/mvAquireControl/mvAcquireControlSDK.exe
and you have to register two environment variables before opening visual studio as described in section 6.1 of the manual that comes with the LabVIEW VIs. Maybe it the VS 2005 project conversion wizard but as the MS people again changed the complete file layout of their makefiles a simple diff will NOT reveal any hint...

Hope anyone can tell me what's going on here...

Regards,

Stefan

[SachaE]

Hi Stefan,

  sorry for the delay. It looks as if there's something specific in the exact process you're going through that generated the .lsb file which then goes into the CIN VI.

I would still recommend not using CIN's and going over to DLL's which would be a lot easier to work with.

The API you're generating doesn't have too many functions in, so this shouldn't be a huge issue, and is definitely worth a try.

I don't want to leave you in the middle of two companies, so if you could get in contact with microsoft to work out the differences and then post back here, that might lead us towards any ideas about what might be going on.

Thanks

Sacha Emery
National Instruments (UK)

[anotherStefan]

Hi SachaE,

no problem with the late response. I haven't been in the office during last week anyway and my workaround with using VS 2003 rather then VS 2005 solved the users problem. However I really want to find out what is going on here. I am pretty sure this will trouble other persons as well in the future and there must be a reason why only LV8 refuses to run with the CIN code I have compiled. I even load the CIN code using LV5 as I always use an older LV version to build my interface for compatibility. So maybe LV8 converts this stuff not entirely correct OR again needs the *.lsb files for reasons I don't know. These however can't be loaded then if they where available (I checked that).

Building a DLL that wraps my DLL would be an option and there is also a newer version (different interface unfortunately) that mostly uses DLL calls now to access our hardware. However this again would be a workaround so I also could stick to the one I am using right now...

Any ideas anybody? This IS a bug (either in LV8 OR in VS2005) and thus the reason should be known, understood and described.

Regards,

Stefan

[SachaE]

Hi,

  I've had a browse around our databases, and it appears that there is an issue with the way that 2005 expects to see the .manifest file :

2005 CRT is an instance of the new SxS (side-by-side) support. This means any unmanaged or managed code that uses it must include the .manifest file as a resource component. We need to update the CIN makefile to detect that we are running the VS.NET 2005 nmake and do the extra step.

This should have been resolved in the new release LabVIEW 8.20 which was released this week.

Can you download the trial version from here, and give that a try with the new makefile in there? (I've checked it and it now includes a manifest action section to it).

http://digital.ni.com/demo.nsf/websearch/14f9ce475127ade786256ac60070926c?opendocument

Thanks
Sacha Emery
National Instruments (UK)

[anotherStefan]

Hi,

thanks for the effort! I just found some time to test your suggestion. Unfortunately the LV 8.20 and using the new cintools files did not improve the situation! VS2005 compiled stuff will just not work with newer releases of LV. Please note, the very same CINs work fine with LV5, LV6 and LV 6.i. I haven't tried LV7 but somewhere between version 6.i and 8.0 must be something drooling under the bed...

Anyway as I have my solution now (NEVER use VS2005 to compile CIN code) I will give up here unless anyone has another bright idea.

Thanks a lot for your help. Someday sooner or later this needs to be fixed anyway...

Stefan

[SachaE]

Hi,

  that's quite wierd. I've just followed the slight modification to the 2003 instructions, and I can build a lsb file that just adds two numbers fine.

Have you tried something that simple yet in LabVIEW 8.2?

Do you have any unmanaged assemblys you're calling back to that have to appear in the manifest?

http://detritus.blogs.com/lycangeek/2006/03/building_cins_w.html

(I've been playing with the code, so hopefully I've uploaded the correct version)

Thanks

Sacha Emery
National Instruments (UK)

[anotherStefan]

And it's getting even weirder: The unmodified VI from your zip archive behaves exactly the same on my machine (Win XP SP2)! It's shows the same error before AND after I have loaded the recompiled lsb file into the CIN. Thus your compiled lsb file already embedded in the CIN doesn't work either...

I attached a screendump of the situation. Can LV produce any more detailed log messages? Can you provide me with a debug build of the modules responsible for this behaviour?

Regards,

Stefan

[anotherStefan]

I forgot some answers:

- no I don't have any stuff that needs to move into the manifest file

Regards,

Stefan

[Lycangeek]

Sorry for the late response to this thread, but I've just come across it. I'm the guy that updated the CIN makefile to work with 2005 and wrote the blog entry describing the issue with the SxS system. I'll be honest that I've not tried downloading any of the code linked about, but thought I would see exactly where we are.  Specifically, Stefan, I'm confused over your last comment. If you are building w/ C or C++, I'd be amazed if you don't need the manifest file since you'll have references out to the C and C++ runtime DLLs.

The screenshot looks like the standard error you'd get if LV fails to load the DLL. Unfortunately, there often isn't a lot of additional error information from the LoadLibrary - often just the error code that the DLL could not be loaded/found. You might want to try it while running the dbgview from www.sysinternals.com and see if you get any other information.

But, if you take the manifest generated by VS.NET and build it into your DLL (either through the makefile I posted or by updating your project w/ the right commands), it should work.

Word of caution - due to the number of steps that have gone on, I strongly recommend you first try to build one of the <labview>\examples\cins examples and make sure that is working - that allows us to seperate a general SxS issue from something specific with your DLL.