I am updating the question above with further logs extracted from the SDL API. We get similar but not the same Errors when trying to work with the server TM project after ~8 hours (the olde token not valid anymore bug?):

1. Unexpected exception when configuring file multiFileConverter for task 'Dateien vorübersetzen': Die Übersetzungs-Engine 'sdltm.URL/ %28US%29 - French %28France%29' konnte nicht instanziiert werden..
   We receive this message after running an AutomaticTaskTemplateIds.PreTranslateFiles as RunAutomaticTask on our project, which is referencing server TMs. After
   foreach (MessageEventArgs messageEvent in messageEventArgsList)
   we don't get any exception in
   messageEvent.Message.Exception
   , even if the message received obviously states "Unexpected exception"
2. The same problem seems to occur after calling AutomaticTaskTemplateIds.AnalyzeFiles, also by using RunAutomaticTask on the project:
   Unexpected exception when initializing task 'Analyse': Die Übersetzungs-Engine 'sdltm.URL/ %28US%29 - French %28France%29' konnte nicht instanziiert werden..
3. The last one has a slightly different error messge, happening when using AutomaticTasks.TranslationCount:
   Unexpected exception when configuring file multiFileConverter for task 'Übersetzte Wörter zählen': Die Übersetzungs-Engine 'sdltm.URL/ %28US%29 - French %28France%29' konnte nicht instanziiert werden..

Hi Guys,

I have investigated this issue this morning and identified the root cause.  It seems that there is an issue in resolving the correct version of System.Net.Http assembly; the original exception is getting gobbled up with abstraction, which was preventing us from understanding the root cause in this case.

You can work around this by simply making a hard reference to the same version of this assembly (that Studio 2019 is using) in your automation project.

Add this reference to your project: C:\Program Files (x86)\SDL\SDL Trados Studio\Studio15\System.Net.Http.dll

Hi Patrick,

thank you very much for having a look at our problems here. We compiled a few questions that came up when trying to use your suggested fix:

1. @ Server-TM 8 hour bug:

1. 1. Is there a difference between both the ProjectCredentials.AddCredential methods? http://producthelp.sdl.com/SDK/BatchTaskApi/1.0/html/05e5f07c-6ff5-8afe-9617-7756003375d5.htm - we are using this:
      string credentials = "user=" + tmServer.username + ";password=" + tmServer.password + ";type=CustomUser";
      Does this behave similarly to your suggestion, when adding GS 2017 / 2021 server TMs?
      project.Credentials.AddCredential(new Uri(serverAddress), false, name, password);
   2. Can we assume, that our code will connect to the groupshare server with a new token / login instance ( or however that is managed inside the API)?
      Or is there a possibility of the Studio API somewhere holding - and after time devaluating - login tokens over several login attempts, if the credentials are the same, in some sort of buffered way?
      Our code basically does this:
      • creating or loading FileBasedProject, which references a sdlproj-Template containing GS-Server-TM in one or more target languages.
      • Then before AutomaticTaskTemplateIds.AnalyzeFiles / PreTranslateFiles / UpdateMainTranslationMemories / PopulateProjectTranslationMemories and project.CreateProjectPackage :
      • Add Credentials for known ServerTMs (inside the project) to the project with project.Credentials.AddCredential

2. Net.Http.dll:

1. 1. Thank you for your suggestion to
      Add this reference to your project: C:\Program Files (x86)\SDL\SDL Trados Studio\Studio15\System.Net.Http.dll
   2. But unfortunately our Studio 2019 installation, versioned 15.2.8.3007, which is untouched so far, does not contain that dll. Neither does Studio 2021 16.1.3.4096.
   3. Which version of the .net framework are you using when developing Studio API code? Possibly we are referencing the wrong version of .net which includes the wrong version of System.Net.Http.dll
   4. Do we have to include that dll manually, e.g. with Nuget? Which version of the dll do you suggest downloading? The newest version available would be 4.3.4, but in our experience, nuget versions should match the versions used by Trados Studio (e.g. Newtonsoft.Json).
   5. If we install the dll on our own, does the .Net dll lookup make sure to look first in the Studio2015 folder, even when using your precompiled API, which implicitely uses System.net.HTTP?

Hopefully you will be able to make use of our problem description, otherwise don’t hesitate to contact me directly.

Best,

Hendrik

Hi Hendrik,

