Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.
REVDOTNET error on some users
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.
"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.
Comments
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?
I haven't attempted to try them with SRPMail but caspol should work to resolve this.
This is the response from IT:
<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.