Trouble loading .NET System assemblies

[bgowland]

I've got an nDroid support puzzle - I've an idea of what's going on but no idea what would cause it.

I've a handler in the main service for locating / loading 3rd-party assemblies...

Code:

    AppDomain.CurrentDomain.AssemblyResolve += new ResolveEventHandler(ResolveAssemblyEventHandler);

...it should normally only fire when looking for things like the SQLite dll etc. but in this case it's firing when trying to locate native .NET System assemblies.

The thread is http://forums.nextpvr.com/showthread.php...ll-problem and from the logs I see...

Code:

26-10-2013 21:53:31.177 ResolveAssemblyEventHandler() called.
26-10-2013 21:53:31.177 args.Name: System.ServiceProcess.resources, Version=4.0.0.0, Culture=nl-NL, PublicKeyToken=b03f5f7f11d50a3a
26-10-2013 21:53:31.177 Attempting to find assembly: System.ServiceProcess.resources.dll
26-10-2013 21:53:31.193 ResolveAssemblyEventHandler() called.
26-10-2013 21:53:31.193 args.Name: mscorlib.resources, Version=4.0.0.0, Culture=nl-NL, PublicKeyToken=b77a5c561934e089

...I'm guessing from the "Culture=nl-NL" part of the args passed in to the handler that it's looking for locale-specific versions of the System dlls but I've never seen that before and can't think what might be causing it.

Anybody any ideas?

Cheers,
Brian

[mvallevand]

I was wondering if he can he run 3.1.1, I'd start there to see if it is .NET 4.0 before looking at nDroid

Martin

[bgowland]

I was wondering if he can he run 3.1.1, I'd start there to see if it is .NET 4.0 before looking at nDroid

Martin

Agreed, that is one thing I intend to ask. If he's running an older npvr version or having problems with 3.1.1 then it's definitely an issue with his .NET 4 installation but I'm suspecting that anyway. It has highlighted a bug in the nDroid event handler which causes a recursive loop though.

Cheers,
Brian

[bgowland]

Just for future reference...

It was the bug I mentioned I'd found. It was my ResolveAssemblyEventHandler() which was creating a problem which didn't really exist. I discovered I'd set a default load path so, even if the assembly couldn't be found and manually loaded from the npvr or ndroid folders, it would try loading from the default path. The result was that the handler would be called again and so on.

I changed the code to simply return 'null' if the assembly can't be found in either the npvr or ndroid folders and as a result the .NET framework assumes responsibility for what should be done.

Cheers,
Brian