Whose responsibility is it? Fixing LoadLibraryEX on ISAPI filter problem.

One of our clients encountered a problem running our web application after they installed it this week. The error message displayed in the browser when navigating to the web application from the web server had something like, “Server Error in Application. Calling LoadLibraryEx on ISAPI filter E:\Mail\Program\ClientAccess\owa\auth\owaauth.dll”. After some trial and error and some Internet searching we resolved the problem by setting a precondition for the isapiFilter in the web.config of the Default Web Site.

<isapiFilters>

<filter name=”Exchange OWA Cookie Authentication ISAPI Filter” path=”C:\Program Files\Microsoft\Exchange Server\ClientAccess\owa\auth\owaauth.dll” enabled=”true” preCondition=”bitness64″ />

</isapiFilters>

Our web application has been installed on over 100 clients and we’ve never encountered this problem. Our first tier of support was stumped
when they first saw the error message also.   However, they could see that the problem was related to Outlook Web Access, and thus it would be very easy to tell our client that they needed to solve the problem themselves, or contact Microsoft to solve the problem.  This leads to the reason for this blog post:

When a software/hardware computer problem occurs due to the interaction of multiple software products, whose responsibility is it to make
the software products compatible so that all the products involved work correctly?

I don’t think our industry has solved this problem, I don’t think we ever will solve this problem, and I fear the problem is getting worse,
particularly as we become more dependent on software to help us through our lives and jobs.  I have seen many approaches to the problem:

• Some software vendors are willing to lose a sale if a client can’t get their product working.
• Some software vendors won’t refund the money if the client can’t get their product working and are willing to accept a negative review or blog post or publicity.
• Some software vendors work with the client until the issue is resolved.

What would you do?

We resolved the problem after finding these two articles:

http://social.technet.microsoft.com/forums/en-US/exchangesvrclients/thread/94c812b5-4bd5-41eb-8396-462e03295201/

http://blogs.msdn.com/b/david.wang/archive/2008/10/30/howto-precondition-an-isapi-extension-dll.aspx

In short, our web application is compiled to run as 32bit, but the Outlook Web Access ISAPI filter is a 64bit DLL and attempted to load into the App Domain we configured (as 32bit) for our application.  The fix tells IIS to only apply the Outlook Web Access ISAPI filter to App Domains that support 64bit.

Apply your Strong Name Key to both DLLs to resolve Friend access was granted compiler message in C#

You will get a compiler error message like:

“Friend access was granted to ‘your dll, PublicKey=your key’, but the output assembly is named ‘your dll, Version=…, Culture=neutral, PublicKeyToken=null’. Try adding a reference to ‘your dll…’, or changing the output assembly name to match.”

when you are using Strong Named Keys (snk) files but you only have the .SNK file assigned to one of the two projects you are trying to compile. If you are using InternalsVisibleTo to expose Friend/Internal methods to another DLL, and either one of the DLLs has a strong named key, make sure they both have a strong named key. You can use the same strong name key on both DLLs.