I was assisting one of our customers move their .NET applications from one server to another and run them using Windows Task Scheduler. I did highlight to them that in order to make the application work, we have to make sure that the correct .NET Framework version was installed on the target server, that the correct .NET Framework version was referenced by the assemblies used (this is very important when the target server has multiple versions of the .NET Framework installed and the assembly was created using an older version) and that the appropriate permissions were given to the accounts that will launch the EXE files from within the Windows Scheduled Tasks. I wasn’t surprised when after the move, I saw this error from calling the assembly from the command prompt

System.IO.FileNotFoundException: Could not load file or assembly ‘MyAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=0e1d67af9d31f077’ or one of its dependencies. The system cannot find the file specified.
File name: ‘MyAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=0e1d67af9d31f077’ —> System.IO.FileNotFoundException: Could not load file or assembly ‘MyAssembly’ or one of its dependencies. The system cannot find the file specified.
File name: ‘MyAssembly’

This blog post highlights a couple of different reasons why an assembly would not load. What I would like to highlight, though, is the use of a pointer to the correct .NET Framework version in the application’s config files.

A lot of developers in the past simply didn’t realize that it would be possible to co-exist different versions of the .NET Framework in a single machine yet cause application issues if not handled properly. This Microsoft document, although relatively old, describes how to manage multiple versions of the .NET Framework on a single machine. If unsure, you might want to enable the Assembly binding logging option thru your registry key

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftFusion!EnableLog] (DWORD) = 1

You can also use the Assembly Binding Log Viewer tool if you have the SDK Tools installed on your target machine (of course, as best practice will tell you, you wouldn’t install anything unnecessary on your production servers)