REVDOTNET error on some users

prattspets

I have upgraded the SRP Mail Utility to version 3.0.1.2. We use a terminal server with multiple users on OI. Most users have no issues with the new DLL, but there are 2 users that experience a lengthy error message as a result from the call:

"RevDotNet Error: Assembly 'SRPMail.dll' not loaded: Exception: Could not load file or assembly 'file:///O:\OInsight\SRPMail.dll' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515) Inner Exception: An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch. See http://go.microsoft.com/fwlink/?LinkId=155569 for more information."

I have checked with IT about it because it's odd that it only happens to 2 users out of 10+. They've checked permissions, etc. on the server. I believe they have been working with Kevin a little also, but I thought I'd see if I can close the loop of communication a bit and see if there are some things I haven't considered.

DonBakke

I believe Kevin sent a response to your IT representative almost two weeks ago which referenced this stackoverflow article. Was this followed up on?

prattspets

The latest communication they said that they had with SRP was on the 16th and they suggested the following.

You must either unblock the SRPMail.dll directly from the property panel or modify the .NET Framework's maching.config file to tell .NET to trust all remote DLLs. This, of course, comes with some security considerations.

I got the dreaded COVID, so I had put this off for a while and hadn't responded until today. I'll have them set the trust to ALL remote DLL's and see if that makes a difference. I just wanted to see if you had any other thoughts in case this is a dead end also. Could I use an older version of the SRPMAIL.dll that does not have .NET dependencies if necessary?

DonBakke

We have no other thoughts as we were waiting to see how this panned out. Kevin is out until mid-next week so he wouldn't have any follow-up until then anyway. I suppose you could roll back to an earlier version of the SRP Mail utility, but you will lose potentially necessary features (like TLS support) as a result. Also, support for that version of the product would be limited.

JaredBratu

5 to 10 years ago when OI 9 first came out I believe I had commands for the caspol utility to allow .net assemblies to load from network shares. As I recall this could be limited to a specific share or specific assemblies. So it should be able to open up access to just the OpenInsight share or it's assemblies but this will need to be done on each workstation so you'll either need a policy to push it out to all the workstations or integrate the command into your existing workstation setup script so new workstations trust the OpenInsight share to run .net assemblies.

I haven't attempted to try them with SRPMail but caspol should work to resolve this.

prattspets

I just wanted to report back that our IT company tried the following and did not have success. I have not forwarded the information from Jared as of yet, but I will collaborated with them on caspol next.

This is the response from IT:

On June 27th I made the suggested change from Kevin Fournier @ SRP to machine.config and added the setting:
<configuration>
<runtime>
<loadFromRemoteSources enabled="true"/>
</runtime>
</configuration>

You let me know that it did not fix the issue. I removed the above addition from the config on July 2nd.

On June 30th I ran the powershell command unblock-file, all this does it unblock the file from loading if it is blocked or has a hidden blocked tag. This also did not work as you reported.