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:

  1. Downloading GDAL sdk from http://www.gisinternals.com/ (64 bit in my case)
  2. Executing the SDKShell.bat script to set the system environment paths, etc.
  3. 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
  4. 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.


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.


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.







dll