1

Closed

loadFromRemoteSources bug

description

The below exception is occuring on some computers when starting up.
System.IO.FileLoadException: Could not load file or assembly 'file:///C:\Users\Administrator\AppData\Local\Temp\SEToolbox\__bincache\Sandbox.Common.XmlSerializers.dll' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)
File name: 'file:///C:\Users\Administrator\AppData\Local\Temp\SEToolbox\__bincache\Sandbox.Common.XmlSerializers.dll' ---> System.NotSupportedException: 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.
   at SEToolbox.CoreToolbox.Load(String[] args)
   at System.Windows.Application.<.ctor>b__1(Object unused)
   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
   at MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(Object source, Delegate method, Object args, Int32 numArgs, Delegate catchHandler)
At the moment I believe it to be some sort of zone trust issue.
When a file is downloaded from the Internet, it's automatically put into a "Internet" zone.
Looking at the properties of the downloaded .zip or .msi file in the "Downloads" directory, there is an additional Security property to Unblock the file.
Image

I'm not sure at this stage if it is SEToolbox that is somehow installed under limited trust and then tries to load the SE assemblies which are under full trust.
Or, SEToolbox running under full trust and it's accessing the SE assemblies which may be under partial trust because they have been copied under the Temp folder.

There are a couple things to note here.
Running the .MSI installed on a Windows 8 PC, the .MSI automatically has its security property changed.
Extracting the .ZIP on a Windows 7 PC with the built in Windows .zip support, will keep the restricted security property on the extracted files. Using 3rd party utilities like 7-Zip or WinRar will removed the restricted security on the extracted files.

Confirmed OS affected so far: Server 2008.

The current workaround is to use the /OLDDLL parameter when starting SEToolbox.
Closed Feb 2, 2016 at 12:37 AM by midspace
As this issue is quite old and there has been no further responses from the reporter I am closing it.

If someone believes this is still required, then a new issue must be logged here:
https://github.com/midspace/SEToolbox/issues/new

comments

wrote Jul 7, 2014 at 11:15 PM

Associated with changeset 27594: Shifted the cachebin folder to a more suitable location and applying checks against thre binaries without deleting them.
Hopefully this will fix the 1392 issue also.

midspace wrote Jul 23, 2014 at 9:40 AM

Previously I had SEToolbox storing the bincache in %AppData%\Local\Temp\SEToolbox__bincache
Changeset 27594 had them moved to %AppData%\Local\MidSpace\SEToolbox__bincache

The Temp directory can be volatile and easily influenced by windows overprotective security, which is why it was removed from there, but it still needed to under user AppData.

I have not received any negative feedback since this change, so I'm closing this issue.

wrote Jul 23, 2014 at 9:40 AM

midspace wrote Jul 24, 2014 at 10:37 AM

** Closed by midspace 23/07/2014 02:40

wrote Jul 24, 2014 at 10:37 AM

wrote Jul 24, 2014 at 10:38 AM

midspace wrote Jul 24, 2014 at 10:39 AM

Newly logged report on this bug.

https://setoolbox.codeplex.com/discussions/552651

wrote Aug 1, 2014 at 6:08 AM

Resolved with changeset 27898: Added additional exception report detail.

midspace wrote Aug 1, 2014 at 6:09 AM

** Closed by midspace 31/07/2014 23:08

wrote Aug 1, 2014 at 6:09 AM

midspace wrote Aug 1, 2014 at 6:09 AM

Accidently closed on check in. :(

midspace wrote Feb 2, 2016 at 12:36 AM

I've removed the whole load from another directory functionality, so this issue should no longer be relevant.
I've never been able to replicate it, but that doesn't mean it doesn't exist under certain circumstances.

Under recent tests at work I found a the same exception occurring because it was running under a remote session on a Windows Server.

If I should revisit it, using the following in the app.config may resolve the issue.

<?xml version="1.0"?>
<configuration>
<runtime>
<loadFromRemoteSources enabled="true"/>
</runtime>
</configuration>

wrote Feb 2, 2016 at 12:37 AM