LabVIEW
Using Labview 8 with MS Visual Studio .net 2003 to create .lsb file
Hi,
I think we are finally getting somewhere!
I will attach the *.log from filemon to this post (sorry it's quite long, but I promise I cleared the *.log-output just before clicking the load button for the vi (still the one from SachaE)). It indeed logs errors related to the runtime libs and files that can't be found. However I am not quite sure what these messages tell me.
Another thing for clarification: I also did NOT have the .NET 2.0 or 1.1 framework installed on the system I run my tests (however I have now, but this didn't change the situation) as I never run tests on my development machine but on a clean system (this means in our case a 'clean' XP with SP2 and all patches, LV 8.20 and the vi from this post.
I also had a look on the policy stuff you mentioned but gave up. Whatever this might have to do with our problem I don't get it...
The C-runtimes for VS 8 (aka VS 2005) are also NOT installed on the target system, but the DLL that will be converted into the LSB file by lvsbutil is NOT linked against them so there should be no need for there presence.
Can you please have a look in the attached file an run your tests on a clean system. I think this is the situation most customers will have as well.
Thanks for the ongoing help.
Regards,
Stefan
I think we are finally getting somewhere!
I will attach the *.log from filemon to this post (sorry it's quite long, but I promise I cleared the *.log-output just before clicking the load button for the vi (still the one from SachaE)). It indeed logs errors related to the runtime libs and files that can't be found. However I am not quite sure what these messages tell me.Another thing for clarification: I also did NOT have the .NET 2.0 or 1.1 framework installed on the system I run my tests (however I have now, but this didn't change the situation) as I never run tests on my development machine but on a clean system (this means in our case a 'clean' XP with SP2 and all patches, LV 8.20 and the vi from this post.
I also had a look on the policy stuff you mentioned but gave up. Whatever this might have to do with our problem I don't get it...
The C-runtimes for VS 8 (aka VS 2005) are also NOT installed on the target system, but the DLL that will be converted into the LSB file by lvsbutil is NOT linked against them so there should be no need for there presence.
Can you please have a look in the attached file an run your tests on a clean system. I think this is the situation most customers will have as well.
Thanks for the ongoing help.
Regards,
Stefan
I really don't understand your reasoning for going with CINs on this anymore!
You say that you would get problems when using your C++ interfaces from a DLL due to compiler differences. While I understand that compilers do have different ways of linking C++ code, I do not understand why this would be a problem with DLLs and not with CIN's as long as you restrict your DLL build toolchain to the same compiler environment you use to create the CIN code. Yes you can not directly call C++ dlls from the Call Library Node but you can create an intermediate DLL that translate the C++ object methods into standard C functions and then call it that way.
What would be the advantages of doing this you ask?
1) you have only one DLL to create instead of many CIN code resources.
2) Modifications to the DLL do not require you to go into every single VI and reload the code resource into a CIN. In fact as long as a specific function is not altered at all in respect to its interface you do not ever have to touch the according VI at all anymore.
3) If you use cdecl as calling convention you can create a project that compiles on multiple platforms and provided you maintain the same function interfaces for all platforms you can use one single VI interfacing to the different DLLs/shared libraries on all the different platforms without one single manual operation in LabVIEW. You just name the library file in the Call Library "myname.*" and LabVIEW will look and dynamically load and link to the appropriate shared library/DLL on that platform.
4) Testing DLLs is much easier as you can use standard envrironments to drive those tests.
5) A LabVIEW compatible DLL interface is virtually 100% compatible with almost any version of Visual Basic and other similar development environments.
So why spend any more time in trying to get CIN issues resolved with every new version of Visual Studio as it generally breaks due to different parameter settings and difference in custom build step handling?
Rolf Kalbermatter
You say that you would get problems when using your C++ interfaces from a DLL due to compiler differences. While I understand that compilers do have different ways of linking C++ code, I do not understand why this would be a problem with DLLs and not with CIN's as long as you restrict your DLL build toolchain to the same compiler environment you use to create the CIN code. Yes you can not directly call C++ dlls from the Call Library Node but you can create an intermediate DLL that translate the C++ object methods into standard C functions and then call it that way.
What would be the advantages of doing this you ask?
1) you have only one DLL to create instead of many CIN code resources.
2) Modifications to the DLL do not require you to go into every single VI and reload the code resource into a CIN. In fact as long as a specific function is not altered at all in respect to its interface you do not ever have to touch the according VI at all anymore.
3) If you use cdecl as calling convention you can create a project that compiles on multiple platforms and provided you maintain the same function interfaces for all platforms you can use one single VI interfacing to the different DLLs/shared libraries on all the different platforms without one single manual operation in LabVIEW. You just name the library file in the Call Library "myname.*" and LabVIEW will look and dynamically load and link to the appropriate shared library/DLL on that platform.
4) Testing DLLs is much easier as you can use standard envrironments to drive those tests.
5) A LabVIEW compatible DLL interface is virtually 100% compatible with almost any version of Visual Basic and other similar development environments.
So why spend any more time in trying to get CIN issues resolved with every new version of Visual Studio as it generally breaks due to different parameter settings and difference in custom build step handling?
Rolf Kalbermatter
