Including Unmanaged C++ DLL as Content in WinRT - c#

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!

Related

Windows Embedded Standard 7 won't find my .dll

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...

Deploying a C# COM dll using an installer

I have made a C# class library, which uses other dll's made by others in the company, for COM interop. It is being used with MS Excel 2013 and works fine on my development machine.
To test it on other machines, i have copied the output (dll's and .tlb file) to my system 32 folder. I have then registered the dll's using regasm (using the /codebase argument). Finally, i added the reference to the .tlb in the Excel VBA editor. Allthough it is a little tedious with 6 dll's, the regasm works fine.
The next step is to distribute the Excel sheet to relevant users in the company, where most are located in different parts of the world in different deparments. This means i do not know what programs that are installed that are needed(for example .net 4.5). Also, since most people in the company know little about the command line, using the above procedure is not only a little tedious, but scares people. I therefore would like to make an installer.
Since i use VS2013, i have installed a plug in that allows me to make a setup file.
I have found this question, which is almost the same as mine, but i don't need the GAC part. How do i modify the procedure to my needs? - i have tried to follow the procedure given, but i get an error stating one of the dll's i use in my own, does not have a strong name and cannot be in the GAC. Build therefore fails. How do i rectify the above? - do i need to fix the dll or can i do this without the GAC-part?
How do i automate the installation process of my dll(s)? - The alternative right now is to roll out VS2013 to the users and make them run the project and register that way (Does VS express suffice?).
Thanks in advance - i started this project with little experience, so learning curve is a bit steep.
It's not clear to me exactly what you want to do, but that link does tell you how to register Dlls - just look at the properties of each Dll and set the register property. You can also add your tlb file to your setup, and mark that to be registered too. If that isn't what you're trying to do then edit the question.
p.s. Don't put tham in the system folder - pout them in your company's/app's common files folder.

Build and deliver a C/C++ DLL into a C# app using Visual Studio 2013

I am a Visual Studio 2013 Newbie who is trying to figure out how to build a C DLL in Visual Studio and then invoke the functions exported by the C lib from within a C# app. I've got everything building, but I cannot figure out the proper way of getting the DLL included with the app build so that it will actually load properly when using [DLLImport()]. I currently get a System.DllNotFoundException when attempting to invoke a function from the library from within my C# class.
I have setup a VS 2013 solution which contains the following projects:
HelloWorldLib.Shared :
Shared project that contains the .cpp and .h files for the DLL
HelloWorldLib.Windows :
Win 8.1 C++ project that references the shared project and builds the DLL for Win 8.1
MyApp-Win.Windows :
C# project for Win 8.1 that wants to make use of the HelloWorldLib.Windows.dll produced by the HelloWorldLib.windows build
I have been looking over many SO questions and answers. For instance, I think my question is similar to this one, which doesn't appear to have been answered in any useful way:
Interop, Native DLL and Visual Studio build process
Some of the other answers suggested adding a file reference to the DLL, but how would I do that and keep the proper Debug/Release versions? Given that all of these projects are being built within the same solution, and there are build dependencies between them, it feels like there should be a straightforward way to set this up.
BTW, I am using the shared project setups, as my ultimate goal is to figure out how to get this all working with Xamarin to target iOS, Win, Win Phone, Mac and Android. So that we can use a common C/C++ layer for our high performance requirement code, and the reference it from the UI layers on the various platforms.
This is a pretty straight-forward problem, easy to identify if you look where the built files end up. The C++ build system has a different strategy than the managed build system. It by default writes the build output to the solution directory's Debug directory. Your C# project however builds to its bin\Debug directory and requires all dependent DLLs to be present there.
So, by default, your C# program can never find the DLL, it is in the wrong directory and Windows doesn't look there. Nor is MSBuild smart enough to discover this by itself, like it can for managed DLLs, it cannot see that you program depends on the C++ DLL.
Two basic ways to work around this:
Change the C++ project's Output Directory setting
Write a post-build event for your C# project that uses xcopy.exe to copy the DLL.
Unfortunately things aren't that easy, at least not yet. I was going to have a meeting with Microsoft C++ team but that got postponed, similar functionality you are after was one of the things on my wishlist (building managed C++/CLI wrappers for Xamarin.iOS and Android).
Currently, if you can, the easiest option is to wrap C++ code inside a DLL that exposes C interface. Then build it with XCode and Android NDK. If you can't then the next option is to create Objective-C binding project that wraps the C++ code inside Objective C classes for iOS. For Android either create Java wrapper or use SWIG. Both of these options are cumbersome which is why C API should be the first choice you investigate.
I know it's not the answer you were hoping for but reusing C++ code is way more complicated than reusing C# or even C.

Pointing an exe to a dll outside of the executable's directory

Using C#, VS2012, windows server 2012r2
I did some searching on this and i think I already know the answer, but was hoping someone could let me know if i am correct.
I have a website which has a dll in the bin folder. I've also got several executable tools that run on demand or a scheduled basis and pretty much all of them use the same dll as the wesbite. or rather, they use a copy of that dll which resides in each exe's folder.
This is pretty bothersome since anytime I update that dll for the website, all those exe's are now using an older version of the dll. So I'd like it if i could point all the exe's to the websites bin folder and use the dll in there.
I'd prefer not modifying windows PATH value if at all possible. if so it looks like would need to use a function called LoadLibrary? I hardly do any windows programming at all so i'm not familiar with this at all. IS this the only (or best) way to do this?
I found this blog post: http://blogs.msdn.com/b/jonathanswift/archive/2006/10/03/dynamically-calling-an-unmanaged-dll-from-.net-_2800_c_23002900_.aspx
Do i just create the NativeMethods class and then call GetProcAddress for every method/function i need to call?
I was hoping there was a way to basically just tell the exe to look in a specific folder for the dll with the app.config. Is that not possible?
Thanks
Seems like your DLL is a managed DLL (built on .net) since you said that you hardly do any Win32 API programming.
One solution is to install your DLL in GAC. Then every time you update the DLL assembly version and deploy to GAC, you have to redirect your applications to use the latest one. See this.

Deploying .NET COM dlls, issues when used on another computer

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.

Categories

Resources