We have an application that is built on .NET 4.0 Client Profile and uses SQL Server Compact Edition. Because it does not rely on the latest core OS technologies, it runs very well on older Windows versions, which is required by the end-users. To test the latest version I booted a fresh Windows XP virtual machine, and successfully installed the app on it. However the app crashed at the first database operation with the following exception:
System.DllNotFoundException: Unable to load DLL ‘sqlceme35.dll’: The specified module could not be found. (Exception from HRESULT: 0x8007007E)
Obviously, the requested file was in the right folder, and we didn’t change anything in the last version of the app that could explain this exception. So what has been changed?
I couldn’t reproduce the issue neither on Windows 8.1, nor on Windows 7, and not even on older XP machines that had the previous version of the app. And although the previous version was running perfectly on XP, it crashed in the fresh VM, so my conclusion was that something is different in the VM.
First I used the VM downloaded from the modern.ie site, and I thought that VM has some specificity that breaks our app. So I installed Windows XP from ISO and spent hours and hours to install all the patches from Windows Update. However it didn’t help, the app crashed like before.
Finally I used ILSpy and peeked into the System.Data.SqlServerCe assembly, and because it was referencing .NET Framework 2.0, I gave it a try and installed that older Framework version side-by-side to the new version. And to my surprise the issue was gone!
The beauty of the case:
- Windows Update was not installing .NET Framework 2.0, only the newer version. It was not the case previously.
- The .NET 4.0 Client Profile was not enough, SQL Compact Edition required version 2.0 as well.
- I understand that there was no problem on Windows 7, because that OS contains .NET 2.0, but why didn’t the app crash on Windows 8.1 which doesn’t install .NET 2.0 by default?