Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

I've developed a Visual Web Part for Sharepoint 2010. I've used VS2010 to do that and tested the Webpart in a testing server using VS to do the deployment.

But to deploy it on the production server I had to use Powershell commands because that server doesn't have VS installed. I followed this guide to deploy it. The only problem I had was that I couldn't enable the feature via Powershell, I had to do it through the web UI (Site collection features).

Now, this Visual Web Part has a HTTP Handler that retrieves some data, this is used to load the data in the webpart asyncronously. It works perfect on the testing server, but when I access the URL of the handler on the production server I get the following:

XML Parsing Error: no element found

Location: url-to-my-handler/myHandler.ashx

Line Number 1, Column 1:

^

I don't know how to get more information about the error. There's nothing in the source of the page, neither in the Event Log. I even added a try/catch block in the ProcessRequest method of the handler and write any exception cached to the Event Log, but doesn't seem to be triggered.

Any ideas?

EDIT:

Maybe it's something related to the .ashx itself, since the catch I wrote on the .ashx.cs is not being hit.

The 'myHandler.ashx' is like this:

<%@ Assembly Name="$Sharepoint.Project.AssemblyFullName$" %>
<%@ WebHandler Language="C#" Class="MyNamespace.MyHandler" %>

But I'm not sure if the Assembly name is being replaced correctly or even replaced.

share|improve this question
    
is there anything in the 14/LOGS folder? Also, is the farm where this is happening load balanced? –  Dave Wise Nov 2 '11 at 4:38
    
One Question is did you register the httphandler in the web.config file? –  Thomson Nov 2 '11 at 4:49
    
@Dave Wise: I'll check the logs folder tomorrow. I have no idea about the farm, I just RDC to a VPS. –  emzero Nov 2 '11 at 7:45
    
@Thomson: No, but I didn't registered on the testing server either. Any information on how to register it? Maybe it'll fix it. –  emzero Nov 2 '11 at 7:47
    
Check this article mysharepointwork.blogspot.com/2010/04/… –  Thomson Nov 2 '11 at 8:04

4 Answers 4

up vote 6 down vote accepted
+100

I suggest you should deal with the problem after going through httphandler development and its deployment in IIS 7 and ASP.NET 3.5. Here is a good link : http://msdn.microsoft.com/en-us/library/bb398986(v=VS.90).aspx (See various walk-through and consider asynchronous handlers as you deal in asynchronous way)

If you think you know it all, Please ensure :

  1. Your web application is using .NET 3.5 (in web.config or IIS) on production server.

  2. The httphandler assembly is in GAC (followed by IISRESET) and Your ashx file is kept at same path you provided in web.config. The best place to keep ashx file is in a seperate folder at _layouts directory and refer it in web.config as :

     <system.webServer><handlers>
    <!-- other handlers here -->
    <add name="MyHandler" path="/_layouts/customhandlers/Myhandler.ashx" verb="*" type="MyNamespace.MyHandler, MyNamespace, Version=[assembly-version], Culture=neutral, PublicKeyToken=[insert-assembly-token-here]" />
    

The ashx file should contain :

<%@ Assembly Name="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Assembly Name="[Insert-assembly-Name], Version=1.0.0.0, Culture=neutral, PublicKeyToken=[insert-assembly-token-here]" %>
<%@ WebHandler Language="C#" Class="MyNamespace.MyHandler" %>

3.Use Application_Error event in global.asax to find or log the error or exception.Try to fix if any. Chances are high that the httphandler is not able to generate some markup on your production server due to some exception.

In a SharePoint web application, you can find global.asax in virtual directory for your web application(C:\Inetpub\wwwroot\wss\VirtualDirectories\port-no where 'port-no' is port of your web application).

If it is not there, you can create a new one. Copy paste below in a notepad and save it as global.asax at root of web application directory:

<%@ Assembly Name="Microsoft.SharePoint"%>
<%@ Application Language="C#" Inherits="Microsoft.SharePoint.ApplicationRuntime.SPHttpApplication" %>

void Application_Error(object sender, EventArgs e)
{

 // code for logging when an unhandled error occurs.

}

4.You should also check ULS logs and event logs for any exception or error.

share|improve this answer
    
Yes, I'm trying to do the Application_Error in global.asax but this is a Sharepoint 2010 application and I can't see the global.asax file anywhere. Is there a way to create it and add this event to catch the error? –  emzero Nov 9 '11 at 18:43
1  
Yea, and it's a part of sharepoint and modifying it may lead to unexpected results. –  Yuri Leontyev Nov 10 '11 at 10:27
1  
This is not a solution but a way to troubleshoot a problem. After finding the relevant error and fixing it we can switch back to normal. A SharePoint is a .net application anyway and I think a developer can use concepts from ASP.NET to debug atleast! –  Amit Kumawat Nov 10 '11 at 13:23
2  
Don't be so religious, he's not saying to modify the global.asax permanently. I've just found what the error was using this method, fixed the problem and the reverted the global.asax to its default version. So what's the problem with that? This was the only answer that gave me a way to find the exception I was getting. Thanks Amit. –  emzero Nov 10 '11 at 13:25
1  
@David : You can check out about global.asax from msdn as well : msdn.microsoft.com/en-us/library/bb892189(v=office.12).aspx –  Amit Kumawat Nov 10 '11 at 13:26
  1. I think that <%@ Assembly Name="$Sharepoint.Project.AssemblyFullName$" %>

    • when you deploy on your prod server, that code is not replaced by Visual Studio, thus you need to specify full name of the assembly you have developed, you can get it from .webpart file.

    That happens due to http://msdn.microsoft.com/en-us/library/ee231545.aspx, VS 2010 changes params only in XML, ASCX, ASPX, Webpart, DWP and misses ashx.

