I was recently working on a project where a developer inadvertently added a 32-bit assembly reference to the project.
Of course, the application worked just fine on the developer's machine, however, when it was deployed to the web server, an assembly loading error message was encountered!
Having seen that error message earlier, we immediately recognized that a 32-bit assembly reference had been inadvertently added to the project/solution and since IIS was not configured to run as a 32-bit application, this error message inevitably popped up.
However, we did not understand how it ever worked on the developer's machine!
Well, as it turns out, the developers was using the built-in version of IIS Express that ships with Visual Studio 2013. Since Visual Studio 2013 itself is a 32-bit application, we assumed it was also using a 32-bit version of IIS Express.
When I ran the application in Visual Studio and looked at Task Manager, our suspicions were confirmed:
The IIS Worked Process clearly indicated that it was a 32-bit process, thereby explaining why the solution worked perfectly on the developer's machine but failed to work when deployed to a full 64-bit version of IIS.
This not only taught us the differences between developing with IIS Express in Visual Studio vs developing with IIS, but also the tremendous importance of having a robust and reliable continuous integration system!!
Of course, the application worked just fine on the developer's machine, however, when it was deployed to the web server, an assembly loading error message was encountered!
Having seen that error message earlier, we immediately recognized that a 32-bit assembly reference had been inadvertently added to the project/solution and since IIS was not configured to run as a 32-bit application, this error message inevitably popped up.
However, we did not understand how it ever worked on the developer's machine!
Well, as it turns out, the developers was using the built-in version of IIS Express that ships with Visual Studio 2013. Since Visual Studio 2013 itself is a 32-bit application, we assumed it was also using a 32-bit version of IIS Express.
When I ran the application in Visual Studio and looked at Task Manager, our suspicions were confirmed:
The IIS Worked Process clearly indicated that it was a 32-bit process, thereby explaining why the solution worked perfectly on the developer's machine but failed to work when deployed to a full 64-bit version of IIS.
This not only taught us the differences between developing with IIS Express in Visual Studio vs developing with IIS, but also the tremendous importance of having a robust and reliable continuous integration system!!
No comments:
Post a Comment