tags:

views:

2571

answers:

2

We have some HTTP handlers specified in our web.config. When we were running this site via a Web Site Project, all worked fine. But for some reason, after porting this over to a WAP project and pointing to the .NET 3.5 framework, the handlers are not working when I bring up the site in IIS 7 on our dev box. Do I need to do something special in IIS7 other than the specified custom handlers that already exist in my web.config?

When I look at the Handler Mappings section in IIS 7 for our site, I do see the 3 handlers listed with our custom extension. So it looks like it's picking up our handlers specified in our web.config. But I know that the handlers that were working in a non-wap website are not working in this WAP project and I don't know why.

For example, when one of our handlers tries to kick in when referenced I get:

Server Error in '/' Application. Parser Error Description: An error occurred during the parsing of a resource required to service this request. Please review the following specific parse error details and modify your source file appropriately.

Parser Error Message: Could not create type 'jaxHandler'.

Source Error:

Line 1:  
Line 2:  
Line 3:  using System;


Source File: /jaxHandler.ashx    Line: 1

Version Information: Microsoft .NET Framework Version:2.0.50727.3074; ASP.NET Version:2.0.50727.3074

furthermore, when I try to click on a hyperlink on our site that has .customextension on it the handler doesn't seem to pick it up.

So when I click on the hyperlink, I get:

HTTP Error 404.0 - Not Found
The resource you are looking for has been removed, had its name changed, or is temporarily unavailable. Detailed Error InformationModule IIS Web Core 
Notification MapRequestHandler 
Handler StaticFile 
Error Code 0x80070002 
Requested URL http://sss:80/somename.prod
Physical Path C:\www\sss\somename.prod 
Logon Method Anonymous 
Logon User Anonymous

(I have replaced the real text with 'somename' and our company name with 'sss') in the case above for privacy.

If I look in the Http Handlers section in IIS7, I do see that *.prod is registered. And here is how we have it set up in our web.config under the custom section:

<add name="sss" path="*.prod" verb="*" modules="IsapiModule" scriptProcessor="C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll" resourceType="Unspecified" preCondition="bitness32"/>
+3  A: 

For ASP.NET applications running on IIS7, HttpHandlers should be mapped in the <system.webServer> section of your web.config. In IIS6, they were mapped in the <system.web> section.

<system.webServer>
    <handlers>
        <add name="HandlerName" 
             path="HandlerPath" verb="*" type="Handler.Type"
             resourceType="Unspecified" />
    </handlers>
</system.webServer>
Kevin Babcock
yes, we have ours mapped to webServer because this site is running already on our prod server in IIS7
CoffeeAddict
A: 

What you need to do is build your code.

You need to copy all the C# code out into a .ashx.cs file. In fact, I recommend you create a new .ashx and copy the C# code into its .ashx.cs file.

Web sites build dynamically. Web Application Projects, like every other similar project type in Visual Studio, need to have code in source files, and to have that code build into an assembly.

John Saunders
the .ashx does not have a code behind. I see. Yea, because it was in a web site project. Gotcha
CoffeeAddict
You've got it, but say "web site" - they're not projects.
John Saunders
well, sort of they are.
CoffeeAddict
Thank you. Because when I ran that Convert to Web Application over an .ashx id did not create a code-behind class or a .designer. Looks like no .designer is created but one would think that converting to a Web Application would at least create the code-behind file.
CoffeeAddict
so I just figured that there was no code-behind for an .ashx even in a WAP which is not true.
CoffeeAddict
@coffeeaddict: No, they're not projects. They differ from every other kind of project that Visual Studio creates. It was a horrible idea to implement web sites: we now have to ask which kind someone is using. Microsoft intended for us all to use web sites, so removed WAP in VS2005. At least then there would have been only one kind - no split in expertise and behavior. But with WAP added back in VS2005 SP1, we're left with a "mixed message", at best.
John Saunders
I know they differ but what I am saying is, they're projects in the sense that they are a physical aspect of your solution. I know they're not WAP.
CoffeeAddict
Yea, it was definitely horrible. This was the ONLY place I've seen have this. Every other team we've always had WAP in 2008 or at least wre using the WAP plugin in 2005 back in the day.
CoffeeAddict
I don't get why the hell MS keeps Web Site as an option in VS 2008. It's a lame excuse to say that "we offer a mixed bag because of choice" when clearly the Web Site option was and is a failure and a poor way to create a website and is NOT professional or does not comply with how the rest of projects work in C# or any language for that matter.
CoffeeAddict
For you John, I'll stop saying Web Site "Projects" :) yes I know.
CoffeeAddict
What they should do is redesign from scratch. Assume there will be WAP but also Web Sites. If Web Sites were only going to be for simple stuff, how would you design them? In that case, you might remove App_Code, etc., in favor of class libraries in external projects; you might be able to focus on the real benefits of the web site model, and not burden it with solving the "web site problem" as well as the "WAP problem".
John Saunders
I created those new .ashx, copied them to the server. For some reason, when I click on a hyperlink I still get that error above talking about the static file handler
CoffeeAddict
ah, here we go: http://blogs.iis.net/thomad/archive/2006/11/04/precondition-what.aspx
CoffeeAddict
Did you build the site afterwards? You should also try using the Publish command.
John Saunders