My Hanlder looks like:

<%@ Assembly Name="WebParts.MyWP, Version=1.0.0.0, Culture=neutral, PublicKeyToken=f5c2f0f5e9dedcf6" %>
<%@ WebHandler Language="C#" CodeBehind="DownloadFile.ashx.cs" Class=" WebParts.MyWP.Layouts.DownloadFile" %>

And is place to _layouts folder.

  1. You may need to recycle app pool or make IIS reset
  2. Make sure you have a valid context.Response.ContentType - not xml, but "text/plain" or "application/json"
  3. Make sure that there is no error in your code - you can deploy a dumb version that will return something like 'Hello world'
share|improve this answer
    
1. Yes, I have already replaced the Assembly directive with the correct name, version and token (from SN command), still the same. 2. The content type is set to text/html because it actually returns html code. 3. There's no error in the code, because I put a big try/catch to get the exception and it's not raising, the error is from the ashx file not the .cs. –  emzero Nov 9 '11 at 18:36
    
did you tried iis reset or recycling app pool? also you can try to deploy the same code to a different folder in _layouts –  Yuri Leontyev Nov 9 '11 at 19:11
    
Yes, I did iisreset. I don't think how deploying the handler in another folder in _layouts would help, but I'll try it anyway. –  emzero Nov 9 '11 at 19:13
    
also what browser are you using? and could you look through the firebug or ie dev tools what response you are receiving from the server? –  Yuri Leontyev Nov 9 '11 at 19:19
    
also you may try writing debug messages using context.Response.Write("started") which should be shown in the browser –  Yuri Leontyev Nov 9 '11 at 19:29

If you need to create an HttpHandler in SharePoint 2010, you need create a source file with the .ashx extension that contains your code and drop it into your \12\TEMPLATE\LAYOUTS\ folder.

The bad deal is that this solution is usefull only if you need to create a preatty simple HttpHandler programming using inline code with no possibilty to debug or test your Http Handler. My solution to this problem is to create a SharePoint 2010 Solution Package that once installed will deploy your assembly into GAC and install the ASHX HttpHandler under the SharePoint's virtual directory called LAYOUTS .

The best way to accomplish this task is: Create an empty solution Separate you code from the markup: use code behind files and not inline codes Build your new HttpHandler Deploy and test it! To show you how to perform this task correctly, I'll describe each step and provide you the source code of my sample.

Here is the SampleHandler.ashx.cs

using System;
using System.Collections.Generic;
using System.Web;
using Microsoft.SharePoint;

namespace SharePointHttpHandlers.CustomHttpHandlers
{

    public class SampleHandler : IHttpHandler
    {

        public void ProcessRequest(HttpContext context)
        {


            context.Response.ContentType = "text/plain";
            context.Response.Write(String.Concat("Hey, your site's url is ",
                SPContext.Current.Site.Url));
        }

        public bool IsReusable
        {
            get
            {
                return false;
            }
        }
    }
}

Here is the SampleHandler.ashx file. Make sure that your ashx is placed in 12\TEMPLATE\LAYOUTS\CustomHttpHandlers

<%@ Assembly Name="SharePointHttpHandlers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=23d6ec32decbea39" %>
<%@ WebHandler Language="C#" CodeBehind="SampleHandler.ashx.cs" Class="SharePointHttpHandlers.CustomHttpHandlers.SampleHandler" %>

Make sure to separate your code from the markup: use code behind files and not inline codes Now you need to instruct your SharePoint Solution to drop the files under the /LAYOUTS/ folder: follow this folder herarchy and add a new HttpHandler with the .ASHX extension:

For getting the correct assembly name and Public key token: Locate your compiled assembly, drop it into Reflector and get your assembly's full name including the Public Key Token

This sample just shows that you are now able to call the SharePoint' s SPContext from your HttpHandler. The handler response with a simple text string that informs you that it works.

The ideal way is to build a WSP package and perform the deployment. Make sure to perform IISReset afterwards.

You can also test using a work around where you copy the dll to GAC and copy the ashx file directly into _Layouts folder (But please don't do that on production since there might be many WFEs)

share|improve this answer
    
Interesting, but problem is I don't have that class. My handler does not inherit from SPFeatureReceiver, but from IHttpHandler. So, where am I supposed the code change suggested on that article? –  emzero Nov 3 '11 at 18:48
    
I did register the httpHandler in the web.config but it didn't change anything. Same error... –  emzero Nov 3 '11 at 19:29
    
You should have an SPFeatureReceiver. You need one to create the SPWebConfigModification objects that will automatically update your web.config file. The reason you want this to be automatic is that it means the same changes are replicated to all servers in the farm, and and new servers that are added later. The Feature receiver is not the same as the handler itself - you're just using it for registration. –  Andy Burns Nov 9 '11 at 9:50
    
It's not required to register handle in web.config, you can access it by absolute url, and it'll process the request, modification web config is required to associate with http actions and specific extension. If it's put to _layouts folder, it'll works the same way as aspx page, but without triggering page life cycle process, just processing the request. –  Yuri Leontyev Nov 9 '11 at 10:34
    
The problem in the scenario is about httphandler and not httpmodule.How your code helps? –  Amit Kumawat Nov 10 '11 at 4:03

 <TokenReplacementFileExtensions>ashx;</TokenReplacementFileExtensions>

share|improve this answer
    
Could you add some reasoning to your answer, that makes us understand what you nean by your code line? Thank You! –  Benny Skogberg Dec 9 '13 at 16:21

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.