@tomunger use this tool to strongly sign Python.Runtime.DLL with a key, e.g. the one provided with pythonnet:

https://github.com/brutaldev/StrongNameSigner

Does this mean that I must sign the DLL on all systems my application is used on? That does not seem scalable. Also, I came across articles against strong naming and microsoft suggests against it.

How do other apps that embed Python solve this? It seems that it should be very simple...

@tomunger the solution is simple - don't use GAC!

I'm trying to not use GAC! Assembly.LoadFrom("filepath") will happily load Python.runtime assembly. But this does not resolve the static references. Soon as my code gets close to PythonEngine.Initilize() it fails with assembly-not-found error. My current solution is to copy the .dll file into application directory. I feels like I'm missing something simple and obvious here but all examples found by Google show me how to do thinks I know and which do not solve the problem.
Thanks for your suggestions.

@tomunger this has nothing to do with pythonnet, but you can set custom load path for reference DLLs:

https://stackoverflow.com/q/1892492/2230844

Did you also check about this(NTFS Security, Blocking)?
#655

@denfromufa thanks for that link. I know about private path and it does not resolve my issue. The standard approach is to distribute DLLs for the assemblies your application depends on WITH your application. However, in the case of Python.Net I don't want to do this. Different versions of Python require different DLLs (right?). What I want to do is use the DLL installed with Python - thus not in my application directory anywhere.
The bottom of that thread had an example of using the AssemblyResolve event and I had not explored that. Turns out that solves my problem. Here's the code that loads Python.Runtime from the python directory.

public class PythonResolver
{
	public const string LIBS_PATH = "Lib\\site-packages";
	public const string ASSEMBLY_FILE = "Python.Runtime.dll";
	private string _pythonHome;

	public PythonResolver(string pythonHome)
	{
		_pythonHome = pythonHome;
		AppDomain.CurrentDomain.AssemblyResolve += this.ResolvePython;
	}

	private Assembly ResolvePython(object sender, ResolveEventArgs args)
	{
		// Forbid non handled dll's
		if (!args.Name.Contains("Python.Runtime"))
		{
			return null;
		}
		string targetPath = Path.Combine(_pythonHome, LIBS_PATH, ASSEMBLY_FILE);

		try
		{
			return Assembly.LoadFile(targetPath);
		}
		catch (Exception)
		{
			return null;
		}
	}
}

@tomunger good finding! Yes, pythonnet has some build time compiler flags for specific Python versions even in Python.Runtime.DLL CLR assembly. @dmitriyse was working on approach to resolve these APIs at runtime, but I'm not sure how far he was able to accomplish this.

@dmitriyse @denfromufa is there an issue tracking this? I am also interested in a generic binding, that could be used with any Python installation across platforms.

I have made great work to isolate C-Calls (that gave an ability to load different python dlls at runtime). But it was so big changes that nobody elso wants to work with that.
Now this work should be performed again due to lots of changes in the C-Calls code.

@dmitriyse can you share the branch?

Sorry, this branch is not in GH now.
And probably I have already delete it from my working computer.

I have spent around 4 working days to carefully add indirection into runtime.cs C-Calls and all other wrapping code.