Unsafe Dependency Loading on Windows

[mobiusklein]

Platform: Windows 10
.NET Version: 4.7.2

I'm unable to run the program either built from source or from the released executable.
Stack Trace (line wraps added for clarity):

2019-05-06 08:51:37,026 INFO ThermoRawFileParser.RawFileParser - Started parsing ./A0002275_1-Bin40_1-L243-1.raw
2019-05-06 08:51:37,145 ERROR ThermoRawFileParser.MainClass - An unexpected error occured:
2019-05-06 08:51:37,148 ERROR ThermoRawFileParser.MainClass - System.TypeInitializationException: 
    The type initializer for 'ThermoFisher.CommonCore.Data.Business.RawFileReaderFactory' threw an exception. ---> 
    System.IO.FileLoadException: ThermoFisher.CommonCore.RawFileReader.dll is not found in C:\Users\jklein\Downloads\ThermoRawFileParser --->
    System.IO.FileLoadException: Could not load file or assembly 'file:///C:\Users\jklein\Downloads\ThermoRawFileParser\ThermoFisher.CommonCore.RawFileReader.dll'
    or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515) ---> 
    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.
   --- End of inner exception stack trace ---
   at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
   at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
   at System.Reflection.RuntimeAssembly.InternalLoadFrom(String assemblyFile, Evidence securityEvidence, Byte[] hashValue, AssemblyHashAlgorithm hashAlgorithm, Boolean forIntrospection, Boolean suppressSecurityChecks, StackCrawlMark& stackMark)
   at System.Reflection.Assembly.LoadFrom(String assemblyFile)
   at ThermoFisher.CommonCore.Data.ObjectFactory`1.Initialize(Boolean throwExceptions)
   --- End of inner exception stack trace ---
   at ThermoFisher.CommonCore.Data.ObjectFactory`1.Initialize(Boolean throwExceptions)
   at ThermoFisher.CommonCore.Data.Business.RawFileReaderFactory.CreateReader()
   at ThermoFisher.CommonCore.Data.Business.RawFileReaderFactory..cctor()
   --- End of inner exception stack trace ---
   at ThermoFisher.CommonCore.Data.Business.RawFileReaderFactory.ReadFile(String fileName)
   at ThermoRawFileParser.RawFileParser.Parse(ParseInput parseInput)
   at ThermoRawFileParser.MainClass.Main(String[] args)

Based upon this stack trace, it looks like there is an unresolved dependency for the RawFileReader.dll, since it is present in the same directory as the executable in the release.

A possible solution is to add an XML configuration file with the contents

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <runtime>
    <loadFromRemoteSources enabled="true" />
  </runtime>
</configuration>

which will get picked up and added to the application config file during the build process. I'm not sure this is desirable though, since it means that the program cannot run "offline".

[caetera]

Hi Josua,
this is a Windows related issue and not specific to ThermoRawFileParser. I have the same error with other .NET assemblies. Windows keeps a special "mark" on all files that are downloaded from the network, considering them as potentially unsafe. One can unblock them as described here: https://blogs.msdn.microsoft.com/delay/p/unblockingdownloadedfile/, or as you suggested change the configuration file to allow "potentially unsafe" assemblies downloaded from the network.

[mobiusklein]

Okay, the MSDN article that the error message points to is not helpful for resolving the problem for the end user then. Could this manual step be documented then?

Alternatively, I thought the RawFileReader library was composed of four DLLs. Are the other two DLLs being loaded from the web, and if so, could they be included in the bundle of static assets to simplify use?

[ypriverol]

@mobiusklein @caetera should we add a FAQ section to the readme explaining these issues?

[mobiusklein]

That would reduce the number of confused issue reports, but I'd rather know what 3rd party resources I'm resolving at run time rather than at build/installation time. Is it actually functional code that is being fetched, or is this a method for letting Thermo log every time the DLL is loaded?

When I wrote redistributable bindings against RawFileReader, I had to bundle four DLLs downloaded from the internet, but they did not need to be "unblocked" in order for me to load them.

[caetera]

@mobiusklein this is just confusing wording. "Remote source" in this case does not mean that you fetch anything from any remote system at runtime. The installation is local. This is a specific Windows protection feature. It remembers files that were downloaded from the network (assuming them as potentially malicious). The information is stored in a so-called NTFS alternate data stream. In case of .NET assemblies, runtime environment blocks the loading of this "potentially malicious" code by default. The user has to either allow "dangerous" code by enabling loadFromRemoteSources, or unblocking the assembly (i.e explicitly stating that you trust it). As soon as one does not use Windows or does not use NTFS (there are no alternate data streams on FAT, for example), the issue will not appear. So, you should not worry, it is safe, and Thermo is not logging anything (at least not like this). Please, let me know if my explanation was clear.

@ypriverol It is up to you, the developers, to decide, whether it is more natural to have FAQ or include this information in readme/user manual as Windows specific installation instruction. I am happy to help in any way.

[ypriverol]

@caetera you add a PR where you add the issue to into a FAQ section and how to solve it?

[mobiusklein]

@caetera Thank you. That explanation clarified the problem. The error message is still coloring how I read your description, but this is the first time I've had this problem with downloaded .NET code.

Is it more preferable to force the users to take an action rather than fix the problem at build time still? I've tested the configuration change on Windows, but I don't have a *nix system with Mono to test on.

[ypriverol]

@caetera Can this be fixed in our side with this solution:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <runtime>
    <loadFromRemoteSources enabled="true" />
  </runtime>
</configuration>

I don't have a Windows machine here.

[caetera]

@ypriverol Yes. You will need to create an Application Configuration Template in Visual Studio project and add the code into it. Then the configuration will be created during build.
Alternatively, here is oneliner that unblocks all files after unpacking
for /f "usebackq delims=|" %%f in (dir /b) do echo "" > %%f:Zone.Identifier
(pretty ugly though)
Can make PR from any of this, if you prefer.

[ypriverol]

@caetera looks like the config solution is more appropriate. Do a PR and I will merge it and test with mono, and you can test it in your windows.

[caetera]

PR done.
Tested in W7 and Ubunty.

[ypriverol]

@caetera Quick question here about the PR: #40 (comment)

[ypriverol]

@mobiusklein @caetera We included in the new release https://github.com/compomics/ThermoRawFileParser/releases/tag/v1.1.4 the changes included by @caetera . Can you test on your side. ?

[mobiusklein]

Looks like it broadly worked on my end, though the file is 746,213,376 bytes with this version compared to 746,278,912 bytes from the previous version built from source. Did something else change?