Problem creating Packages using Automation API after upgrading to version 16.1.8.4404

Question

We have our own wrapper that we were using from the VBA to create projects and packages. After recent update to 16.1.8.4404 it stopped working. 
 In version 16.1.5.4270 is everything working fine. 
 Tested also with another tool/autmation kit STraSAK that originaly developed Mr. Mazanek without luck. https://github.com/EvzenP/STraSAK 
 
 Thank you for your help. 
 Description of error> 
 Error: Could not load file or assembly 'System.Runtime.CompilerServices.Unsafe, Version=4.0.4.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. System.IO.FileNotFoundException: Could not load file or assembly 'System.Runtime.CompilerServices.Unsafe, Version=4.0.4.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. 
 File name: 'System.Runtime.CompilerServices.Unsafe, Version=4.0.4.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' at System.Span`1..ctor(T[] array) at SharpCompress.Writers.Zip.ZipWriter.WriteEndRecord(UInt64 size) at SharpCompress.Writers.Zip.ZipWriter.Dispose(Boolean isDisposing) at SharpCompress.Writers.AbstractWriter.Dispose() at Sdl.ProjectApi.Implementation.ZipCompress.ZipDirectory(String packageFilepath, String localDataFolder) at Sdl.ProjectApi.Implementation.PackageProjectArchiver.ZipDirectory(String packageFilepath, String localDataFolder) at Sdl.ProjectApi.Implementation.PackageProject.CreatePackage(String packageFilePath, Boolean saveProject) at Sdl.ProjectApi.Implementation.AbstractProjectPackageCreation.StartImpl() at Sdl.ProjectApi.Implementation.PackageOperation.Start()

Patrick Andrew Hartnett · Accepted Answer

Hi Marián Kollár , Etienne LBS 
 I was successful in reproducing this issue while running the powershell script that you have made note of above. The previous version of that assembly is being resolved because of a dependency in one of the references (System.Memory). 
 To fix, simply include a binding redirect in the script to ensure the correct version of that assembly is resolved in the current App Domain during execution, as follows: 
 $compileServicesAssembly = [System.Reflection.Assembly]::LoadFrom("$ProgramFilesDir\SDL\SDL Trados Studio\$StudioVersion\System.Runtime.CompilerServices.Unsafe.dll")
$onAssemblyResolveEventHandler = [System.ResolveEventHandler] {
 param($sender, $e) 
 if ($e.Name.StartsWith("System.Runtime.CompilerServices.Unsafe")) {
 return $compileServicesAssembly
 }
 foreach($assembly in [System.AppDomain]::CurrentDomain.GetAssemblies()) {
 if ($assembly.FullName -eq $e.Name) {
 return $assembly
 }
 }
 return $null
}
[System.AppDomain]::CurrentDomain.add_AssemblyResolve($onAssemblyResolveEventHandler) 
 Note: Add this code, before you load the modules and remember to remove the reference when exiting the PS 
 
 Example : 
 cls

if ("${Env:ProgramFiles(x86)}") {
 $ProgramFilesDir = "${Env:ProgramFiles(x86)}"
}
else {
 $ProgramFilesDir = "${Env:ProgramFiles}"
}

$StudioVersion = "Studio16"

$Modules = @("TMHelper","ProjectHelper","GetGuids","PackageHelper")


Write-Host "Add binding redirect to 'System.Runtime.CompilerServices.Unsafe.dll'";

$compileServicesAssembly = [System.Reflection.Assembly]::LoadFrom("$ProgramFilesDir\SDL\SDL Trados Studio\$StudioVersion\System.Runtime.CompilerServices.Unsafe.dll")
$onAssemblyResolveEventHandler = [System.ResolveEventHandler] {
 param($sender, $e) 
 if ($e.Name.StartsWith("System.Runtime.CompilerServices.Unsafe")) {
 return $compileServicesAssembly
 }
 foreach($assembly in [System.AppDomain]::CurrentDomain.GetAssemblies()) {
 if ($assembly.FullName -eq $e.Name) {
 return $assembly
 }
 }
 return $null
}
[System.AppDomain]::CurrentDomain.add_AssemblyResolve($onAssemblyResolveEventHandler)

Write-Host "Load PowerShell Toolkit modules.";

ForEach ($Module in $Modules) {Import-Module -Name $Module -ArgumentList $StudioVersion}


Write-Host "Test: Export packages.";

Export-Package -ProjectLocation "C:\MyProjects\Project 1\Project 1.sdlproj" -PackageLocation "C:\Packages"

Write-Host "Completed.";

Remove-Module -Name "TMHelper";
Remove-Module -Name "ProjectHelper";
Remove-Module -name "GetGuids";
Remove-Module -name "PackageHelper";
[System.AppDomain]::CurrentDomain.remove_AssemblyResolve($onAssemblyResolveEventHandler) 
 
 Try this and let me know how it goes...

Paul · Answer

Hello Marián Kollár 
 Glad this has worked for you and you've been able to build your solution appropriately. 
 Marián Kollár said: But for any future Trados releases it would be much better when any necessary assamblies would be resolved directly in trados libraries during an API call. 
 We would be interested to understand why you think this would be the correct approach after what has been explained here? The issue is related to how nugget package dependencies are resolved in the App domain that is executing your code. So applying a binding redirect in this case should not be seen as a workaround, but a requirement in providing sufficient information from the App Domain that is executing your code to choose the correct version of the assembly when multiple versions are referenced from the libraries that are loaded. 
 Trados Studio handles this problem by including binding redirects in the app.config file that is loaded when the application starts. However, when you are running your scripts from PowerShell or the Command shell, the code is executed outside of the Trados Studio context. The solution is however the same, so far as to provide the App Domain with the same instruction via a binding redirect, so that it can disambiguate which version to resolve. 
 References: 
 https://docs.microsoft.com/en-us/nuget/concepts/dependency-resolution

Patrick Andrew Hartnett · Answer

Hi Guys, 
 There is certainly an issue where the system is not finding that specific version of the assembly. 
 I would try the following in this order: 
 
 Check if you are using the latest version of that assembly and upgrade if necessary, Depending on whether or not this reference is direct dependency or dependency of a dependency, this might be a difficult or easy exercise. 
 Introduce a binding redirect in the app config file of your application. 
 Register that version of the assembly in the GAC so that your system can find it... 
 
 let me know how it goes...

Emanuel Albu · Answer

Hi! 
 The binding redirect should be added to your app, not in Trados, as your app seems to have a reference to an older version of the DLL in question.

Trados Studio Developers > Studio Developers Q&A

Problem creating Packages using Automation API after upgrading to version 16.1.8.4404

Top Replies