I cannot build the solution. The error output is:
Looking at other people's suggestions pointed to missing dependencies. So I checked it:
The properties of a file like Dsofile.dll points to a location on the hard drive. I have checked it and the SourcePath is correct and it is marked as "Exclude" because unmarking it leads to another error. The Dsofile.dll cannot be shared in GAC. So where's the error? The list of dependencies is longer. There is about another 10 SI.ArchiveService.*.dll files.
Dsofile.dll is inprocess COM Server for those who use .NET to interact with Office documents when Office is not installed. But, to do so, one has to install this file. It can be done following
this link.
Do you have installed MS Office? Maybe that is the problem. Also, there are several missing files as can be seen on screenshot (MDIVWCTL.DLL - it is used for Microsoft Office Document Imaging), PDFCreator.exe, etc. You definitely should check if missing assemblies exist on your machine, and if so, change paths to them. But, I suppose that COM Servers don't exist or they are not registered since they should be found if they are properly registered. My recommendation is to reinstall missing components.
Related
Getting error Barcode Engine assembly not found
when trying to implement example "BarcodeReader_ReadBarcodeExample4()" in following link
https://www.leadtools.com/help/leadtools/v19/dh/ba/leadtools.barcode~leadtools.barcode.barcodereader~readbarcode(rasterimage,logicalrectangle,barcodesymbology[],barcodereadoptions[]).html
Any idea?
The most likely cause is that you are missing a reference DLL that needs to be present alongside your program's executable in order for the demo application to function correctly.
The example you mentioned deals with UPC barcode symbologies. This means you will at least need Leadtools.Barcode.OneD.dll in addition to the assemblies you already included.
Also, if you try to load or save images, you will need to add references to file format codecs. For example, if you're going to work with PNG files, you must add Leadtools.codecs.png.dll.
You can refer to the following help page in our documentation to see which assemblies you would specifically need:
https://www.leadtools.com/help/leadtools/v19m/dh/to/filestobeincludedwithyourapplication.html
Note that if you build one of the demo applications that ship with the toolkit, it normally outputs the EXE to the Bin folder where all the assemblies are located. This helps you avoid reference problems during development, but when you deploy your program, you must prepare a list of files you need and include them in your deployment.
If you are still facing problems getting this code to work, feel free to contact LEADTOOLS support by email (support#leadtools.com) or by Live Chat through our website.
I have had the pleasure of using ISLE and its now got to the point where I have to post a question on SO. Ohh the headache.
I have tried added the Extended WPF Tookit via nuget and manually to my application but with no luck getting ISLE to include these assemblies when it builds the installer. I have done a dependency scan in ISLE and in both scenario the dependencies are present.
I am using a TeamCity (v8.1.1) build server to automate the build. Everything works fine except that it will not include the above mentioned assemblies in the package.
How do I solve this problem?
Update #1
With some more research it seems that ISLE on the dev. box picked up a wrong version of log4net.dll while the build server found the correct version.
Resolution - Cleared all log4net.dll found in the "%temp%\Temporary asp.net files" folder.
You solve the problem by turning off dependency scanning and take responsibility for knowing what your applications needs to run and what the best way for deploying it. Dynamic installation authoring has never fully worked and it never will. When you take into consideration all the different kinds of apps and the way they take their dependencies it becomes obvious.
The easy button is an illusion.
I am unaware of why ISLE has these inconsistency and obvious logic problems however I have resolved my issue, albeit the solution is shaky.
Issue #1
Firstly I encountered a XamlParseException due to a TypedInitializationException. An assembly could not be loaded and that assembly was noted in the Exception which turned out to be log4net. The log4net assembly was in the folder however it was the wrong version.
Somehow ISLE found an older version of this assembly in the "%temp%\ASP.NET Temporary files" folder and used that in the package. Clear all these files and give ISLE no choice but to use the assembly you have provided. NOTE: Don't get gungho and delete the culprit assembly if found in the folder of one or more of your installed applications - it just might stop working.
Issue #2
I realized that not only were the Extended WPF Toolkit but the output of a dependent console application was missing from the install directory.
You would expect ISLE to find all dependencies however it doesn't.
Based on the advice provided by ##Christopher Painter I added the primary output of the console application dependency manually. I expected this to solve the console dependency issue however it turned out to solve both.
Now does ISLE break internally if the one of the dependencies is unavailable, locked, or some exception occurred while adding to the output causing it to stop at that point and not add any more dependencies. Who knows, but I am sure there are some flaws within ISLE Microsoft if you are going to ship a 3rd party and only a 3rd party installer ensure that it works properly first.
Update #1
Running the build a second time on the TeamCity server resulted in the Extended WPF Toolkit not being added again. So it seems again the ISLE installer is really shaky.
Issue #3
Another option to solve the missing Extended WPF Toolkit assemblies would have been to add then explicitly as dependencies. ISLE however adds a explicit rather than relative path location to these files meaning that you need to recreate the folder structure on your build server (not good).
If anyone has a better solution I would love to hear it. This request also goes out to Flexera Software and hopefully the answer is not to upgrade to the PRO version or pay for support.
I started to use gdal_csharp dll in my application and read a geotiff file. but it says:
The type initializer for 'OSGeo.GDAL.GdalPINVOKE' threw an exception.
it's my code
string fileName = #"/path to geotiff file";
OSGeo.GDAL.Dataset DS =
OSGeo.GDAL.Gdal.Open(fileName, OSGeo.GDAL.Access.GA_ReadOnly);
can anyone help?
Edit:
I have these dlls
This is the full error message:
It says that cannot load gdal_wrap. But when I'm going to add that dll to my application the below message is shown:
As an update to this there is now GDAL maintained by the SharpMap team as a nuget package here which is updated regularly. You'll need to install both the "GDAL.Native" and "GDAL" package for your project to use the GDAL library. Once installed via nuget, they'll automatically create a "GdalConfiguration.cs" that you call into to initialize the GDAL paths before starting. The only thing to note is the packages are setup to automatically copy their appropriate GDAL libraries to your output build directory. If you need to deploy the application you'll have to do a bit of extra effort.
To solve this one I downloaded the prebuilt libraries as described here and grabbed FWTools from here.
The unmanaged DLLs I used came from \install_dir\FWTools2.4.7\bin and the C# wrapper from \install_dir\FWTools2.4.7\csharp.
gdal14.dll, msvcp71.dll and msvcr71.dll came from here, which is mentioned in that first link.
The error you are receiving re gdal_wrap.dll is referring to one of its dependencies. I threw that DLL into depends and it found a lengthy list of dependent libraries. Note that this list is likely longer due to my use of the FWTools distribution - if you built your version from source it may look different, though the same principles apply.
To get the above code to work on my machine I had the following files in my output directory:
gdal14.dll
gdalconst_csharp.dll
gdalconst_wrap.dll
gdal_csharp.dll
gdal_fw.dll
gdal_wrap.dll
geos_fw.dll
geotiff_fw.dll
hdf5dll.dll
hdf_fw.dll
jpeg12_osgeo.dll
jpeg_osgeo.dll
libcurl.dll
libeay32.dll
libexpat.dll
libmysql.dll
libpq.dll
libtiff_fw.dll
lti_dsdk_dll.dll
mfhdf_fw.dll
msvcp71.dll
msvcr71.dll
NCScnet_fw.dll
NCSEcw_fw.dll
NCSUtil_fw.dll
netcdf.dll
ogdi_32b1.dll
proj.dll
sqlite3.dll
ssleay32.dll
szlibdll.dll
xerces-c_2_7.dll
zlib1.dll
zlib_osgeo.dll
Now these don't necessarily all have to live in the output directory - as long as they are on your path somewhere (e.g., \Windows\System32) you should be fine.
I know it's an old question, but I believe my answer might help someone.
I was able to successfully compile and run examples using c# gdal by doing the following:
Downloading GDAL sdk from http://www.gisinternals.com/ (64 bit in my case)
Executing the SDKShell.bat script to set the system environment paths, etc.
Creating a project in Visual Studio. And referencing all .net dlls (the ones that names end with _csharp.dll), located in \bin\gdal\csharp\ inside downloaded SDK
Setting platform target in Visual Studio project settings to x64 to get rid og bad image format exceptions. The last step wouldn't be necessary if I'd choosse 32bit version of SDK to work with.
I did not install fwtools at all. It seems like the last build of fw_tools is relatively old, and sdk is still maintained.
I know this is a reasonably old question now, but I found this in google after researching the same problem myself, so this means that for searches on this error this is still a very relevant page to update given it's still in the top 5 from the big G when the same problem is searched.
In my case it was the answers from "DeusExMachina25" and "Grzegorz Sławecki" that struck a chord.
I'm writing some software that makes use of the current builds of "sharp map" on NUGet (as of 24th of June 2016) and my software kept throwing the same gdal_wrap message as the OP originally reported, even though I'm using the GDAL package provided by the Sharpmap team.
I didn't realize that the NUGet installer for the package had installed a configuration class for me, but after reading through this thread and finding out that it does I went looking for it.
Sure enough I found the file 'GdalConfiguration.cs' in my project and added a call to it in an appropriate place in my project, expecting GDAL to be initialized correctly.
However, after I did this, I still had the same problem.
So, I set a break point on the beginning of the GDAL routine that had been added, and waited until the break point was hit.
I then traced through the method, and eventually found the following line:
var gdalPath = Path.Combine(executingDirectory, "gdal");
at around line 64 in the file.
Tracing through this, I noticed that the path being built was:
d:\geodata\maptest\maptest\bin\debug\gdal
but the NUGet installer had installed all the dependent assemblies in
d:\geodata\maptest\maptest\bin\debug
Exactly where I expected them to be.
I changed line 64 so that it now read:
var gdalPath = Path.Combine(executingDirectory, "");
and voila, the error went away and everything started to work.
I could have done things the other way too, and created a folder called gdal, then copied everything into that, but that then would have gotten deleted when I did a "clean" on the project.
Since the config class, set's up various environment variables based on this path, quickly changing that one line also fixes up the path for the GDAL data files , plugins and a few other things too.
You could try using Dependency Walker to see if there are any dlls that gdal_csharp is trying to grab but cannot.
Have you added the path to your GDAL libraries to your PATH environment variable? I downloaded my files from http://vbkto.dyndns.org/sdk/?_sm_au_=iVVqjsHS2n46WP00 and here's my path: C:\libs\release-1600-gdal-1-9-mapserver-6-2\bin.
To use the C#-bindings of GDAL you need an installation of FWTools (from http://fwtools.maptools.org/) as well as the most current binaries that match your system (from http://vbkto.dyndns.org/sdk/). Afterwards it is important to include the bin-directory of FWTools (example for 64bit-systems: C:\Program Files (x86)\FWTools2.4.7\bin) in your PATH variable as well as the necessary dlls (gdal_csharp.dll was mentioned in the question) in your Visual Studio project references. I outlined the complete processs here.
This process works on 32 bit as well as 64 bit systems, I tested it with VS 2010 and 2012.
Remove the path to python from the system variables. Because the main gdal paths conflict with python 27
Did you forget to:
GdalConfiguration.ConfigureGdal();
GdalConfiguration.ConfigureOgr();
Gdal.AllRegister();
Ogr.RegisterAll();
In my case the issue was:
I had 2 projects in my solution: ProjectA and ProjectB
I was executing ProjectA, and ProjectA was referencing ProjectB
ProjectB is the one that contained the references to both GDAL and GDAL.Native
ProjectA tried to find GDAL.Native's files under ProjectA\bin\Debug\netcoreapp3.1\gdal ... but in reality those files are under ProjectB\bin\Debug\netcoreapp3.1\gdal
Possible solutions:
Dirty solution: just copy the files from ProjectB under ProjectA\bin\Debug\netcoreapp3.1
Okayish solution: add the GDAL.Native package to each one of your "entry projects"
I don't like either of those solutions. This stuff happens under GdalConfiguration.cs, so maybe there is a way to modify it to find the correct path.
I started to use gdal_csharp dll in my application and read a geotiff file. but it says:
The type initializer for 'OSGeo.GDAL.GdalPINVOKE' threw an exception.
it's my code
string fileName = #"/path to geotiff file";
OSGeo.GDAL.Dataset DS =
OSGeo.GDAL.Gdal.Open(fileName, OSGeo.GDAL.Access.GA_ReadOnly);
can anyone help?
Edit:
I have these dlls
This is the full error message:
It says that cannot load gdal_wrap. But when I'm going to add that dll to my application the below message is shown:
As an update to this there is now GDAL maintained by the SharpMap team as a nuget package here which is updated regularly. You'll need to install both the "GDAL.Native" and "GDAL" package for your project to use the GDAL library. Once installed via nuget, they'll automatically create a "GdalConfiguration.cs" that you call into to initialize the GDAL paths before starting. The only thing to note is the packages are setup to automatically copy their appropriate GDAL libraries to your output build directory. If you need to deploy the application you'll have to do a bit of extra effort.
To solve this one I downloaded the prebuilt libraries as described here and grabbed FWTools from here.
The unmanaged DLLs I used came from \install_dir\FWTools2.4.7\bin and the C# wrapper from \install_dir\FWTools2.4.7\csharp.
gdal14.dll, msvcp71.dll and msvcr71.dll came from here, which is mentioned in that first link.
The error you are receiving re gdal_wrap.dll is referring to one of its dependencies. I threw that DLL into depends and it found a lengthy list of dependent libraries. Note that this list is likely longer due to my use of the FWTools distribution - if you built your version from source it may look different, though the same principles apply.
To get the above code to work on my machine I had the following files in my output directory:
gdal14.dll
gdalconst_csharp.dll
gdalconst_wrap.dll
gdal_csharp.dll
gdal_fw.dll
gdal_wrap.dll
geos_fw.dll
geotiff_fw.dll
hdf5dll.dll
hdf_fw.dll
jpeg12_osgeo.dll
jpeg_osgeo.dll
libcurl.dll
libeay32.dll
libexpat.dll
libmysql.dll
libpq.dll
libtiff_fw.dll
lti_dsdk_dll.dll
mfhdf_fw.dll
msvcp71.dll
msvcr71.dll
NCScnet_fw.dll
NCSEcw_fw.dll
NCSUtil_fw.dll
netcdf.dll
ogdi_32b1.dll
proj.dll
sqlite3.dll
ssleay32.dll
szlibdll.dll
xerces-c_2_7.dll
zlib1.dll
zlib_osgeo.dll
Now these don't necessarily all have to live in the output directory - as long as they are on your path somewhere (e.g., \Windows\System32) you should be fine.
I know it's an old question, but I believe my answer might help someone.
I was able to successfully compile and run examples using c# gdal by doing the following:
Downloading GDAL sdk from http://www.gisinternals.com/ (64 bit in my case)
Executing the SDKShell.bat script to set the system environment paths, etc.
Creating a project in Visual Studio. And referencing all .net dlls (the ones that names end with _csharp.dll), located in \bin\gdal\csharp\ inside downloaded SDK
Setting platform target in Visual Studio project settings to x64 to get rid og bad image format exceptions. The last step wouldn't be necessary if I'd choosse 32bit version of SDK to work with.
I did not install fwtools at all. It seems like the last build of fw_tools is relatively old, and sdk is still maintained.
I know this is a reasonably old question now, but I found this in google after researching the same problem myself, so this means that for searches on this error this is still a very relevant page to update given it's still in the top 5 from the big G when the same problem is searched.
In my case it was the answers from "DeusExMachina25" and "Grzegorz Sławecki" that struck a chord.
I'm writing some software that makes use of the current builds of "sharp map" on NUGet (as of 24th of June 2016) and my software kept throwing the same gdal_wrap message as the OP originally reported, even though I'm using the GDAL package provided by the Sharpmap team.
I didn't realize that the NUGet installer for the package had installed a configuration class for me, but after reading through this thread and finding out that it does I went looking for it.
Sure enough I found the file 'GdalConfiguration.cs' in my project and added a call to it in an appropriate place in my project, expecting GDAL to be initialized correctly.
However, after I did this, I still had the same problem.
So, I set a break point on the beginning of the GDAL routine that had been added, and waited until the break point was hit.
I then traced through the method, and eventually found the following line:
var gdalPath = Path.Combine(executingDirectory, "gdal");
at around line 64 in the file.
Tracing through this, I noticed that the path being built was:
d:\geodata\maptest\maptest\bin\debug\gdal
but the NUGet installer had installed all the dependent assemblies in
d:\geodata\maptest\maptest\bin\debug
Exactly where I expected them to be.
I changed line 64 so that it now read:
var gdalPath = Path.Combine(executingDirectory, "");
and voila, the error went away and everything started to work.
I could have done things the other way too, and created a folder called gdal, then copied everything into that, but that then would have gotten deleted when I did a "clean" on the project.
Since the config class, set's up various environment variables based on this path, quickly changing that one line also fixes up the path for the GDAL data files , plugins and a few other things too.
You could try using Dependency Walker to see if there are any dlls that gdal_csharp is trying to grab but cannot.
Have you added the path to your GDAL libraries to your PATH environment variable? I downloaded my files from http://vbkto.dyndns.org/sdk/?_sm_au_=iVVqjsHS2n46WP00 and here's my path: C:\libs\release-1600-gdal-1-9-mapserver-6-2\bin.
To use the C#-bindings of GDAL you need an installation of FWTools (from http://fwtools.maptools.org/) as well as the most current binaries that match your system (from http://vbkto.dyndns.org/sdk/). Afterwards it is important to include the bin-directory of FWTools (example for 64bit-systems: C:\Program Files (x86)\FWTools2.4.7\bin) in your PATH variable as well as the necessary dlls (gdal_csharp.dll was mentioned in the question) in your Visual Studio project references. I outlined the complete processs here.
This process works on 32 bit as well as 64 bit systems, I tested it with VS 2010 and 2012.
Remove the path to python from the system variables. Because the main gdal paths conflict with python 27
Did you forget to:
GdalConfiguration.ConfigureGdal();
GdalConfiguration.ConfigureOgr();
Gdal.AllRegister();
Ogr.RegisterAll();
In my case the issue was:
I had 2 projects in my solution: ProjectA and ProjectB
I was executing ProjectA, and ProjectA was referencing ProjectB
ProjectB is the one that contained the references to both GDAL and GDAL.Native
ProjectA tried to find GDAL.Native's files under ProjectA\bin\Debug\netcoreapp3.1\gdal ... but in reality those files are under ProjectB\bin\Debug\netcoreapp3.1\gdal
Possible solutions:
Dirty solution: just copy the files from ProjectB under ProjectA\bin\Debug\netcoreapp3.1
Okayish solution: add the GDAL.Native package to each one of your "entry projects"
I don't like either of those solutions. This stuff happens under GdalConfiguration.cs, so maybe there is a way to modify it to find the correct path.
So I recently updated my software and with the new version I supply a new dll-file, lets call it My.dll. Now, the old version works just fine on every computer I have tried.
The problems began with the new version. Specifically, so far on at least one computer, it states that "Could not load file or assembly My.dll". This even happens when I have dropped a copy of the software on a network drive and run the software directly from there. It works on every other computer but one, which still gives the exact same error where other computers work fine.
The dll in question is even in the same directory as the executable, so I'm really quite bummed here. I tried to google around a bit as well, but all the issues I found were related to ASP.NET specifically. Any ideas on how to go about finding the problem would be much appreciated.
It is possible that the computer in question has a DLL added to it's Global assembly cache. This would take priority over the DLL in the same folder.
More information about the GAC: http://msdn.microsoft.com/en-us/library/yf1d93sz(v=VS.100).aspx
Is there an old copy of the DLL lying around? Perhaps with a different name? I had a similar issue when I changed the name of a dll. Internally, the namespaces were the same.
In my case, an older version of the DLL was still there. .NET got confused with two assemblies in the bin directory having the exact same namespaces and classes, couldn't decide on which to load, and threw an exception.
Removing the older version of the dll solved the issue.
Use the Assembly binding log viewer and set it to log failures. This will give you some clues as to why it is not loading.
You could take a look at the error log using the Assembly Binding Log Viewer. First you have to turn on logging.
--Right Click on Project
--Goto Properties->Build tab
--Change Platform and Platform Target to Any CPU, Save and run