For a deeper look into our Eikon Data API, look into:

Overview |  Quickstart |  Documentation |  Downloads |  Tutorials |  Articles

question

Upvotes
Accepted
1 0 1 3

What could cause the error "Unable to resolve type: ThomsonReuters.Desktop.SDK.DataAccess.IInternalDataServices"

An application connecting the Reuters using the legacy desktop application is producing an interesting issue.

In two different environments I'm getting different results.

After publishing the application I need to copy over the missing DLL files (EikonPipeDll, i18nresource, msvcp120 and msvcr120 published on 2015-11-24) for the application to run without errors.

When I switch to another environment and try it again I get the error

Unable to resolve type: ThomsonReuters.Desktop.SDK.DataAccess.IInternalDataServices

Last Stack Trace:

at ThomsonReuters.Desktop.SDK.DataAccess.TinyIoCContainer.DelegateFactory.GetObject(Type requestedType, TinyIoCContainer container, NamedParameterOverloads parameters, ResolveOptions options)


I've tried using the new missing dlls published on 2020-04-13, but using these the program fails with the same error in both environments.


I've tried identifying where the dll were being loaded in using the bellow code targeting the following assembelies: typeof(DataServices).Assembly, typeof(IDataServices).Assembly, typeof(DataServicesStateChangedEventArgs).Assembly, typeof(ServiceInformationChangedEventArgs).Assembly, typeof(CommonInterval).Assembly and typeof(DataChunk).Assembly.


private static IEnumerable<Assembly> GetReferencedAssemblies(Assembly a, HashSet<string> visitedAssemblies = null)

{

visitedAssemblies = visitedAssemblies ?? new HashSet<string>();

if (!visitedAssemblies.Add(a.GetName().EscapedCodeBase))

{ yield break; }

foreach (var assemblyRef in a.GetReferencedAssemblies())

{

if (visitedAssemblies.Contains(assemblyRef.EscapedCodeBase)) { continue; }

var loadedAssembly = Assembly.Load(assemblyRef);

yield return loadedAssembly;

foreach (var referenced in GetReferencedAssemblies(loadedAssembly, visitedAssemblies))

{ yield return referenced; }

}

}

Results:

In my first environment using the old missing dlls everything worked well and the paths were pointing to the application folder. When I tried on the second environment or when using the new version of the missing dlls, I got the following error.


Could not load file or assembly 'ThomsonReuters.Udap.BusTools.dll' or one of its dependencies. is not a valid Win32 application. (Exception from HRESULT: 0x800700C1)

mscorlib


I was hoping someone would shed some light as to why this is happening.

I've tried loading the missing dll directly, but doing this caused a System.BadImageFormatException.

And I've also tried imbedding the package in my tool but this too caused an issue.

Any idea or suggestion will help. It might help me narrow down the problem.


Thank you.


eikoneikon-data-apipythonworkspaceworkspace-data-apirefinitiv-dataplatform-eikonerror
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

1 Answer

Upvotes
Accepted
45.2k 103 43 60

@evan.lee

You can use the Process Monitor tool to verify the file activities of the application in both environments, as mentioned in this question.

Then, we can compare both logs to identify the differences.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.