title: Loaded DLL works only if the loader program is compiled as debug
body: <p>I have a very simple C# code that reads a DLL and loads it, the problem is: if I compile with a &quot;Debug&quot; profile, or a copy of it, it works, if it is a &quot;Release&quot; profile, or a copy of it, it throws an exception.</p>
  <p>The code is essentialy this</p>
  <pre><code>static void Main(string[] args) {
          FileStream s = new FileStream(&quot;file.dll&quot;, FileMode.Open, FileAccess.Read);
          int l = (int)new FileInfo(&quot;file.dll&quot;).Length;
          BinaryReader br = new BinaryReader(s);
          byte[] data = br.ReadBytes(l);
          Assembly asm = Assembly.Load(data);
          asm.DefinedTypes.Where(type =&gt; type.Name == &quot;Program&quot;).First()
                          .GetMethod(&quot;Main&quot;, new Type[] {typeof(string[])})
                          .Invoke(null, new object[] { new string[] { } });
  }
  </code></pre>
  <p>I tried enabling and disabling Code Optimization, defining and undefining TRACE and DEBUG constants, no difference, if the profile is a copy of Release, or Release/Publish, it does not work. And here's the weirdest part, in both cases it loads the DLL, however in Release it throws a failed decryption exception inside the loaded DLL, what seems extremely random.</p>
  <p>I am 100% stumped as I can't find what Visual Studio does different for these profiles other than optimization(which I tried enabling/disabling), and I am not sure how this even should make a difference considering the same DLL is loaded.</p>
  <p>Per request, the exception thrown is:
  &quot;FormatException: The input is not a valid Base-64 string as it contains a non-base 64 character, more than two padding characters, or an illegal character among the padding characters.&quot;</p>
  <p>It itself is not the problem, it happens because it receives an empty response after sending invalid encrypted data to another service, however if the loader is compiled as Debug, the message sent is valid, and so also the response, and the exception does not happen.</p>