We Keep Coding

Where will Python search for .NET assemblies?

We have a C# application and we need to provide Python scripting interface. Now it's implemented in a way that:
A managed scripting library (compiled as a DLL) does all the core work
A C++/CLI wrapper (wraps around the managed library and is compiled as a static library) does all the native-managed data translation
A boost extension project (BOOST_PYTHON_MODULE) (compiled as a dynamic library with the extension manually changed to pyd) talks to the C++/CLI wrapper layer.
The problem I have is that every time any python app tries to use the interface, it will complain the core managed assembly cannot be found. I have to place it either in the Python installation directory, or deploy it into the GAC.
I enabled the Windows Fusion logging and saw that it will only probe the assembly in the Python directory, I wonder if there is a way to direct Python to search for the .NET assembly in our application installation directory, or rather, any custom directory?
I tried all approaches in this post but that does not work for me. Any help will be highly appreciated!
PS:
We know that there are other python options like IronPython or Python .NET but we need to be backward compatible so a C++ interface is also required.
In case you are curious what error I get, here it is:
Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'ScriptingInterface, Version=1.3.9.0, Culture=neutral, PublicKeyToken=160df4f7a3973cc2' or one of its dependencies. The system cannot find the file specified.
at NativeCommunicator.{ctor}(NativeCommunicator* )

Esentially to fix the problem you have to:
In your python script as a very first line you have to call "init".
"Init" is a function which you add in your .pyd module
In Init method you simply register a hook for resolving assemblies.
In the hook you have a chance to load your assemblies from whatever directory you want.
Link below might have be helpful for you:
Loading Mixed-Mode C++/CLI .dll (and dependencies) dynamically from unmanaged c++

Loading a .NET DLL from Resources inside a Win32/clr DLL

I wrote a Win32-DLL (with clr support in VS 2010/13, c++) as extension for another/old VB6 app and use the opensource-dll PDFSharp.
It works fine, but if the "PDFSharp.dll" removed from Directory the Application crashes if the program try to load my dll.
I want to include the Sharp DLL into mine, so that only one DLL is needed.
I tried to add it to resources, and load/catch the error during run time by
AppDomain^ root = AppDomain::CurrentDomain;
root->CurrentDomain->AssemblyResolve += gcnew ResolveEventHandler(MyResolveEventHandler);
in the first Function that the app calls, but my Problem is, the app/dll crashes before i can handle something.
ILMerge can't help, because it is a Win32/net(clr) DLL not a 100% NET-DLL.

C++/CLI mixed-mode DLLs have two sets of references: the native imports in the PE header, and the .NET assembly references. Problems finding the native imports will cause the symptom you observed, that loading the assembly fails early during load and cannot be intercepted and recovered.
It's not clear to me why the native dependency rules are applicable here. For a true native dependency that needs to be located using an alternate search order under your control, delay-loading could be applied. But that can't be used with a referenced .NET assembly.
In any case, the simplest fix is to not need a separate assembly at all. Your goal is single file deployment, and the ideal single file deployment scenario is when all the code is contained in a single DLL and you don't need to unpack a second file at runtime.
For pure .NET assemblies, there is an ILMerge tool that combines multiple DLLs into a single file. But your case has a C++/CLI mixed mode DLL, not pure MSIL.
Using multiple languages in a native program generally works a little bit differently. Instead of producing a complete executable from each toolset, native code standardizes an object file format (Windows .obj, Linux .o) which all the various toolsets know how to produce, and then the link step can link together object files from a variety of languages. The object files are often bundled into static libraries. (A static library is just an archive of object files, with a symbol index) Because the C++/CLI toolset is patterned on native C++, it uses this model as well.
The .NET version of this language-independent "object file" which can be further linked is a .netmodule file. Internally, it is a .NET assembly without a manifest. Functionally, it acts like a static library. And the C++/CLI link.exe can link together C# (and VB, and F#, etc) .netmodule static libraries together with the C++/CLI object files and static libraries, and native object files and libraries, when it creates the mixed-mode assembly.
This isn't the most straightforward process, because while it is supported by the underlying toolchains, the Visual Studio project options dialog boxes don't have a UI for either creating or consuming .netmodule static libraries.
For the C# side to produce a .netmodule, you should open your .csproj file and change the <OutputType> setting to module. Then reopen the project in Visual Studio and build as usual.
On the C++/CLI side, the project options dialog allows you to customize the compile and link command-lines. Change the linker command to include /link and the name of the .netmodule file.
If you've done it right, the C++/CLI linker will create a single mixed-mode DLL with all the types and code from both the C# and C++/CLI source files. And all the internal usage between C# and C++/CLI will be already resolved, so you won't have to worry about missing dependencies at run time. Well, at least not these dependencies; any you didn't choose to link in will still be handled normally.

Call C++ code from C# without creating dll?

I'm noob in C# and I already searched on the web. Anyway I'm still not sure about this and I do not have the total control of the code I have to implement, this is why I would like to be sure I needn't make any dll. I have a C++ file with a method, and I want to call this method from C# code. I just added "extern C" to the function.
When I just add the .h and .cpp files to the C# project they aren't detected. And of course, when I try to add it as reference, it doesn't work.
So do I absolutly have to make a dll ?

Your options for accessing the C++ code from C#:
Compile C++ as unmanaged DLL and access using p/invoke. This requires the C++ code be exposed using a C style API.
Compile C++ as unmanaged DLL and access using COM. This requires that you wrap your C++ in as COM objects.
Compile C++ as mixed/mode C++/CLI assembly and access the assembly as a managed reference. This requires that you wrap the original C++ as managed C++ ref classes.
All of these options, by necessity, involve the creation of another module/assembly. You cannot link the C++ code directly into your C# assembly.

