We Keep Coding

SharpMap -Gdal Raster Layer, The type initializer for 'SharpMap.Layers.GdalRasterLayer' threw an exception [duplicate]

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.

Exception while using GDAL in C#

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.

Building C# App with Internal DLLs

Is there a way to keep any DLLs needed for my Visual C# program (such as SQLite) inside the actual EXE so it doesn't require the files to be present?
If not, can anyone show me how to make a wrapper for my program (independent of .NET, so maybe C++?) to copy/load required files to the working directory before starting the program itself.
What I intend to end up with is a single EXE file that can be deployed anywhere and set itself up like a transformer. All it requires is the following criteria:
SQLite is present
OpenHardwareMonitorLib is present
.NET 2.0 is installed (if not, offer install with redistributable package)

Microsoft provide a tool for merging DLLs. It's called ILMerge.
It doesn't always work, I believe certain things can cause problems. But it's definitely the easier option!

If the problem is redistribute only one file, you can create a "installer" exe, that unpack all your dependencies (from executable content).
If you don't want to leave all dlls in your production environment, you can merge all IL code in the main executable. you can use ILMerge (but it's not the only product that can do this)

You can merge the dependencies into the main executable. After your build completes you run an additional tool that combines the IL code into a single assembly.
ILMerge can do this but is a bit cumbersome to use.
Some (proprietary) tools can do this as well. I know of at least one obfuscator (DeepSea) that can do this. DeepSea also allows you to specify what you want to include and what types you want to expose from the resulting assembly.
Full disclosure: I know the guys that build DeepSea Obfuscator.

I guess you could embed the target assemblies as resources and then unpack them in some custom assembly resolution code?
Edit: there's an example of this here: Embedding assemblies inside another assembly

Which configuration do I need to use an external DLL in a WinForms application?

I'm working with an external DLL to consume an OCR device using a wrapper written by me. I have made tests on the wrapper and it works perfectly. But, when I use a WinForms project to consume the client class of the wrapper (located an another project), an error arises when calling C# methods imported from the DLL (using [DLLImport(...)]) saying that the DLL is not registered.
The error says:
"DLL Library function no found. Check registry install path."
All executions have been made in debug mode.
I've compared both projects configuration. The most relevant difference is that Test project is oriented to Any CPU and WinForms app only points to x86.
What could it be?
Updates
I've tried to register the dll using Regsvr32.exe but it didn't work. I thought about using Gacutil.exe but it required to uninstall all frameworks beyond .net framework 1.1...
I was wondering... at testing environment probably everything works well because testing framework has its dll's or executable files (or something like that) totally registered in windows, so those are trusted dlls. It is possible that debug generated dlls are not trusted by windows and therefore this problem arises?
I've created a form in the same troubling project and then I call the OCRWrapper from a button I've added to it. The OCR's worked!!. Unfortunately, it is difficult to rewrite the first form because we have invested a lot of hours in it; so, I'm still wondering what do I need to change in the troubling form...
I started again the form's development from scratch and added all the components related to it; everything worked well, the OCR read succesfully all data. When I loaded a combo box using a call to an ObjectContext and the error appeared again... I'm using an entity framework connected to Oracle.

I have a theory.
Let's imagine the following situation:
The ocr.dll depends on some other native DLL, lets call it other.dll [A].
In case this is a static dependency, you'll see it through Dependency Walker.
If its dynamic, you can use Sysinternals Process Explorer to monitor DLL loading in your working test project at run-time.
Your ADO.NET provider uses native DLLs under the hood (this is certainly true for ODP.NET) which depend on other.dll [B], which happens to have the same name but is actually a different DLL (or at least a different version) compared to other.dll [A].
Then, in run-time, this might happen:
When you connect to the database, ADO.NET provider dynamically loads its native DLLs, including the other.dll [B].
Then you try to call a function from OCR DLL. The P/Invoke tries to load the OCR DLL dynamically and succeeds, but the other.dll [B] is already loaded and ocr.dll tries to use some function from it, instead from other.dll [A] where it actually exists.
Welcome to DLL hell. So what can you do?
Try varying the order of calls to ocr.dll and ADO.NET provider to see anything changes. If you are (very) lucky, other.dll [A] might actually be a newer version that is still backward-compatible with other.dll [B] and things migh magically start to work.
Try another version of ADO.NET provider.
Try another ADO.NET provider.
Try getting a statically-linked ocr.dll from your vendor (i.e. no run-time dependency on other.dll [A]).

