.exe won't find DLL

Apr 14, 2014 at 8:31 PM
Edited Apr 14, 2014 at 8:40 PM
I have a program using pcap.net. It works well when I am launching it from the developer, but fails completely when I use the exe. Here's what I've done and the exception:

Add existing item to project (PcapDotNet.base.dll, .core.dll, .core.extensions.dll, and .packets.dll)
  1. Gone to references and added to their location in my project's folder. No yellow warning triangles
  2. Gone to Build->project->compile to make sure the configuration says "release"
  3. Gone to Build->project->compile to make sure the target cpu says "x86".
  4. Tried both 86 and 64 in my developer pack versions of .dll, and have removed the references prior to add them as existing items. (it threw an exception at run time for the x64, so I changed back to the x86)
  5. works without a problem when I run it from Visual studio, gives this error when I run from a .exe in my release folder.
  6. I have .NET and the 2010 Redistributable Package installed
"ex in find camerasSystem.IO.FileNotFoundException: Could not load file or assembly 'PcapDotNet.Core" and goes on to say that my assembly binding logging is turned off.


I will take any help I can get on this issue. What am I missing?
Apr 15, 2014 at 8:51 AM
Hi sparkysword,

Have you looked at the different steps in Using Pcap.Net in your programs?

  • Make sure the application you're using was built in Release mode and not Debug.
  • Install WinPcap 4.1.2.
  • Try installing the x86 version of the Microsoft Visual C++ 2010 Redistributable Package when x64 version doesn't work.
Apr 15, 2014 at 11:51 AM
Hey Brickner,

Thank you for your help, However I have done those things.
-#2 shows that I have made the configuration into "Release"
-I did not list, but yes I have WinPCap 4.1.2, or it wouldn't have run in the development mode
-I didn't specifically say x86 of the package, but yes I have the latest version.
-I did look at using pcap.net in my program,and made sure to get each point.

Am I missing another step?

Thank you,
Apr 15, 2014 at 7:09 PM
Yikes, I'm pulling my hair out on this one. Could really use some help. Here is my setup:
  1. Project->Properties:
    Configuration: Active(release)
    Platform: Active (Any CPU)
    Target CPU: x86
  2. Build ->configuration manager:
    Release / any CPU
  3. DLLs are referenced (the x86 ones, I had deleted the bin folder and replaced with x64 while changeing the target too)
    They are included in my bin folder. My vbproj shows it:
    <Reference Include="PcapDotNet.Base, Version=, Culture=neutral, PublicKeyToken=4b6f3e583145a652, processorArchitecture=MSIL">
    <Reference Include="PcapDotNet.Core, Version=, Culture=neutral, PublicKeyToken=4b6f3e583145a652, processorArchitecture=x86">
    <Reference Include="PcapDotNet.Core.Extensions">
    <Reference Include="PcapDotNet.Packets, Version=, Culture=neutral, PublicKeyToken=4b6f3e583145a652, processorArchitecture=MSIL">
  1. When I run the .exe file (with the dlls in the same folder) on my machine I get no issues. When the .exe is run by itself on my computer OR with the Dlls in the same folder on another computer, we get a file not found exception.
Any ideas?
Apr 21, 2014 at 8:02 AM
Looking at http://stackoverflow.com/questions/23069607/pcap-net-exe-error-with-dll, I guess that you didn't have WinPcap installed where you tried to run the application, right?
Apr 22, 2014 at 1:08 PM
Don't use "Platform: Any CPU."
If you use Platform Any CPU, with 32bit pcap, on a 64bit Windows, targeting Net Framework 4.0 you get a BadImageFormatExeption because .Net is gonna load the 64bit runtimes.
If you target Net Framework 4.5 though, is gonna detect a 32bit dependency and load the 32bit runtimes, even if Windows is 64 and platform is Any CPU. Net 4.5 is a bit smarter than 4.0.

So just avoid Platform: Any CPU
Apr 22, 2014 at 1:23 PM
If "Any CPU" is a problem... then how come I can load the .exe on different machines that don't have .net 4.5, and it doesn't throw me that exception? How come I get zero exceptions when I run it on mine from visual studio? I feel there needs to be more testing on this dll support.