之前提過，我們公司是使用VS.NET 2003 C#開發Smart Client的架構，從上星期把Prototyping放到Window 2003的IIS 6上執行，一直驚喜不斷…
今天又發現了一個問題，放置Smart Client的虛擬目錄，無法讀取之下的Bin子目錄，更利害的是又不是一直不能讀取，而在數個小時的努力之後，忽然有一次可以，然後又不行，一直無法理解…
後來，終於找到問題了！
原來Window 2003的Default Policy，為了保護asp.net_isapi.dll，而有一個Default Filter，會保護Bin的目錄。也就是說，基本上IIS 6的基本作法與.NET Framework有差異
.NET Framework的邏輯是，當你呼叫一個Dll時，首先會到本機的GAC中搜尋，如果不存在，會直接找尋執行程式的相同目錄下是否存在；若是仍然不存在，而會到執行目錄的Bin子目錄下尋找。而IIS 6.0卻把它的機制，用另外一種方法關閉了，害我們忙了一整天解決的方法：
1.在IIS 6.0 伺服器，點選開始–>執行
2.找到
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET3.新增一個DWORD VALUE：Name = StopBinFiltering，Value=1ps：若想恢復原本的IIS 6.0的設定，請把StopBinFiltering的Value，設為 0 即可

原文：http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/54e9382b-743d-495e-a324-b8b57a5214ee.mspx

All requests with /bin in the URL are rejected and return a 404 error (IIS 6.0)

This occurs when IIS 6.0 and ASP.NET are both installed. In order to take a more proactive stance against malicious users and attackers, the ASP.NET ISAPI filter, aspnet_filter.dll, blocks incoming request containing /bin in the URL. This behavior occurs server-wide, regardless whether the request is for static or dynamic content.

The preferred solution to this issue is to modify the path to content on the server so that /bin is not necessary in any request.

If the content URL cannot be modified, an alternative solution is to set a registry key that stops the ASP .NET ISAPI filter from filtering requests containing /bin in the URL. This is a server-wide setting.

Procedures

  Important

Setting the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\ registry key can allow a malicious user access to programs and content in the /bin directory.

To disable /bin filtering

1.	In the details pane, right-click, point to New, and click DWORD Value.
2.	In the Name box, type the following: StopBinFiltering.
3.	Double-click the StopBinFiltering value, and in the Value data box type 1.
4.	Click OK, and then close Registry Editor.
5.	To reenable /bin filtering, set the StopBinFiltering value to 0.