Sytem.IO.FileLoadException in custom script after upgrade

We recently upgraded OneIdentity to 8.1, and one of our custom scripts started failing with:

System.IO.FileLoadException: Could not load file or assembly 'PhoneNumbers, Version=8.8.11.0, Culture=neutral, PublicKeyToken=cad7840cee602442' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)


I checked Software Loader, and the version in the database is 8.10.21.0, which is different from what the script compiled against. I assumed that something got cached and not recompiled internally, so I added a dummy line to the custom script that is failing, recompiled the database and everything is working agian.

However, a few days later (I'm assuming after I made changes to another custom script and recompiled the database again), the same error started appearing. I fixed it again by doing the same thing.

I'm still assuming that there's an issue with how the assemblies are compiled by OneID, but I'm not sure how to fix or diagnose further, any suggestions?

  • One Identity Manager 8.1 is coming with version 8.8.11.0 of the PhoneNumbers.dll. So if you are having a newer version in your database, it might be the case that some of your customizing (Script, WebDesigner, ...) used the lib before One Identity Manager did. That would explain why the version is different.

    One option would be to upload the version PhoneNumbers.dll coming with OneIM into the database using SoftwareLoader and see if this solves the issue.

  • Additionally, you can configure a binding redirect in the .NET configuration files to work around the version discrepancy.

  • I think this would fix the issue (although I still don't know why the custom script gets compiled dfferent versions of PhoneNumbers.dll whenever I hit compile).

    Where should I put the binding redirects for this? I'm not sure how OneId exactly recompiles the scripts and what controls it.

  • Did you try to load the ootb version of the PhoneNumbers.dll back to the database? Does it solve your issue?

  • While I was investigating further, I noticed that we actually had two versions of the dll loaded at the same time. I think we somehow ended up in this situation while upgrading. We already had an older version of the dll loaded for use in one of our custom scripts, and after the upgrade we had both that and the new one.

    It looks like our database custom scripts were getting compiled sometimes against one version, sometimes against another, but there was only one version available to the script during runtime.

    I deleted the old version of the dll in designer and recompiled, and the issue seems to have been fixed.