So, the call to the DLL works from a single button, but it does not work from a complex form. I'd say that there is an undefined behavior going on. The question remains whether it is you, that wrote the marshalling incorrectly, or it the DLL that is badly written.
Since we do not have access to the source code of the DLL, maybe you can post the prototype of the function, and all relevant struct definitions, and the DllImport line that you wrote for it?

Google can't find that error message which means(not definitely though :)) it is not a system message but a custom one coming from the code in the dll. So the dll does something dodgy. I guess it tries to double dispatch your call to another function internally.
Few things I suggest you try:
Run a x86 configuration. In the project properties -> Build tab set the platform to x86. this is assuming the dll is an x86 dll.
dumpbin /headers orc.dll
File Type: DLL
FILE HEADER VALUES
14C machine (**x86**)
4 number of sections
4CE7B6FC time date stamp Sat Nov 20 11:54:36 2010
0 file pointer to symbol table
0 number of symbols
E0 size of optional header
2102 characteristics
Executable
32 bit word machine
DLL
This command line should tell you the bitness. In case it is a 64 bit run a 64 bit config instead but I bet it is 32 bit.
Do not include the dll in the project. I guess you do that already. Make sure the dll is in a folder that is in the %PATH% environment variable. When you run this at command prompt:
where ocr.dll
should tell you where the dll is. If it doesn't add the folder where the dll is installed to the %PATH%.

C# to C++/CLI to C DLL System.IO.FileNotFoundException

I'm getting System.IO.FileNotFoundException: The specified module could not be found when running C# code that calls a C++/CLI assembly which in turn calls a pure C DLL. It happens as soon as an object is instantiated that calls the pure C DLL functions.
BackingStore is pure C.
CPPDemoViewModel is C++/CLI calling BackingStore it has a reference to BackingStore.
I tried the simplest possible case - add a new C# unit test project that just tries to create an object defined in CPPDemoViewModel . I added a reference from the C# project to CPPDemoViewModel .
A C++/CLI test project works fine with just the added ref to CPPDemoViewModel so it's something about going between the languages.
I'm using Visual Studio 2008 SP1 with .Net 3.5 SP1. I'm building on Vista x64 but have been careful to make sure my Platform target is set to x86.
This feels like something stupid and obvious I'm missing but it would be even more stupid of me to waste time trying to solve it in private so I'm out here embarrassing myself!
This is a test for a project porting a huge amount of legacy C code which I'm keeping in a DLL with a ViewModel implemented in C++/CLI.
edit
After checking directories, I can confirm that the BackingStore.dll has not been copied.
I have the standard unique project folders created with a typical multi-project solution.
WPFViewModelInCPP
BackingStore
CPPViewModel
CPPViewModelTestInCS
bin
Debug
Debug
The higher-level Debug appears to be a common folder used by the C and C++/CLI projects, to my surprise.
WPFViewModelInCPP\Debug contains BackingStore.dll, CPPDemoViewModel.dll, CPPViewModelTest.dll and their associated .ilk and .pdb files
WPFViewModelInCPP\CPPViewModelTestInCS\bin\Debug contains CPPDemoViewModel and CPPViewModelTestInCS .dll and .pdb files but not BackingStore. However, manually copying BackingStore into that directory did not fix the error.
CPPDemoViewModel has the property Copy Local set which I assume is responsible for copying its DLL when if is referenced. I can't add a reference from a C# project to a pure C DLL - it just says A Reference to Backing Store could not be added.
I'm not sure if I have just one problem or two.
I can use an old-fashioned copying build step to copy the BackingStore.dll into any given C# project's directories, although I'd hoped the new .net model didn't require that.
DependencyWalker is telling me that the missing file is GPSVC.dll which has been suggested indicates security setting issues. I suspect this is a red herring.
edit2
With a manual copy of BackingStore.dll to be adjacent to the executable, the GUI now works fine. The C# Test Project still has problems which I suspect is due to the runtime environment of a test project but I can live without that for now.

