Develop Reference

Launching C# WPF from Java causes FileNotFoundExceptions

I have a existing Java Project which needs functionality from a SDK written in C#. It should open a WPF Window and send the information back to Java on close.
For a basic connection of those two worlds i created a Java Project ("DotNetCaller") calling native functions. These are implemented in a C++/CLI Project ("DotNetBridge") which calls the C# Project ("DotNetApplication").
I already can set Strings from Java in C# and callback from C# to Java.
But as soon as i add a WPF Window and try to launch it with:
Application app = new Application();
app.Run(new DotNetWindow());
in a STA Thread it crashes.
The DotNetApplication doesnt find mscorlib.resources, after i provide the DLL, PresentationFramework.resources is missing and if i provide that, the DotNetApplication.resource is missing (which i cant provide).
If i call the DotNetApplication alone or from the DotNetBridge the Window displays as expected.
Can anyone tell ma what i'm really missing here?
Thanks
Edit:
I looked at this example once more and tried to adapt it to my needs.
I have set the dll directory of the ResolveEventHandler to the .NET dir in "Referenced Assemblies"
C:\Program Files (x86)\Reference
Assemblies\Microsoft\Framework.NETFramework\v4.0
and added a Window in C#.
It failed aswell but with a new exception in the C++ part rather than C#.
The ResolveHandler gets called with an empty argument causing an uncatchable exception in mscorelib.
I added a check if the String is empty and this basic approach works fine now.
I'm still unsure if i have the correct approach for this, so feel free to contribute.

Your AppDomain::AssemblyResolve handler probably needs to be overhauled and based on your own understanding of what you want to do. There is some guidance here. The basic rule is that you return nullptr for requests that you can't handle.
But first you have to plan the locations in which you want to deploy (and/or debug) your assemblies. A simple layout would be to put all of the assemblies that your JNI DLL depends on in the same folder as the JNI DLL (with the exception of any that will be installed in the GAC). You can then use its location to satisfy resolution requests. But remember to return nullptr if no file containing a manifest for an assembly with the requested name is present there. (This is likely the case with your ".resources" requests. If there isn't one it's okay unless you know otherwise.)
I'd be a little surprised if an assembly in a Reference Assemblies folder wasn't also in the GAC—but it'd be up to the assembly provider. Reference Assemblies is for design and build tools (e.g. Visual Studio). (The old way was for each folder that had assemblies in it to be registered for each version of Visual Studio so the assemblies could be used for design and build.) If a dependency is not in the GAC, you can use the "Copy Local" property on the reference to make it available for debugging.
You might find the Assembly Binding Log Viewer useful while designing and troubleshooting. With it you can see all the folders and extensions that are tried before giving over to calling the AppDomain::AssemblyResolve handler chain. (Disable logging when you are done.)

Can I obfuscate a compiled .NET executable/assembly?

So I'm trying to obfuscate my program AFTER it's been compiled. I'm pretty sure that's how you do it (?)
I'm using a pretty popular freeware called EazFuscator which has a nice little command line utility.
So if I go:
Eazfuscator.NET MyProgram.exe
it'll obfuscate it successfully, and when it's done, I'll try to run my program and it crashes! (gives me some runtime exception)
Another thing I tried instead is to obfuscate one of the DLL's my program uses:
EazFuscator.NET SomeDLLMyProgramUses.dll
it'll obfuscate it successfully, but again, when I run my program crashes...
I'm wondering first off, regardless of this EazFuscator program, is it possible to obfuscate .DLL and .EXE files? and is it usually NOT supposed to break them?
Note: I do have some reflection going on in my program, and maybe that's whats causing the problem.. but I'm not 100% sure.

There is Dotfuscator community edition, which you could try.
In general obfuscators are not supposed to break the apps they obfuscate. You should contact the manufacturer if you can reproduce the issue.

Most of the Obfuscation tools have settings that allow you to manage the level of obfuscation - like type names, method names, strings and so on. It is possible that your level of obfuscation has resulted in an IL code that is broken due to these changes that the tool performed on your original IL code. Check the settings available and attempt to avoid a few of those settings.

If you are using reflection then the obfuscation tool will probably break you code. During obfuscation type names are usually changed, therefore your reflection may not work as expected, especially if you are referring to a type by name. Use a tool like reflector to have a look at you obfuscated assembly, you will be able to see whats going on.

Yes, we need to obfuscate our assembly after compilation. Assembly is built again by obfuscator. So we don't need to worry about compilation and building it.
I am using FxProtect which is free obfuscator. Advance Professional version is also available but it is not free. You can try it...
.Net Obfuscator

No, you do not typically obsfucate your executable program. I'm sure you've been thinking about it since you posted your question and can imagine why.
Run the obfuscation on your source code then compile that into deliverable.

Whether or not your code is broken by obfuscation depends upon what you do in your code. If you're using reflection in there that will almost certainly be the root cause.
CLISecure has worked well for me in the past (even on mixed-mode assemblies) ...but we don't use any reflection in our codebase.

Not able to run SWIG C# examples in VS 2010

