• State Suggested Answer
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 392 subscribers
  • Views 1865 views
  • Users 0 members are here
Options
Related

TMX export is not working anymore with Trados Studio 2022 17.1.8.17828 API

Sébastien Desautel

Hello,

this post is possibly connected to Matthias' post ( TranslationMemoryImporter throws error when trying to import TMX file ). 

I had a working code to simply export sdltm to tmx. It is basically what can be found here: https://developers.rws.com/studio-api-docs/apiconcepts/translationmemory/exporting_to_tmx.html?tabs=tabid-1%2Ctabid-2

But it does not work anymore.

If I remember well, my last Studio version without issue was 17.1.6. After the update to 17.1.8, I got several error messages in Visual Studio and I had to comment out some TM functions.

I tried today to have one export function work again: on the last line "exporter.Export(exportString, true)", I get the error that npgsql.dll is missing, later, that microsoft.data.sqlclient.dll is missing and at the end sqlite.interop.dll that I can't add at all (Error adding reference to "SQLite.Interop" Make sure that the file is accessible and that it is a valid assembly or COM component.).

But it does not look like the right way to fix the problem, correct?

Can you have a look and see if it's maybe a bug?

Thanks

Sébastien
Rate translation
×
Suggest better translation
×
Parents
  • 0

    Hello again,

    I investigated further and must correct some elements above. Former version was 17.0.6 (not SR1) but it was already a problem that I didn't notice.

    After a proper update of the AssemblyResolver project from Github, the problem with missing "npgsql.dll" and "microsoft.data.sqlclient.dll" has been solved, but "sqlite.interop.dll" was still not recognized. Trying to add this dll as nuget directly is still impossible. (see above)

    I also tried to use the AssemblyResolver nuget instead aof my compiled version, but there was the error that the assembly should have a strong name.

    Thanks

    Sébastien
  • 0 in reply to Sébastien Desautel

    Hi , is there a reason you can't use the latest release of the product SR2?

    Have you tried making reference to the sqllite.interop from the Trados Studio installation and simply adding the binding redirect?
         <dependentAssembly>
           <assemblyIdentity name="Microsoft.Data.SqlClient" publicKeyToken="23ec7fc2d6eaa4a5" culture="neutral" />
           <bindingRedirect oldVersion="0.0.0.0-5.0.0.0" newVersion="5.0.0.0" />
         </dependentAssembly>

    Patrick Andrew Hartnett | Developer Experience | Team Lead | RWS Group

  • 0 in reply to Patrick Andrew Hartnett

    Hello , thanks for looking into this.

    I will try with SR2 as soon as I can (not yet possible in my environment). Adding a reference to the sqlite.interop.dll from the Trados Studio installation folder also casts the following error: adding reference to "SQLite.Interop" Make sure that the file is accessible and that it is a valid assembly or COM component.

    Adding the <dependentAssembly> as suggested did not help on it's own, but I think you suggested this along with the reference to the dll, right?

    I have found 2 solutions:
    - a previous post in the community suggested copying the dll directly to the compile destination folder (bin/debug) and this helped.
    - I also tried importing a larger sqlite nuget (System.Data.Sqlite) and this also helped.

    After importing the larger nuget, I also did a test without AssemblyResolver, and to my surprise it still works. Do you know maybe why?

    Anyway, this seems to be fixed.

    Thanks

    Sébastien
Reply
  • 0 in reply to Patrick Andrew Hartnett

    Hello , thanks for looking into this.

    I will try with SR2 as soon as I can (not yet possible in my environment). Adding a reference to the sqlite.interop.dll from the Trados Studio installation folder also casts the following error: adding reference to "SQLite.Interop" Make sure that the file is accessible and that it is a valid assembly or COM component.

    Adding the <dependentAssembly> as suggested did not help on it's own, but I think you suggested this along with the reference to the dll, right?

    I have found 2 solutions:
    - a previous post in the community suggested copying the dll directly to the compile destination folder (bin/debug) and this helped.
    - I also tried importing a larger sqlite nuget (System.Data.Sqlite) and this also helped.

    After importing the larger nuget, I also did a test without AssemblyResolver, and to my surprise it still works. Do you know maybe why?

    Anyway, this seems to be fixed.

    Thanks

    Sébastien
Children