You might like to try using the PInvoke Interop Assistant to generate the C# necessary to interact with the DLL via Platform Invoke. Be aware that this is imperfect though so YMMV.
Another alternative, if you have the knowledge and patience, is to make a COM component out of your native C++ DLL and consume that from C# by using the Type Library Importer to create a managed wrapper.

You won't be able to interact with .cpp/.h files since you need at least a binary object (assembly) for C# to interact with and C# won't generate any binaries from .cpp/.h. That's on the subject about adding these files as references to the project.
As for the argument that you don't have control over the code - well, don't make a DLL out of the actual .cpp/.h, but make your own thin DLL that has a wrapper object that just includes the headers, calls whatever method you would be calling and links to the appropriate .o files or .lib or whatever you have. If the interface changes you would just changed your thing wrapper which should be easy.

Is it possible to run unmanaged C++ normally from a managed C++/CLI project?

I'm in the process of wrapping a pure unmanaged VC++ 9 project in C++/CLI in order to use it plainly from a .NET app. I know how to write the wrappers, and that unmanaged code can be executed from .NET, but what I can't quite wrap my head around:
The unmanaged lib is a very complex C++ library and uses a lot of inlining and other features, so I cannot compile this into the /clr-marked managed DLL. I need to compile this into a seperate DLL using the normal VC++ compiler.
How do I export symbols from this unmanaged code so that it can be used from the C++/CLI project? Do I mark every class I need visible as extern? Is it that simple or are there some more complexities?
How do I access the exported symbols from the C++/CLI project? Do I simply include the header files of the unmanaged source code and will the C++ linker take the actual code from the unmanaged DLL? Or do I have to hand write a seperate set of "extern" classes in a new header file that points to the classes in the DLL?
When my C++/CLI project creates the unmanaged classes, will the unmanaged code run perfectly fine in the normal VC9 runtime or will it be forced to run within .NET? causing more compatibility issues?
The C++ project creates lots of instances and has its own custom-implemented garbage collector, all written in plain C++, it is a DirectX sound renderer and manages lots of DirectX objects. Will all this work normally or would such Win32 functionality be affected in any way?

You can start with an ordinary native C++ project (imported from, say, Visual Studio 6.0 from well over a decade ago) and when you build it today, it will link to the current version of the VC runtime.
Then you can add a single new foo.cpp file to it, but configure that file so it has the /CLR flag enabled. This will cause the compiler to generate IL from that one file, and also link in some extra support that causes the .NET framework to be loaded into the process as it starts up, so it can JIT compile and then execute the IL.
The remainder of the application is still compiled natively as before, and is totally unaffected.
The truth is that even a "pure" CLR application is really a hybrid, because the CLR itself is (obviously) native code. A mixed C++/CLI application just extends this by allowing you to add more native code that shares the process with some CLR-hosted code. They co-exist for the lifetime of the process.
If you make a header foo.h with a declaration:
void bar(int a, int b);
You can freely implement or call this either in your native code or in the foo.cpp CLR code. The compiler/linker combination takes care of everything. There should be no need to do anything special to call into native code from within your CLR code.
You may get compile errors about incompatible switches:
/ZI - Program database for edit and continue, change it to just Program database
/Gm - you need to disable Minimal rebuild
/EHsc - C++ exceptions, change it to Yes with SEH Exceptions (/EHa)
/RTC - Runtime checks, change it to Default
Precompiled headers - change it to Not Using Precompiled Headers
/GR- - Runtime Type Information - change it to On (/GR)
All these changes only need to be made on your specific /CLR enabled files.

As mentioned from Daniel, you can fine-tune your settings on file level. You can also play with '#pragma managed' inside files, but I wouldn't do that without reason.
Have in mind, that you can create a complete mixed mode assembly. That means, you can compile your native code unchanged into this file PLUS some C++/CLI wrapper around this code. Finally, you will have the same file as native Dll with all your exported native symbols AND as full-fledged .NET assembly (exposing C++/CLI objects) at the same time!
That also means, you have only to care about exports as far as native client code outside your file is considered. Your C++/CLI code inside the mixed dll/assembly can access the native data structures using the usual access rules (provided simply by including the header)
Because you mentioned it, I did this for some non-trivial native C++ class hierarchy including a fair amount of DirectX code. So, no principal problem here.
I would advise against usage of pInvoke in a .NET-driven environment. True, it works. But for anything non-trivial (say more than 10 functions) you are certainly better with an OO approach as provided by C++/CLI. Your C# client developers will be thankful. You have all the .NET stuff like delegates/properties, managed threading and much more at your finger tips in C++/CLI. Starting with VS 2012 with a somewhat usable Intellisense too.

You can use PInvoke to call exported functions from unmanaged DLLs. This is how unmanaged Windows API is accessed from .Net. However, you may run into problems if your exported functions use C++ objects, and not just plain C data structures.
There also seems to be C++ interop technology that can be of use to you: http://msdn.microsoft.com/en-us/library/2x8kf7zx(v=vs.80).aspx

Build native c++ for use as .net library

I have the c++ source code of functionality which is appealing to me.
What effort/work is involved/required in order to either reference this from a .net application or build this code as a .net assembly (preferably c#)?
This is my first attempt at porting code, so please breakdown your answer for me step by step.

There are several ways of doing it.
PInvoke
Create C++/CLI wrapper around your C++ native code (make static library out of C++ native code) and C++/CLI generated assembly can be easily utilized in .net application.
COM, i.e using interop (which is difficult among all the options)
In my suggestion easiest way is to use option 2, but you need to take care of proper marshaling.

Solution A:
If you have the source code, then compile the CPP program as a DLL file.
Use P/Invoke
Solution B (if the functionality you want is in a static library):
Create a stub function caller and compile THAT as a DLL
Same as solution A.2