I am trying to get SWIG to work with Visual Studio and C#.
I downloaded swigwin-2.0.4.zip and converted the project to a VS 2010 project.
I am able to build the 'class' example. When I then try to run compiled build I get the error
The type initializer for 'examplePINVOKE' threw an exception.
I haved googled the error, but have not found any suggestions on how to resolve it.
Hope somebody is able to help!
Thanks,
Christian

What worked for me was to:
Go to Build->Configuration Manager. For the C# project change AnyCpu to x86 and rebuild.
Copy example.dll to bin\x86\Debug (Release).
Doesn't require CorFlags.

I got the following answer from Gregory Bronner on the swig-user mailinglist:
I had this issue as well (VS2010 , Windows 7, 64 bit computer, 32 bit mode dll, .NET 4) :
The problem actually relates to being unable to load the DLLs
There were two causes:
#1: All DLLs used by the C# assembly need to be in the same directory (or you need to change the lookup paths).
#2: The C# or the C++ DLL (I forget which) had incorrect CofFlags -- use CorFlags /32Bit+ *.dll or something like that. You could also try using /UpgradeCLRHeader
#3: You need to target the .NET 4.0 system in the project file, but 1 and 2 should get you started.
I will try these hints out and see whether they work and then post an answer if I am able to resolve the issue.

The solution for me was
Move the used dll's to the Release (or Debug) directory
Run CorFlags /32Bit+ file.exe
where file.exe is the executable produced by building the code.
For more information on what is going on Í found the following links helpful
http://www.davesquared.net/2008/12/systembadimageformatexception-on-64-bit.html
http://blogs.msdn.com/b/joshwil/archive/2005/05/06/415191.aspx

Why can't my .NET CF application find a DLL In the same directory as the executable?

I have a .NET CF 1.1 application that has been running perfectly fine for years. Occasionally, I get a help desk ticket with the following error message (generic):
Method not found:
MethodName
AssemblyNamespace.Class
The DLL is there, and it's the same version as my other devices. What could change that would make it not find the method. Does this error imply that the assembly was loaded, or did it break before that even happened?
Does it matter how I added the reference in Visual Studio (2003, btw)? I have Copy Local set to true, and therefore I made the assumption that it needs to be in the same directory as my executable.
Any help you can offer is appreciated. Thanks.
EDIT: I believe this DLL is also in the windows directory of the device, possibly a different version. It contains a lot of hardware specific functions (i.e. backlight, keyboard state, etc.)

No it does not matter how you add the reference in Visual studio 2003. (100% sure)
Now for the not so sure : I think that someone else has the same assembly in the GAC of the phone. So the GAC assembly gets called rather than the one you deployed and that version of the assembly lacks the requested function.

Depends on how you reference the file in your code. You could be relying on the current working directory which depending on how the app is launched or what they do after, it might not be what you expect it to be.

Sometimes .NetCf throws this exception when the device is running out of memory, instead of the expected "Out of Memory" exception. I have observed this behaviour more often when loading native dlls using P/Invoke than loading pure netcf dlls.

How would i use a C++/CLI dll that wraps native code with multiple dependent libraries in C#?

I am wondering how I would go about correctly setting up a C++/CLI library that wraps native c++ code that has several dependencies. I have tried both statically and dynamically linking the native library to its dependent libraries with no luck.
The Managed C++/CLI dll builds just fine and can be added as a reference to a C# project. However when I attempt to use any of the defined classes i receive either a BadImageFormatException or FileNotFoundException depending how i linked. I believe I need to specify the dependent libraries in the CLI library so it is loaded in the manifest but I am unsure of the process. Also because i know it will come up, I have verified that all of the libraries involved are built on the x86 architecture.

I figured out the problem and everything is working correctly now. It was a combination of several incorrect things all happening together.
If anyone has the same issue, I resolved it by setting up the following:
1) The Boost libraries that were referenced (specifically boost_thread) needed to be compiled with BOOST_THREAD_USE_DLL preprocessor (other boost libraries may need BOOST_ALL_DYN_LINK to just dynamically link everything). This is apparently a common issue.
2) I verified that all dependencies were in system Path (like R Ubben reiterated)
3) I used the DependencyWalker (depends.exe from sourceforge) to analyze my compiled managed DLL. It turned out that the libpq.lib library being used actually referenced additional DLLs that were not included in the lib folder but in the bin folder. So that need to be added to the Path.
4) Part of my wrapper was using the #include header for lists. This forced my library to link against 2.0 framework dependent libraries. This was not compatible with my 4.0 client targeted C# application. This was only made known by parsing through the Warnings from compiling (previously hidden due to C++ generating too many..foolish i know). However this was resulting in a System.BadImageFormateException being thrown despite everything targeting the same x86 architecture.
Hope that helps anyone else who has the same problem. The BadImageFormateException and FileNotFoundException were entirly too vague and unhelpful.

You should make the C++ dll in release mode and use extern "C" for public static things.

I have gotten that error when the dependent libraries were not in the path. The wrapper library is found because of the reference, but the reference does not also take care of the dependent libraries. Try placing them explicitly where the program is executing.