Hi Donlin > Yes,it's really the mpr.dll problem.I notice that on all installed .Net > Framework cann't run my osg app,on all no-installed .Net Framework can run > my osg app freely. > > It may be that the two mpr.dll is different. is it really the problem of > .Net Framework?
The mpr.dll library the OSG normally links to is located in c:\windows\system32 and is part of the core windows system, updated with the Service Pack 2. It has no relation with the .NET framework AFAIK. It may be that a 3rd party library you use is based on the .NET framework (that is, on a specific version of it) and breaks with the latest ones. > > I have copy all necessary osg dlls. > > (my osg app is run on internet use .cab including all dlls zipped in it ,it > can automantic download dlls,when downlaod mpr.dll,it give notice: cann't > copy mpr.dll ,the current mpr.dll is used by system...) You should never download any Windows DLL to the user's system. Never. I know one can find applications that do so, but they are not examples to follow - actually I'd bet that respecting this rule is part of the "windows logo" requirements. > CoreDll.dll I don't know this file - it might be part of a 3rd party lib your application links to. If so, you can (and should) include it in your distribution. > not only the file mpr.dll,there are the files commctrl.dll > ws2_32.dll and ws2help.dll, Same rule applies for those DLLs. Do never include them in your distribution. The user's system must have them installed prior to running your application. It is your responsibility as a programmer to specify a target windows version (through the _WINVER preprocessor macro) that the user must have to make the software run - e.g. if you specify 0x502 (WinXP, SP2) you are guaranteed that a Windows XP system with the SP2 will have the required system libs. > sometimes the file msjava.dll This one often shows in red in the depedency walker, but it has never been a problem for me (it is a either a delay-load DLL that is normally never loaded, or a problem for the dependency walker to find it. In both cases you needn't worry) > msvcr80.dll > msvcp80.dll and mfc80u.dll show errors while copy. The MSV*.DLL files are not part of the system but are system components that you should redistribute along with your application. You can either add them as merge modules in your .MSI installer file if you use them or require the user to install them with the vcredist_x86.exe package. Google for "visual studio redistributable" and download the version that matches your compiler's. You can even silently install them in a pre-install step with the command line: vcredist_x86.exe /q:a /c:"msiexec /i vcredist.msi /qb!" Making proper installation packages on Windows is not easy the first time, but once you get the trick (MSDN is your friend) it is not so complicated - and happens to work. Try to create a blank windows installation in VMWare (the free server edition is perfect for that) and deploy your system on it. Some people advocate the use of the trial-and-error process where you copy your app, try to run it, see why it complains, install the required DLL and loop until it works. This is also a valid approach if you are really lost. Also, note that if you don't have the visual studio runtimes, your application will pop up the unhelpful message "the application is not correctly installed, Re-running the installer may fix the problem" (or something similar). If you do, it will tell you the exact DLL it is looking for. Good luck Regards Thibault _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
