Several weeks ago I have build a Native C++ .dll that wraps a third-party .dll to be used with C# P/Invoke in several applications to be deployed in WES7. I've been using Windows 10 as a dev box and everything works as expected. This week I finally got my hands on the box with embedded Windows and things are not doing that well anymore... I've tried to deploy three different C# applications that use the .dll I built alongside the third-party one but they all fail with a DllNotFoundException. Obviously both .dll files are in the same folder as my executable file for each project, but I keep getting the DllNotFoundException. My native .dll targets the Win32 platform, the embbedded windows is a 32-bit system, and all my C# apps are built to target the x86 architecture, so I've ruled that out. I've wasted the last hour messing around with the system32 folder to no avail, so I've run out of options. Any suggestions will be appreciated.
Edit: I just talked to a co-worker who works remotely and he had the exact same problem when trying to run our .dll under WES7. I'll update this question as soon as I have more info.
In the end, I happened to be dumb enough to deploy a DEBUG version in the target machine, which didn't have msvcp100d.dll and msvcr100d.dll. I used Dependency Walker to figure that out (apparently it was too hard for me to take a look at the project properties page drop-down) and deployed a release version in the target. It finally worked, but I had a different problem that leads to another question...
Related
I have been struggling to find solution to prevent application from searching .dll files in program installation directory.
I have tried many approaches like SetDllDirectory, delaying .dll loading etc.
However my tests shows that .dlls is still searched from installation directory and only then C:/Windows
I have tested it by adding one of my own .dll that runs cmd. For example if I place DWrite.dll in installation directory in always runs cmd and then runs application.
I have few projects with same issue, one is pure C++ and other is C#, that uses some of C++ sub projects in it, this makes it even more difficult to solve.
Do anyone know proper solution for this or workaround?
I am trying to use a C++ DLL in C# Windows Store app. I included the DLL file as Content with Copy Always option, in a project directory (which should map to an installation directory upon installation).
This works fine on a Desktop without a problem.
Based on what I have researched online, I cannot figure out why this method doesn't work for Windows Phone Emulator and Device.
Worth pointing out that the DLL is updated to the appropriate architecture (x64, x86, arm) with VS2015's Pre-build event command.
Some unsuccessful attempts:
I attempted using LoadPackagedLibrary in App Initialization just in case the DLL was not being loaded in time but didn't help (also meant messing up with DllImport I could do without!).
I would have thought Package.appxmanifest is where such dependencies are declared (or hinted) but couldn't find much mileage with this approach either.
Am I missing [something obvious] for an unmanaged DLL included as Content?
I've this feeling that this should be straight-forward 'cos many developers must have done this but can't figure or find a how-to example. Help!
3 Days of hair pulling. It just doesn't make any sense. I can't figure out what I've missed.
So I have this C#/WPF VS2013pro project I'm building that works fine on my Visual Studio machine: Win 8.1 x64 but fails due to 'dll not found' on any target PC I transplant it to.
It uses FreeImage, which has two DLLs:
FreeImage.dll - C++ that does all the work
FreeImageNet.dll - .NET wrapper to make like easy in C#
The two need to be in the same directory and preferably the same as the .exe - so they are.
My project is 64bit. I downloaded the source for FreeImage and compiled both DLL's for x64: First the CPP one, then the .NET one. Then copied them to the solution.
The .net DLL is referenced in my solution. The CPP does not reference, of course. Both are part of the solution and copy to the %outputdir% (Bin/Debug or Bin/Release) when the solution is built. The program runs fine in DEBUG and in RELEASE on my Development PC and the DLL methods do their job.
I copy the entire BIN directory to another PC running the same version of Windows, same updates, the works... The program runs but when a method is needed from the FreeImage.dll it fails with "unable to find dll".
To make sure I'm right about it using the dll from the BIN directory (and not from System32 or SysWOW64) on my VS machine I pull it out and run the app: Yep it fails.
I put it back and move the entire directory: It works
I pull it out: It fails
I put it back and move it to a thumbdrive: It works
{you get the idea}
So at this point it sure seems like it is really using the one in the same directory as the .exe and the .NET wrapper dll
I move the thumbdrive with the code that just worked on my VS machine to the other PC: It fails.
Next I try remote debug to the other PC: All the files copy to a matched directory, debugging starts and works, I get output and breakpoint behavior from the remote PC: Only the calls that require the DLL again fail because FreeImageNet.dll cannot locate FreeImage.dll
I did nothing special on my Visual Studio machine to make FreeImage work: I downloaded the source and compiled then copied the DLLs to the solution and referenced the .NET dll - That's it.
I have Googled, and researched and opened questions on SourceForge about it.
Every previous question I have found on this issue are cases of someone thinking FreeImageNet.dll was self-contained and not realizing it had to be located along side of FreeImage.dll
I have checked registry for I have checked registry for HKLM/System/CurrentControlSet/Control/SessionManager/KnownDLLs/
I have tried to register it with regsrver32 (yes, the 64bit flavor)
I have tried setting an environmental variable to it.
I have tried copying the DLL to every directory that is part of the DLL search order.
I have tried it on Win8.1x64pro (same as my Visual Studio pc) and two Win7x64pro machines.
I have assumed it was some weird quirk in 3.16 of FreeImage and done this again and again with previous releases as far back as 3.6, all with the same results.
I have built an installer for the solution and installed it on the VS machine where it worked, and installed it on the test machine where it failed.
I am trying for the first time (and not so successfully) to virtualize my physical PC. VMware has always been good to me for test environments and at this point I want to see if a total clone of the Visual Studio machine will succeed or fail with this project.
So... Anyone have an idea?
Darn it, I missed one: vcomp120.dll
Seems it is part of the Visual C++ redistributable that was installed with Visual Studio.
It should have dawned on me that I would need to include this, but with the entire EMGUcv package working... and the fact that I hate C++ and haven't used it in a dozen years... It totally never occurred to me.
Can you please try to import the dll with DLLIMPORT. Copy and place the dll to the directory same as of exe and use following code in Code behind:
[DllImport("FIBITMAP.dll")]
public static extern void Load(string param1,string param2,...);
Here Param1, Param2,... will be your parameters to the function Load.
Hope this helps.
I'm coding a simple application that I need to be portable (the user can just run it by clicking on the .exe without having to run a installer).
All the other questions on this subject that I found on StackOverflow wants to make .NET Framework "bundable" with the software, but I don't need that.
A workaround that I found is going to /bin/Debug on the project folder and use the .exe there, but that seems "wrong". Is there another way to make a software written in C# portable?
Thanks!
EDIT: Okay, I'm really dumb and I asked all the wrong questions. However, your answers pointed me to the right direction. I wanted to know how to generate the .exe to send to my friends. What I had to do is change this to "Release" and press F6. I added this so if someone with the same "doubts" that I had can find the answer easly. Thanks!
Going to bin/Debug and using the DLL there is wrong.
Instead, build and copy the one from bin/Release.
If there's anything else inside the folder, though (except *.pdb), then beware. Your application might need those additional files. For example, the app.config.
All .NET applications are "portable" as long as the machine you are running it on has the version of .NET you are targeting (or a compatible version). The key here is to make sure that your application does not depend on things that an installer would take care of for you to make your application work. Examples include: registered DLLs (like Interop assemblies), registry keys, or components that must be found in certain locations (such as having something stored in user's AppData folder).
As long as the machine you want to run it on has .NET framework, you can make any .NET application portable. If the app you're making has no dependencies other than .NET then it's fully portable already. Even if it does have dependencies just include those with the executable.
To expand on Zerkms's comment:
Every software is portable by default. Installers are a way of telling to program to search for resources in a certain place, meaning that if the place isn't there, eg: C:\Windows then the program won't be able to run.
So as long as you have the application have the resources already within the exe or a root folder search (so where the program is, rather then where it should be) then you'll be fine.
If you're using default controls, it should be fine as long as your software's running framework version is installed on the computer. If you're using 3rd party controls, you can emded the dll's into the .exe upon compiling. Do note that the more dll's you embed, the bigger the .exe file will be.
I'm kinda new to C# programming, and I'd like your help on something.
A quick review of what I have to do first.
I have to create : - A DLL that produces several .h5 files (HDF5 format) and one xml file
- A WPF viewer for the graphs that are written in these HDF5 files.
The problem is mainly that they are going to be used in a software called Panorama E², which basically manages DLLs, in a very restrictive way. For instance, it does not allow .NET framework 4 (Which makes me use the 3.5 version of the framework).
More info on Panorama : http://uk.codra.net/panorama/panorama-e2-information-system
I'm using HDF5DotNet.dll, that I compiled in x64 for .NET 3.5, and DynamicDataDisplay for my WPF application.
All my DLLs are going to be used by another computer, where Panorama is installed, and where Visual Studio isn't (only the 3.5 .NET framework and some required tools are).
What's the problem ?
Well, first, my WPF application isn't really one, Panorama doesn't seem to support WPF, only Windows Forms, and only as DLLs. Which means I created a WPF UserControl, that I embed in a Windows Form DLL.
I basically have 2 DLLs, one which is the WPF control, and one that uses this control in a winform. This is the last one that I have to integrate in Panorama. On my computer, the one I'm coding with, Panorama recognizes correctly the DLL and there's no problem.
But when I try to give these DLLs to my colleague, with his Panorama without Visual Studio installed, it doesn't work. After some tests, I noticed that it only works if the project (the DLLs) have been compiled on the same computer.
The same problem goes for the other DLL, the one that creates files. As I said, it uses HDF5DotNet.dll, but it seems it doesn't create it correctly. I guess it's the same problem, the DLL is not recognized.
What I tried.
I thought that maybe the DLLs weren't exported correctly. Maybe the referenced DLLs or assemblies aren't given, which are when you compile on the same computer. They're COM DLLs, because they're used in Panorama, and I can't manage to export them correctly.
I tried creating setup projects, so that they would be installed with their dependencies, but I couldn't find a way. Only the DLLs are installed. I tried looking at my DLLs with DependancyWalker, and there are some where dependancies are missing. Even if I try adding them manually, nothing changes.
I also know that regsvr32 doesn't work with .NET DLLs, because there is no entry point. That's why i thought about GAC, but I can't manage to register them (with strong name and everything), because I can't generate them directly.
So yeah, sorry for the long post, I tried to explain my train of thoughts and what I actually tried to do, but I can't find a way to give my projects to my colleague so that he can use them on his computer.
"Self Registration" ( be it RegSvr32, RegAsm or other ) is not a Windows Installer Best Practice. This injects out of process dependencies into the installation critical path that the installer is not aware of, that can fail and can't be rolled back or uninstalled.
The better approach is to use RegAsm /regfile to harvest the COM metadata for the ComVisible assembly and then author those registry values into your MSI's Registry table. This way Windows Installer merely has to copy the DLL and apply the registry values to register your component. It's far less likely to break and can be uninstalled and repaired cleanly.
How you do this exactly depends on the tool you are using to author your MSI. In WiX you'd use Heat to harvest this information. In InstallShield you'd set the .NET ComVisible attribute to True.
The end result is the same.
Hi try the following in command prompt instead of regsvr32 try the following :
"RegAsm.exe acxMaterialClassificationMerge.dll /codebase " where acxMaterialClassificationMerge.dll is your dll. You should do this on every pc thats going to use the dll. RegAsm is located in C:\Windows\Microsoft.NET\Framework\v2.0.50727
1: install first dotnet framework version 2 or newer on the computer
2: in command prompt :"RegAsm.exe acxMaterialClassificationMerge.dll /codebase " where acxMaterialClassificationMerge.dll is your dll. You should do this on every pc thats going to use the dll. RegAsm is located in C:\Windows\Microsoft.NET\Framework\v2.0.50727.