Friendly Reminder: If you release a NuGet package please sign all the DLLs.

Please. I am begging you. If you release NuGet packages sign both the Debug and the Release DLLs. Do not just sign the Release DLLs.

I wasted four hours today debugging the following exception: “FileLoadException: A strongly-named assembly is required. (0x80131044)”.

I was debugging the debug build of an application that uses the Titanium.Web.Proxy version 3.1.1397, obtained using NuGet. The Titanium.Web.Proxy uses BouncyCastle.NetCore version 1.8.10.

I have a python script that copies the build output from the output directory to the appropriate location on my test PC where I have the product I am working on installed. This python script replaces the files already present in the application installation directory with the files produced by building the product on my development PC.

The build process, which uses MSBuild, copies the DLLs for BouncyCastle.NetCore and Titanium.Web.Proxy to the output directory. This is useful for release builds because the installer project pulls all DLL and EXE files from the build output directory. My python script previously copied the BouncyCastle.NetCore and Titanium.Web.Proxy files to my test PC in addition to all the DLL and EXE files for the application.

The problem is that the Debug DLLs for BouncyCastle.NetCore and Titanium.Web.Proxy are not signed. When a .NET assembly depends on another assembly and the dependent assembly is not signed .NET will throw a “FileLoadException: A strongly-named assembly is required. (0x80131044)” exception when the first assembly attempts to load the dependent assembly.

It took me four hours to find out why this exception was occurring.