Sorry to hear you are still having problems in getting this running on your system. You are right, my mistake, that dll doesn't seem to be included with the installer anymore.

1. There should be no difference with choosing one overload over the other for ProjectCredentials.AddCredential.

2. I have just checked now and the version of System.Net.Http that I’m using locally for Studio 2019 is 4.3.3, available for download here  https://www.nuget.org/packages/System.Net.Http/4.3.3
Download/extract and make a hard reference to the \runtimes\win\lib\net46\System.Net.Http.dll from that package

let me know how it goes,

P.

Hi,

I hope it's ok if I ask this here instead of creating a new post, but we are having similar issues.

We have an application which we developed using the Trados Studio 2019 API that we use to analyze files for translation. But instead of server based TMs, the application uses file based TMs that are stored on the local file system.

We've now been trying to update this application to the new Trados Studio 2021 API, but we are now running into an issue where the analysis reports are not being generated. The issue seems to be the similar to the one above with the following error message: 

Unexpected exception when initializing task 'Analyse': Die Übersetzungs-Engine 'sdltm.file:///c:/TradosServer/10.0.2.234/MainTMs/C00001612_de-DE_en-GB_def.sdltm' konnte nicht instanziiert werden.."

Any idea what could be the cause of this? Since we are not using server based TMs it don't think the System.Net.Http.dll is the issue. Thank you very much for any help, it's very much appreciated.

Here is the entire exception stack trace:

