[SOLVED] Costura Fody throwing error with FodyIsolated.dll


I’ve built a WPF application, and used Costura.Fody to combine it into one exe. This has worked until today, and the only change that I know of is that I upgraded Visual Studio (Community edition to 15.7.2).

It now throws an error when building, immediately after starting:
Could not load file or assembly '<directory of my app>\packages\Fody.3.0.3\netclassictask\FodyIsolated.dll' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)

I’ve tried a number of things:

  • Checking that FodyIsolated.dll is not blocked (it’s not)
  • Upgrading to the latest version of Costura.Fody Nuget
  • Uninstalling and Re-installing Costura.Fody Nuget
  • Downgrading to the version that worked previously
  • Adding <loadFromRemoteSources enabled=”true”> to my app.config
  • Adding <loadFromRemoteSources enabled=”true”> to the devenv.exe.config in the Visual Studio install directory
  • Adding the IP of the network drive that my application is stored on to the Local Intranet zone in internet options (the application is stored on a network drive)

One of the above solutions has worked for everyone else facing this issue, but none of them has helped me. I’m hoping somebody can give me another option, or point out where I’m going wrong.

To be clear, if I remove Costura.Fody, the app builds fine, but obviously has all of the dlls separate to the exe.


I managed to solve this myself, after a bit more experimentation and research.

I’d noticed a common theme with this particular error was files on network drives, so I tried running the solution from my C drive, and to my surprise it built with no issues.

So I then did a bit more googling and stumbled upon this: https://blogs.msdn.microsoft.com/shawnfa/2009/06/08/more-implicit-uses-of-cas-policy-loadfromremotesources/

The important part of it is how it treats assemblies being loaded. I was in the right area with adding the IP of the server to intranet zone, it just needed to be the full path of the folder that the solution was in.

So if anyone else has this issue, try adding your solution’s folder to the intranet zone, as that fixes it.

Answered By – James R

Answer Checked By – Gilberto Lyons (BugsFixing Admin)

Leave a Reply

Your email address will not be published. Required fields are marked *