Are the C and C++ DLLs in the same directory as the C# assembly that's executing?
You may have to change your project output settings so that the C# assembly and the other DLLs all end up in the same folder.
I've often used the Dependency Walker in cases like this; it's a sanity check that shows that all the dependencies can actually be found.
Once your app is running, you may also want to try out Process Monitor on the code you are running, to see which DLLs are being referenced, and where they are located.

The answer for the GUI, other than changing output settings, was the addition of a Pre-Build Step
copy $(ProjectDir)..\Debug\BackingStore.* $(TargetDir)
The answer for the Test projects was to add the missing DLL to the Deployment tab of the testrunconfig. You can either do so by directly editing the default LocalTestRun.testrunconfig (appears in Solution under Solution Items) or right-click the Solution and Add a new test run config, which will then appear under the main Test menu.
Thanks for the answers on this SO question on test configurations for leading me to the answer.

The reason why this happens is because you either are loading DLLMAIN from managed code, before the CRT has an opportunity to be initialized. You may not have any managed code, be executed DIRECTLY or INDERECTLY from an effect of DllMain notifications. (See: Expert C++/CLI: .Net for Visual C++ Programmers, chapter 11++).
Or you have no native entrypoint defined wahtsoever, yet you have linked to MSVCRT. The CLR is automatically initialized for you with /clr, this detail causes a lot of confusion and must be taken into account. A mixed mode DLL actually delay loads the CLR through the use of hot-patching all of the managed entry point vtables in your classes.
A number of class initialization issues surround this topic, loader lock and delay loading CLR are a bit trickey sometimes. Try to declare global's static and do not use #pragma managed/unmanaged, isolate your code with /clr per-file.
If you can not isolate your code from the managed code, and are having trouble, (after taking some of these steps), you can also look towards hosting the CLR yourself and perhaps going through the effort of creating a domain manager, that would ensure your fully "in-the-loop" of runtime events and bootstrapping.
This is exactally why, it has nothting todo with your search path, or initialization. Unfortunately the Fusion log viewer does not help that much (which is the usual place to look for .NET CLR assembly binding issues not dependency walker).
Linking statically has nothing todo with this either. You can NOT statically link a C++/CLI application which is mixed mode.
Place your DLLMAIN function into a file by itself.
Ensure that this file does NOT have /CLR set in the build options (file build options)
Make sure your linking with /MD or /MDd, and all your dependencies which you LINK use the exact same CRT.
Evaluate your linker's settings for /DEFAULTLIB and /INCLUDE to identify any possiable reference issues, you can declare a prototype in your code and use /INCLUDE to override default library link resolution.
Good luck, also check that book it's very good.

Make sure the target system has the correct MS Visual C runtime, and that you are not accidentally building the C dll with a debug runtime.

This is an interesting dilemma. I've never heard of a problem loading native .DLLs from C++/CLI after a call into it from C# before. I can only assume the problem is as #Daniel L suggested, and that your .DLL simply isn't in a path the assembly loader can find.
If Daniel's suggestion doesn't work out, I suggest you try statically linking the native C code to the C++/CLI program, if you can. That would certainly solve the problem, as the .DLL would then be entirely absorbed into the C++/CLI .DLL.

Had the same problem switching to 64-bit Vista. Our application was calling Win32 DLLs which was confusing the target build for the application. To resolve it we did the following:
Go to project properties;
Select Build tab;
Change 'Platform target:' option to x86;
Rebuild the application.
When I re-ran the application it worked.