06-20-2012 12:41 AM
Hi :
I have dll which was created in dot net , I build application with labview 9 which called this dll using Libraries &Executable ----> call library function
this application works with windows 7 , but I doesn't work with windows XP Bit
just to mention the the dll was complied also under windows 7 and under 32 bit system in order to support all environments
can any one help me why I doesn't work in windows XP
Thanks
06-20-2012 01:49 AM
We can't see the DLL so it's a bit hard to give you ideas. Does it use only .Net functionality or interface to unmanaged DLLs? What .Net version did you target your DLL for? What bitness of OS in both cases? Bitness of installed LabVIEW? Are you sure you have the necessary .Net version and all its dependencies installed on your XP system?
05-30-2013 04:25 PM - edited 05-30-2013 04:29 PM
Hello rolfk,
I have a similar issue. To give at least as much info and answers to your questions:
And for completeness the original error was:
"This application has failed to start because MSVCR100D.dll was not found. Re-installing the application my fix this problem."
Thank you for any assistance.
05-31-2013 01:23 AM
MSVCR100.dll is a Microsoft Visual C++ Redistributable component! However each Visual C version has it's own version, this one is specifically for Visual Studio 2010. So you can't just install any but have to install the right one. There is a chance that MSVCR100.dll is present in your system but somthing is borked up enough that Windows can't load it because it misses other dependencies for that DLL. Rerunning the correct Visual C++ Redistributable installation should fix that. Notice that you might have to install both the 32 bit and 64 bit version on a 64 Bit Windows system.
As to the error messages of the import library wizard, he can't really know what is missing, can he? It's a simple tool that can not know about all the possible software on earth and which of them could be missing, if file xxxyyyzz.h is not found. Besides even if they started such superficial intelligence it would be more often wrong than not.
Macros inside function declaration are indeed a bit "strange". Seems someone tried to outsmart everyone, and potentially himself too.
It does not really matter if the DLL accesses managed or unmanaged interfaces. If the according component is not installed (correctly) on the target system, loading of that DLL fails in either case. The DLL loader is not using any .Net features at all. It is a much lower level Win32 component, which .Net uses too, so it can't really depend on .Net or you would get a so called circular dependency that is almost impossible to manage right.