Aspose assemblyresolve handling is slow

Hello, we are experiencing an issue with Aspose 20.10.0.0. Our website uses aspose to convert documents on the fly. Once we convert a document, ex. convert mht to pdf, the website becomes sluggish when localizing resx files. We’ve traced the behavior using perfview and have tracked it down to the following assemblies binding a handler to AppDomain.AssemblyResolve event.
aspose.pdf
aspose.pub
aspose.tasks
aspose.cad
aspose.page
aspose.email

This is causing a performance issue for our website where we generate all localized strings for the browser in a single call. These handlers are being fired multiple times for every resource string, as .net tries to locate the satellite assemblies containing the resx for the user’s language and culture.

Here is an example call tree starting with resourcemanager.getstring which immediately results in the AssemblyResolve event handler being called.

Name
|| + OTHER <<mscorlib!ResourceManager.GetString>>
|| + aspose.pdf!#=qoVrhiBciSukbg$QwrRyJNgXGy6PWv10Gl0Yy6R0BU8U=.#=zTX9k4yvHRTvgEPXf_1bH_j3X6EwG(class System.Object,class System.ResolveEventArgs)
|| |+ aspose.pdf!#=qoVrhiBciSukbg$QwrRyJNgXGy6PWv10Gl0Yy6R0BU8U=.#=zV7z10K2IqVbrS9UTqRQ4HDw=(class System.String)
|| | + aspose.pdf!#=qoVrhiBciSukbg$QwrRyJNgXGy6PWv10Gl0Yy6R0BU8U=+#=zsyve3GPPJXHAokqYd8YRmgrkLO4b+#=z6bMRP4QT$R66hkF7ev3fdZ0=.#=z1UGtBP4=()
|| | |+ OTHER <<mscorlib!String.SplitInternal>>
|| | |+ aspose.pdf!#=qoVrhiBciSukbg$QwrRyJNgXGy6PWv10Gl0Yy6R0BU8U=.#=zopjJks45hXgGogB_yWZA0Fk=()
|| | ||+ aspose.pdf!#=qoVrhiBciSukbg$QwrRyJNgXGy6PWv10Gl0Yy6R0BU8U=.#=zzpk9FWIHY8aVPmALGBTmE_R_E4Wl()
|| | || + OTHER <<mscorlib!StackTrace.CaptureStackTrace>>
|| | |+ OTHER <<mscorlib!String.InternalSubString>>
|| | |+ OTHER <<clr!?>>
|| | |+ aspose.pdf!#=qXsNxBVkFerbWWgv_b_teub0JrKH2vy5_unugXQfKz9E=.#=zpTdA0Q0=(int32)
|| | | + OTHER <<mscorlib!System.Collections.Generic.Dictionary2[System.Int32,System.__Canon].TryGetValue(!0,!1&)>> || | + aspose.pdf!#=qoVrhiBciSukbg$QwrRyJNgXGy6PWv10Gl0Yy6R0BU8U=+#=zSpUFyABac24hPBKN1eAnwCDNkxbN..ctor(class System.String) || | |+ OTHER <<mscorlib!System.Version..ctor(class System.String)>> || | |+ aspose.pdf!#=qXsNxBVkFerbWWgv_b_teub0JrKH2vy5_unugXQfKz9E=.#=zpTdA0Q0=(int32) || | ||+ OTHER <<mscorlib!System.Collections.Generic.Dictionary2[System.Int32,System._Canon].TryGetValue(!0,!1&)>>
|| | ||+ OTHER <<clr!?>>
|| | ||+ aspose.pdf!#=qXsNxBVkFerbWWgv_b_teub0JrKH2vy5_unugXQfKz9E=.#=zpTdA0Q0=(int32)
|| | || + OTHER <<clr!?>>
|| | |+ OTHER <<mscorlib!String.SplitInternal>>
|| | |+ OTHER <<mscorlib!String.StartsWith>>
|| | |+ OTHER <<mscorlib!String.InternalSubString>>
|| | |+ OTHER <<clr!?>>
|| | + aspose.pdf!#=qoVrhiBciSukbg$QwrRyJNgXGy6PWv10Gl0Yy6R0BU8U=+#=zsyve3GPPJXHAokqYd8YRmgrkLO4b+#=z$7HXQ3PmJSztUGm6x4YhsliFn$3
.#=zEcQEUmMGIYEzkgZammAr$S7cefC9()
|| | |+ OTHER <<mscorlib!Convert.FromBase64String>>
|| | |+ OTHER <<mscorlib!UTF8Encoding.GetString>>
|| | |+ OTHER <<clr!?>>
|| | + aspose.pdf!#=qXsNxBVkFerbWWgv_b_teub0JrKH2vy5_unugXQfKz9E=.#=zpTdA0Q0=(int32)
|| | |+ OTHER <<clr!?>>
|| | |+ OTHER <<mscorlib!System.Collections.Generic.Dictionary`2[System.Int32,System.__Canon].TryGetValue(!0,!1&)>>
|| | |+ aspose.pdf!#=qXsNxBVkFerbWWgv_b_teub0JrKH2vy5_unugXQfKz9E=.#=zpTdA0Q0=(int32)
|| | | + OTHER <<clr!?>>
|| | + OTHER <<mscorlib!String.InternalSubString>>
|| | + OTHER <<mscorlib!String.StartsWith>>
|| | + aspose.pdf!#=qoVrhiBciSukbg$QwrRyJNgXGy6PWv10Gl0Yy6R0BU8U=.#=zV7z10K2IqVbrS9UTqRQ4HDw=(class System.String)

@dfreder

Can you please preferably be using latest Aspose assemblies on your end and share if the behaviour is still getting reproduced or not. Meanwhile, I am also moving this query to Aspose.Total forum as it’s an issue concerned with multiple APIs.

@dfreder

We need to further investigate the scenario in our environment. As per our previous suggestion, please try to use the latest versions of all Aspose APIs and if the issue still persists, please share a sample application in .zip format which is able to replicate the issue. We will test the scenario in our environment and address it accordingly.