c# - without - visual studio package dll into exe
C#: How to include dependent DLLs? (4)
How are you deploying? Just flat files? If so, it should work as long as the file ends up in the project output directory. Does it?
If you are using another deployment, you will need to tell that engine to include it. This is different for each of msi/ClickOnce/etc.
I am using a 3rd party API which is defined in 2 DLLs. I have included those DLLs in my project and set references to them. So far so good.
However, these DLLs have at least one dependent DLL which cannot be found at runtime. I copied the missing DLL into the project and set the 'Copy to output' flag but without success.
What should I be doing here to tell the project where it should find the dependent DLL?
Clarification I tried adding a reference to the missing DLL but as it wasn't recognised as a .Net component. In desperation, I added it directly to the output folder but without success.
Finally, I installed the API on the PC and it all worked. The installation sets the PATH variable and the DLL is found in the installation folder. But how to tell the project to look in one of its internal folders?
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.batscript 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.
The unmanaged DLLs I used came from
\install_dir\FWTools2.4.7\bin and the C# wrapper from
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.
You can either slowly add the downstream dependencies as references to your project. This is cumbersome, and somewhat fragile
Or your could use a tool like "Depends.exe" from microsoft to inspect your top level assemblies and get a reference list to the dependencies.