<SOAP-ENV:Envelope xmlns:xsi="">www.w3.org/.../XMLSchema-instance" xmlns:xsd="">www.w3.org/.../XMLSchema" xmlns:SOAP-ENC="">schemas.xmlsoap.org/.../" xmlns:SOAP-ENV="">schemas.xmlsoap.org/.../" xmlns:clr="">schemas.microsoft.com/.../1.0" SOAP-ENV:encodingStyle="">schemas.xmlsoap.org/.../">
<SOAP-ENV:Body>
<a1:ProjectApiException id="ref-1" xmlns:a1="">schemas.microsoft.com/.../Sdl.ProjectApi, Version=16.0.0.0, Culture=neutral, PublicKeyToken=c28cdb26c445c888">
<ClassName id="ref-4">Sdl.ProjectApi.ProjectApiException</ClassName>
<Message id="ref-5">Unexpected exception when initializing task &#39;Analyse&#39;: Die Übersetzungs-Engine &#39;sdltm.file:///c:/TradosServer/10.0.2.234/MainTMs/C00001612_de-DE_en-GB_def.sdltm&#39; konnte nicht instanziiert werden..</Message>
<Data xsi:null="1"/>
<InnerException href="#ref-6"/>
<HelpURL xsi:null="1"/>
<StackTraceString id="ref-7"> bei Sdl.ProjectApi.Implementation.TaskExecution.ContentProcessingTaskImplementation.InitializeTaskImplementations()
bei Sdl.ProjectApi.Implementation.TaskExecution.ContentProcessingTaskImplementation.Execute()
bei Sdl.ProjectApi.Implementation.AutomaticTaskExecuter.Execute()</StackTraceString>
<RemoteStackTraceString xsi:null="1"/>
<RemoteStackIndex>0</RemoteStackIndex>
<ExceptionMethod id="ref-8">8
InitializeTaskImplementations
Sdl.ProjectApi.Implementation, Version=16.0.0.0, Culture=neutral, PublicKeyToken=c28cdb26c445c888
Sdl.ProjectApi.Implementation.TaskExecution.ContentProcessingTaskImplementation
Void InitializeTaskImplementations()</ExceptionMethod>
<HResult>-2146233088</HResult>
<Source id="ref-9">Sdl.ProjectApi.Implementation</Source>
<WatsonBuckets xsi:null="1"/>
</a1:ProjectApiException>
<a3:ProjectAutomationException id="ref-6" xmlns:a3="">schemas.microsoft.com/.../Sdl.ProjectAutomation.Core, Version=16.0.0.0, Culture=neutral, PublicKeyToken=c28cdb26c445c888">
<ClassName id="ref-10">Sdl.ProjectAutomation.Core.ProjectAutomationException</ClassName>
<Message id="ref-11">Die Übersetzungs-Engine &#39;sdltm.file:///c:/TradosServer/10.0.2.234/MainTMs/C00001612_de-DE_en-GB_def.sdltm&#39; konnte nicht instanziiert werden.</Message>
<Data xsi:null="1"/>
<InnerException href="#ref-12"/>
<HelpURL xsi:null="1"/>
<StackTraceString id="ref-13"> bei Sdl.ProjectAutomation.FileBased.Internal.AutomationServerEvents.HandleTranslationProviderException(ITranslationProviderItem translationProviderItem, Exception exception)
bei Sdl.ProjectApi.Helpers.ProjectCascadeFactory.GetTranslationProviderLanguageDirection(ITranslationProviderItem translationProviderItem, LanguagePair languageDirection, Boolean performUpdate, Boolean refreshCache)
bei Sdl.ProjectApi.Helpers.ProjectCascadeFactory.CreateProjectCascadeEntries(IList`1 projectCascadeEntryDataList, LanguagePair languagePair, Boolean readOnly, Boolean refreshCache)
bei Sdl.ProjectApi.Helpers.ProjectCascadeFactory.CreateCascade(ProjectCascadeSettings projectCascadeSettings, Boolean refreshCache)
bei Sdl.ProjectApi.Helpers.LanguageDirectionHelper.CreateCascade(ILanguageDirection languageDirection, ProjectCascadeEntryDataFilterFunction filter, IComparer`1 sort, Boolean readOnly, Boolean refreshCache)
bei Sdl.ProjectApi.Helpers.LanguageObjectsCache.&#60;&#62;c__DisplayClass6_0.&#60;GetRecognizers&#62;b__0(String _)
bei System.Collections.Concurrent.ConcurrentDictionary`2.GetOrAdd(TKey key, Func`2 valueFactory)
bei Sdl.ProjectApi.Helpers.LanguageObjectsCache.GetRecognizers(ILanguageDirection languageDirection)
bei Sdl.ProjectApi.AutomaticTasks.Analysis.AnalysisDataCollectorX.CreateAnalysisDataStorage(ILanguageDirection languageDirection, AnalysisTaskSettings analysisSettings, TranslationMemorySettings translationMemorySettings, ILanguageObjectsCache objectsCache)
bei Sdl.ProjectApi.AutomaticTasks.Analysis.AnalysisDataCollectorX.Initialize(IList`1 files)
bei Sdl.ProjectApi.AutomaticTasks.Analysis.AnalysisTask.CreateAnalysisDataCollectors()
bei Sdl.ProjectApi.AutomaticTasks.Analysis.AnalysisTask.InitializeTask(IExecutingAutomaticTask task)
bei Sdl.ProjectApi.Implementation.TaskExecution.ContentProcessingTaskImplementation.InitializeTaskImplementations()</StackTraceString>
<RemoteStackTraceString xsi:null="1"/>
<RemoteStackIndex>0</RemoteStackIndex>
<ExceptionMethod id="ref-14">8
HandleTranslationProviderException
Sdl.ProjectAutomation.FileBased, Version=16.0.0.0, Culture=neutral, PublicKeyToken=c28cdb26c445c888
Sdl.ProjectAutomation.FileBased.Internal.AutomationServerEvents
Void HandleTranslationProviderException(Sdl.ProjectApi.ITranslationProviderItem, System.Exception)</ExceptionMethod>
<HResult>-2146233088</HResult>
<Source id="ref-15">Sdl.ProjectAutomation.FileBased</Source>
<WatsonBuckets xsi:null="1"/>
</a3:ProjectAutomationException>
<a4:ArgumentNullException id="ref-12" xmlns:a4="">schemas.microsoft.com/.../System">
<ClassName id="ref-16">System.ArgumentNullException</ClassName>
<Message id="ref-17">Der Wert darf nicht NULL sein.</Message>
<Data xsi:null="1"/>
<InnerException xsi:null="1"/>
<HelpURL xsi:null="1"/>
<StackTraceString id="ref-18"> bei System.Activator.CreateInstance(Type type, Boolean nonPublic)
bei System.Activator.CreateInstance(Type type)
bei Sdl.Core.PluginFramework.DefaultObjectResolver.CreateObject(Type objectType, XElement attributeElement)
bei Sdl.Core.PluginFramework.Implementation.Extension.CreateInstance()
bei Sdl.Core.PluginFramework.ObjectRegistry`2.CreateObjects()
bei Sdl.LanguagePlatform.TranslationMemoryApi.TranslationProviderManager.GetTranslationProviderFactories()
bei Sdl.LanguagePlatform.TranslationMemoryApi.TranslationProviderManager.CreateTranslationProvider(Uri translationProviderUri, String translationProviderState, ITranslationProviderCredentialStore credentialStore)
bei Sdl.ProjectApi.TranslationProviderCache.CreateTranslationProvider(Uri translationProviderUri, String translationProviderState, ITranslationProviderCredentialStore credentialStore)
bei Sdl.ProjectApi.TranslationProviderCache.GetTranslationProvider(Uri translationProviderUri, String translationProviderState, ITranslationProviderCredentialStore credentialStore, Boolean performUpdate, Boolean refreshCache)
bei Sdl.ProjectApi.Helpers.ProjectCascadeFactory.GetTranslationProviderLanguageDirection(ITranslationProviderItem translationProviderItem, LanguagePair languageDirection, Boolean performUpdate, Boolean refreshCache)</StackTraceString>
<RemoteStackTraceString xsi:null="1"/>
<RemoteStackIndex>0</RemoteStackIndex>
<ExceptionMethod id="ref-19">8
CreateInstance
mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
System.Activator
System.Object CreateInstance(System.Type, Boolean)</ExceptionMethod>
<HResult>-2147467261</HResult>
<Source id="ref-20">mscorlib</Source>
<WatsonBuckets xsi:null="1"/>
<ParamName id="ref-21">type</ParamName>
</a4:ArgumentNullException>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Hi Laurent Hug,  I'd try to keep the issues separate to avoid scope creep.

I'm interested to understand if your team were successful in getting the automation working, given the indications I provided above for the Studio 2019 specific issue?
If yes, then please close this ticket to confirm that the solution provided worked, so that others may also benefit from it; wdyt?

Hi Patrick,

First of all, thank you very much for the quick answer.

We've tried following the steps you indicated above, but this did not solve our problem. We still get the same error after referencing System.Net.Http Version 4.3.3 as you mentioned above. We also tried using the newer version 4.3.4, but unfortunately this also didn't help.

Hi Laurent Hug, sorry to hear this.

I can confirm that during my tests, I was able to reproduce the same exception message that you received initially; I discovered that the root exception was related to a discrepancy in the version of  System.Net.Http; the solution was to make specific reference to that assembly as opposed to pulling it from the GAC.

What is the full version of Studio 2019 that you are using in your automation environment?

Lets try the following:

• I will prepare and provide your team with the automation sample project that I coded where this is working interrogating your GS 2017 server, against the latest production release of Studio 2019 SR2 CU8 that I have locally.  I will update you via e-mail either later on today or tomorrow morning.
• Try the test without any other plugins from being loaded with the automation Studio environment, to exclude any external influences (e.g. unknowns)

Hi Patrick,

First of all, thank you for your help!

It seems like an old Version of the DeepL Translation Provider Plugin was the Problem. After removing all Plugins from our installation of Trados Studio 2021 like you suggested, the analysis seems to work fine.

Thanks again!

Hi Patrick,

unfortunately the message

Unexpected exception when configuring file multiFileConverter for task 'Übersetzte Wörter zählen': Die Übersetzungs-Engine 'sdltm.GROUPSHARESRV Resources%2FO-00133 English (USA) 020&tmName=Testing' konnte nicht instanziiert werden..

is still bugging our customer and us when using Trados 2019 with GS 2017, although we added the dependency to system.http.

The Groupshare server in its TMService.log seems to log this error which should be related:

2021-04-21 08:04:37.2402|GROUPSHARESRV|Warn|THREAD_ID:22|TR_ID:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx|Authentication failed: The message expired at 20.04.2021 19:39:44 and it is now 21.04.2021 08:04:37.
2021-04-21 08:04:37.2402|GROUPSHARESRV|Warn|THREAD_ID:22|TR_ID:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx|Unauthorized request

Since this seems to be a Groupshare problem, we thought about possibly sending a keep alive to the GS 2017 server, possibly requesting login tokens on a regular basis (x hours) or before using actual server TMs.

Do you think this might solve the problem or would this be a waste of time?

Do you have other suggestions, e.g. another method of accessing server TMs within the Studio API, or other tools ( https://github.com/sdl/groupsharekit.net )?

We need code that works together with the project automation API since we rely on project.runautomatictask to achieve CAT business.

Our server TM access code is still the same as in the original post.

Best regards,

Hendrik