If the new system is a 64-bit OS system, then during compilation “target platform” should be set to 64-bit (and not “Any Platform”).
more info here:
http://blogs.msdn.com/delay/archive/2006/03/23/559142.aspx
If the system is OK (32bit OS) then the following steps should help:
To find exact errors the following tools should be used.
1. Assembly Binding Log Viewer (Fuslogvw.exe). (part of SDK Tool v2.0) (http://msdn2.microsoft.com/en-us/library/e74a18c4(VS.80).aspx)
Just run the viewer, enable the “Log bind failures to disk” setting, run the tool again, then refresh the viewer and open the failed binding entry (open all entries one by one until you see failing entry)
2. Filemon for windows (http://www.microsoft.com/technet/sysinternals/utilities/Filemon.mspx)
Run Filemon, specify a filter of “*tool_name*” to limit the output, then run the program of interest. Filemon will capture a whole bunch of stuff, so save the output to a file where it can be searched more easily.
Ex:
In my case the problem was that PDFLIB was using 2 libraries:
– pdflib_dotnet.dll
– msvcr71.dll
In manual for using PDFLIB with ASP.NET it states that:
“Both pdflib_dotnet.dll and msvcr71.dll should be placed in bin folder”
ASP.NET compiler was looking for msvcr71.dll within the folder C:/windows/system32 (and many other folders).
Without going too deep in the details, i just copied one copy of msvcr71.dll from the bin folder to the system32.
Voila, everything started working.
Apparently system was set up some weird way and ASP.NET compiler was looking for msvcr71.dll in system32. Because the website works even without “msvcr71.dll” placed in a bin folder.