2010-01-08 23 views
5

Tôi đã sử dụng mô-đun UrlRewriting.Net trong vài năm nay mà không gặp bất kỳ sự cố nào trong Windows XP và Windows 2003. Tôi vừa mới nâng cấp máy tính ở nhà lên Windows 7 và bắt đầu phát triển một trang web mới.UrlRewriting.Net Module + IIS7 Equals Page.User == null?

Kế hoạch là sử dụng phần mở rộng .html và viết lại chúng cho các đối tác .aspx của chúng bằng mô-đun UrlRewriting.Net. Tất cả mọi thứ hoạt động hoàn hảo trong VWD 2008, nhưng khi tôi thử chạy nó thông qua IIS7 nó là một câu chuyện khác nhau.

Khi tôi cố gắng truy cập trang qua .html ghi đè, tôi không còn có thể truy cập Page.User; nó tiếp tục trả về null. Nếu tôi nhấn trang bằng cách sử dụng phần mở rộng .aspx, Page.User được điền chính xác. Tôi cũng nên đề cập đến rằng tôi có một bộ điều khiển LoginView trong trang Master của tôi và nó bị các triệu chứng tương tự: Khi truy cập thông qua phần mở rộng .html nó cho thấy AnonyousTemplate; Khi sử dụng phần mở rộng .aspx nó hiển thị đúng LoggedInTemplate. Tôi đoán cả hai có liên quan.

[Lưu ý: Tôi cũng đã thử URL extensionless và chúng biểu lộ cùng một vấn đề]

Cách duy nhất tôi đã nhận được nó để làm việc là để chuyển đổi các hồ bơi ứng dụng cổ điển, sau đó đòi hỏi tôi phải thêm một trình xử lý DD.Net ASP.Net cho phần mở rộng .html [nếu không nó được xử lý bởi StaticFileHandler và xuất hiện dưới dạng lỗi 404]. Tuy nhiên, tôi muốn ứng dụng web của tôi chạy đúng cho mọi người mà không cần phải loay hoay với IIS.

Vì vậy, tôi để lại với một số câu hỏi:

  • Có ai có ý tưởng là tại sao Page.User luôn bằng null cho .html => .aspx viết lại trang?
  • Tại sao nó hoạt động trong VWD 2008, nhưng không phải IIS7?
  • Điều gì đã thay đổi từ IIS6 => IIS7 có thể đã gây ra điều này?
  • Bất kỳ suy nghĩ nào khác về cách giải quyết?

[Lưu ý: Tôi vừa thử .aspx => .aspx viết lại và nó không hiển thị sự cố. Không thực sự là những gì tôi muốn, nhưng nghĩ rằng tôi nên đề cập đến nó.]

Trả lời

11

Chỉ cần có một bước đột phá với mô-đun UrlRewriting.Net. Điều này làm cho nó hoạt động ở chế độ tích hợp trong IIS7:

<modules runAllManagedModulesForAllRequests="true">

Sau khi tìm nó ra tôi đã làm một tìm kiếm trên "runAllManagedModulesForAllRequests" và điều đầu tiên mà hiện lên là Scott Guthrie's blog mà thực sự cuộc đàm phán về việc sử dụng nó cho mục đích này.

+2

Có chế độ Tích hợp trong IIS là sự khác biệt chính giữa IIS6 & 7. Bạn có thể muốn xem xét Di chuyển ứng dụng ASP.NET từ IIS6 sang IIS7 (http://msdn.microsoft.com/en-us/library /bb515251.aspx). Như bạn đã khám phá, VWD 2008 chạy mọi thứ thông qua .NET, vì vậy nó chạy hiệu quả trong chế độ tích hợp với runAllManagedModulesForAllRequests được đặt thành true. – krohrbaugh

+0

Cảm ơn Sam. Bạn đang ở trên. Nó giải quyết vấn đề. Tôi sẽ bỏ phiếu cho câu trả lời của bạn nhưng không có đủ danh tiếng: ( – Heinnge

2

Một cách tiếp cận khác dường như hoạt động là xóa mô-đun Session và readd nó để lại hộp kiểm "Invoke only for requests to ASP.NET applications hoặc managed handlers" không được chọn. Nó trông giống như thế này trong file web.config:


<system.webServer> 
    <modules> 
    <remove name="Session" /> 
    <add name="SessionManualAdd" type="System.Web.SessionState.SessionStateModule, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" /> 
    </modules> 
</system.webServer> 

Có vẻ như vấn đề là các module phiên không thực hiện cho tiếng nói '* .htm' file khi HttpContext.RewritePath được sử dụng, nhưng loại bỏ và readding các mô-đun trong thời trang này gây ra xử lý phiên được thực hiện cho các yêu cầu.

Giải pháp này được đề xuất trên chuỗi bên dưới.Đáng tiếc là Microsoft quyết định không giải thích lý do đằng sau hành vi này hoàn toàn:

http://connect.microsoft.com/VisualStudio/feedback/details/357248/context-rewritepath-disables-session-module-in-iis7

+0

Xin chào, Tôi đã có phương pháp được đề cập ở trên "xóa rồi thêm lại phiên theo cách thủ công" .Tôi đã làm việc với phân trang của mình nhưng sau này khi tôi tạo CMS nó bắt đầu tạo ra các vấn đề với sự kiện Session_Start trong Global.asax Sự kiện này đã không bắn ở tất cả Sau đó tôi đã sử dụng phương pháp trên "runAllManagedModulesForAllRequests", tôi rất vui vì tôi có thể xem lại các trang của mình. Vì vậy, tôi muốn cảnh báo những người đang có kế hoạch sử dụng kỹ thuật đầu tiên Cảm ơn bài đăng của bạn, bạn thực sự đã giải quyết được vấn đề của mình. –

0

Microsoft bao gồm một sửa chữa cho vấn đề này (ít nhất là cho các url extensionless) trong Service Pack 1 cho Win7 và Windows Server 2008 R2: http://www.microsoft.com/download/en/details.aspx?id=5842

Cũng sẵn như là một hotfix: http://support.microsoft.com/kb/980368

Sau khi vá này được áp dụng, ASP.NET 4 ứng dụng có thể xử lý các yêu cầu đối với các URL extensionless. Do đó, các HttpModules được quản lý chạy trước khi thực thi trình xử lý sẽ chạy. Trong một số trường hợp, HttpModules có thể trả về lỗi cho URL không mở rộng. Ví dụ, một HttpModule được viết để chỉ mong đợi các yêu cầu .aspx bây giờ có thể trả về các lỗi khi nó cố truy cập thuộc tính HttpContext.Session.

Sau khi áp dụng SP1 hoặc hotfix, không cần thay đổi web.config để làm cho phiên và biểu mẫu auth hoạt động cho URL không mở rộng được viết lại cho trang asp.net/trình xử lý/v.v.

Tôi không biết điều này có khắc phục được bất kỳ điều gì để ghi đè lên các đuôi tệp tĩnh như .htm hay không. Tôi đoán có lẽ là không. Tôi sẽ cố gắng tránh thiết lập runAllManagedModulesForAllRequests = "true" trong môi trường sản xuất, bởi vì nó bổ sung thêm chi phí không cần thiết cho các yêu cầu tệp tĩnh.