Thank you. I have downloaded your sample and get the same error.
I found a good description of this issue here: http://www.marklio.com/marklio/PermaLink,guid,ecc34c3c-be44-4422-86b7-900900e451f9.aspx
Looking at the FSharp post, and a few other on Google, I expected this code to work:
private static void SetBindingMode()
ICLRRuntimeInfo rtInfo = (ICLRRuntimeInfo)RuntimeEnvironment.GetRuntimeInterfaceAsObject(Guid.Empty, typeof(ICLRRuntimeInfo).GUID);
// WARNING - this is not the real interface - it just has enough slots to get to BindAsLegacyV2Runtime correctly.
[MethodImpl(MethodImplOptions.InternalCall, MethodCodeType = MethodCodeType.Runtime)]
But it doesn't. The result from the BindAsLegacyV2Runtime() call is OK, but under the debugger I see that the GetRuntimeInterfaceAsObject call actually loads the .NET 2.0 runtime .dll... not sure why. And when loading the SQLite library, the original error
is still present.
From the marklio article, I thought that this means we are calling the BindAs... function too late. [Or the GetRuntimeInterfaceAsObject is returning the wrong Runtime
Next I tried to change the unmanaged loader to make the call as early as possible. I added this line:
HRESULT hrbind = pRuntimeInfo->BindAsLegacyV2Runtime();
into the LoadClrMeta procedure in the file ExcelDnaLoader.cpp. Again I see this suspicious entry in the debugger during this call:
'excel.exe': Loaded 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll'
and eventually loading the SQLite library will fail with the same error as before.
I've suspected for many years that Excel registers to be called when .NET is loaded (maybe with a call to LockClrVersion http://msdn.microsoft.com/en-us/library/ms230241.aspx). This
interferes with Excel-DNA's attempts to host the runtime, (and would likewise interfere with VSTO or a COM Shim).
As a result, I don't think you can change this binding setting for Excel anywhere but in the exel.exe.config file. Of course I would love to be proven wrong (I could have made a mistake in where the unmanaged call fits in). To pursue this further, you'd
have to make an unmanaged host to emulate Excel loading the code and try to make the call to compare with the Excel call, or perhaps investigate whether Excel is really interfering with the .NET loading process.
For now it seems you have to choose between:
- Adding the excel.exe.config file.
- Rebuilding the mixed assemblies to target .NET 4. (I see the System.Data.SQLite driver is progressing under control of the SQLite guys now).
- Using another way to talk to SQLite (or your other native libraries) - perhaps using P/Invoke (like http://code.google.com/p/sqlite-net/) or with a pure managed implementation: http://code.google.com/p/csharp-sqlite/.
- Retargeting your add-in for the .NET 2.0 runtime.
Sorry I can't give a nicer answer.