It seem like, after a friend checked the wrap-files with Dependency
Walker, that there are references to msvcr100.dll and msvp100.dll which,
as far as I know, are runtime files from Visual Studio 2010.
is that really as it should be? Should really the result depend on files
from the environment it was compiled in? Must I go back to VSE2008 and
recompile Gdal to make it work on all machines or is there a setting
somewhere...
Yours
Tomas
Tomas R skrev 2010-07-21 09:25:
I have a Gdal-plugin for the eminent program SportTracks. This plugin
gives access to the Gdal libraries for other plugins of the program.
Works great, normally.
But on some, or possibly all, WinXP computers it fails. It fails
setting up the environment for the plugin, the path.
The plugin is written in C#, targeted at .Net2 and also the bindings
and Gdal is compiled with .Net2. Below is the code and the exception
I get.
Anyone with an idea why this fails on WinXp? I have confirmed the
problem on an updated WinXp computer with .Net2 and .Net3.5 installed.
The code is, in short, like this:
path = Environment.GetEnvironmentVariable("PATH");
installPath =
Path.Combine(Path.GetDirectoryName(this.GetType().Assembly.Location),"Gdalbin")
;
path = installPath + ";" + path;
Environment.SetEnvironmentVariable("PATH", path);
OSGeo.GDAL.Gdal.SetConfigOption("GDAL_DATA", Path.Combine(installPath,
"data"));
and it fails on the last line above, it fails to locate/link to the
correct DLL even though the path is correct and the DLLs exist at the
end of the path. I have tested with a shorter path and checked the
framework version of the DLLs at runtime, the managed DLLs that is.
It throws the following exception:
System.TypeInitializationException: The type initializer for
'OSGeo.GDAL.GdalPINVOKE' threw an exception. --->
System.TypeInitializationException: The type initializer for
'SWIGExceptionHelper' threw an exception. --->
System.DllNotFoundException: Unable to load DLL 'gdal_wrap': The
specified module could not be found. (Exception from HRESULT: 0x8007007E)
at
OSGeo.GDAL.GdalPINVOKE.SWIGExceptionHelper.SWIGRegisterExceptionCallbacks_Gdal(ExceptionDelegate
applicationDelegate, ExceptionDelegate arithmeticDelegate,
ExceptionDelegate divideByZeroDelegate, ExceptionDelegate
indexOutOfRangeDelegate, ExceptionDelegate invalidCastDelegate,
ExceptionDelegate invalidOperationDelegate, ExceptionDelegate
ioDelegate, ExceptionDelegate nullReferenceDelegate, ExceptionDelegate
outOfMemoryDelegate, ExceptionDelegate overflowDelegate,
ExceptionDelegate systemExceptionDelegate)
at OSGeo.GDAL.GdalPINVOKE.SWIGExceptionHelper..cctor()
--- End of inner exception stack trace ---
at OSGeo.GDAL.GdalPINVOKE.SWIGExceptionHelper..ctor()
at OSGeo.GDAL.GdalPINVOKE..cctor()
--- End of inner exception stack trace ---
at OSGeo.GDAL.GdalPINVOKE.SetConfigOption(String jarg1, String jarg2)
at OSGeo.GDAL.Gdal.SetConfigOption(String pszKey, String pszValue)
at GDALPlugin.Gdal_Interface..ctor()
please, I am at a loss here.
The path is correct. Is it a framework problem?
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
