DLL hell; the elastic apm profiler vs OutSystems edition…

DLL hell; the elastic apm profiler vs OutSystems edition…

l.s.

We are running our applications on an OutSystems platform (v11.32.0 (Build 44177)) which is a lowcode platform hosted on a windows server 2022 IIS. For application monitoring we would like to run elastic apm profiler (v1.34.1).

However when adding the profiler to the application pool, the applications start throwing the following type errors.

This happens because the .dll used and loaded by apm is an older version then used by the OutSystems application:

ElasticAPMProfiler    System.Text.Encodings.Web.dll                         4.6.26515.06   4.0.3.0         cc7b13ffcd2ddd51

OutSystems Repository System.Text.Encodings.Web.dll                         8.0.23.53103   8.0.0.0         cc7b13ffcd2ddd51

OutSystems Scheduler  System.Text.Encodings.Web.dll                         8.0.23.53103   8.0.0.0         cc7b13ffcd2ddd51

I tried adding the following to the machine config but OutSystems does not pick this up.

      <dependentAssembly>

        <assemblyIdentity name="System.Text.Encodings.Web.dll" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />

        <bindingRedirect oldVersion="0.0.0.0-4.0.3.0" newVersion="8.0.0.0" />

      </dependentAssembly>

Copying the de dll’s from the OutSystems repository to the apm net462 directory works.

But I was hoping there is a better solution?

Any help would be much appreciated!!!

1 Like

Hi, @avanlieshout.

Unfortunately we have seen this previously, specifically with OutSystems. We don’t directly depend on that DLL, but one of our dependencies does. We have attempted to find solutions in the past but on all occasions, increasing our dependencies breaks test applications due to other conflicts.

I’m surprised binding redirects didn’t work as it’s the correct solution for .NET Framework applications.

Did you also try:
<bindingRedirect oldVersion="0.0.0.0-8.0.0.0" newVersion="8.0.0.0" />

Unfortunately, low-code solutions are closed boxes in most cases.

Our best solution to date has been copying the newer DLL into the install directly, which I’m please to hear is at least working as a workaround.

Thanks for the quick response, i will create a support ticket with outsystems as wel. If i get any usefull information i will update the topic.