I have a reportviewer control that works fine locally, but when deployed to the IIS 7 webserver, it just returns a blank page (or XML error in Firefox).
I thought it was permission related but I've given everyone permission as a Hail Mary and still I get a blank report with typically sparse MS error handling to help me track down the issue.
Has anyone else run into this?
Using IIS 7 and ReportViewer 9.0
If your using IIS 6 for development and IIS 7 for deployment. IIS7 it might be using integrated pipeline. In that case
<add verb="*" path="Reserved.ReportViewerWebControl.axd" type="Microsoft.Reporting.WebForms.HttpHandler, Microsoft.ReportViewer.WebForms, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
will not fire and nothing is rendered. Either you switch to classic pipeline or update your web.config. HttpHandler have a different section in web.config for intregrated pipeline.
http://msdn.microsoft.com/en-us/library/ms228090.aspx
I added the name attribute to the what Fahad posted and this worked great. Thanks! I can now use my MVC project with a ReportViewerControl on a WebForms page. Exactly what I needed.
<add verb="*" name="ReportViewerWebControl" path="Reserved.ReportViewerWebControl.axd" type="Microsoft.Reporting.WebForms.HttpHandler, Microsoft.ReportViewer.WebForms, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
Related
I created an ASP.NET MVC WebPages application. Works perfectly local. Works perfectly on the server when I install it as a website. However when it is installed as an IIS application (level below another website, using the same application pool) all it does is throwing this exception:
Could not load file or assembly
'System.ServiceModel.DomainServices.Hosting, Version=4.0.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its
dependencies. The system cannot find the file specified.
Apparently something related to WCF RIA services, which is not used. All I use is Linq to SQL. How is this possible?
Server: Windows Server 2008 R2 with IIS 7.5
Check the web.config of your application if it contains an entry like:
<httpModules>
<add name="DomainServiceModule"
type="System.ServiceModel.DomainServices.Hosting.DomainServiceHttpModule, System.ServiceModel.DomainServices.Hosting, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</httpModules>
It is located in the <system.web> section.
Theres is also another entry like:
<modules runAllManagedModulesForAllRequests="true">
<add name="DomainServiceModule"
preCondition="managedHandler"
type="System.ServiceModel.DomainServices.Hosting.DomainServiceHttpModule, System.ServiceModel.DomainServices.Hosting, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</modules>
in the <system.webserver> section.
Remove the entries, then you should not get the exception.
I know it too late, but may be my answer will be useful for some people.
I had similar problem, but no corresponded to IIS.
So, I had web app based on RIA services. This app used separate dll (DAL) which contained some classes attributed by RIA attributes (of course, it had reference to RIA dll). The dll (DAL) was referenced by another app which did not use RIA and raised same error as you mentioned (but only with System.ServiceModel.DomainServices.Server).
This error was raised only during WCF channel creation (ChannelFactory<>). So I suppose WCF should know about all referenced dlls during analyzing of attributes of contract's classes. But I did not found any explanation why WCF don't used only own attributes whithout analizing all of them.
I have an IIS6 running on Windows Server 2003 (x86) and have written a custom handler (Not a handler for 404 errors).
When I try to access the handler by opening in a browser http://localhost/Priority1.Sync/Transfer.p1s, I get error 404 (404 0 in log file). Other pages in the web application work, e.g. http://localhost/priority1.sync/syncservice.asmx
The handler works fine on my IIS7 dev machine.
web.config is setup as follows:
<httpHandlers>
<remove verb="*" path="*.asmx"/>
<add verb="*" path="*.asmx" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<add verb="*" path="*_AppService.axd" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<add verb="GET,HEAD" path="ScriptResource.axd" validate="false" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<add verb="*" path="*.p1s" type="MCS.Priority1.Sync.WebServices.TransferHandler, SyncService" />
</httpHandlers>
I have set an application extension for "*.p1s" (Default Web Site>Properties>Home Directory>Configuration>Mappings>Add).
Am I missing something else?
Thanks,
Andy
Do you have the "Verify that file exists" option in your custom handler IIS configuration checked or not?
IIS6 expects a physical file to exist by default. If there isn't one, it won't pass the request on to your handler at all. You need to disable this check, so it will send the request to your handler as expected.
IIS6 and IIS7 are fundamentally different beasts. IIS7's managed pipeline means every request hits your registered handlers, in IIS6 only things mapped to ASPNET_ISAPI.DLL (typically *.aspx and *.ashx and other default ASP.NET extensions) get processed.
You can make your IIS7 dev box behave this way by using the "classic" pipeline for your development app pool for this project.
Another trick to making it work how you expect is to map 404 errors to an ASP.NET page and then you can at least get into your handler.
In all honesty I would look towards upgrading production to IIS7 as it is so vastly more capable it isn't even funny.
If you are registering handlers for IIS 6 then do remember they should be placed in the
<httpHandlers> element of <system.web> section of the web.config not the <system.webServer> section that IIS7 uses.
I'm deploying a castle monorail web application to Windows Server 2003.
I've already set the httphandler mapping in web.config as follows :
<httpHandlers>
<add verb="*" path="*.castle" type="Castle.MonoRail.Framework.MonoRailHttpHandlerFactory, Castle.MonoRail.Framework" />
</httpHandlers>
<system.webServer>
<handlers>
<add name="castle page" path="*.castle" verb="*" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll" resourceType="Unspecified" preCondition="classicMode,runtimeVersionv2.0,bitness32" />
</handlers>
</system.webServer>
But whenever I tried to access http://localhost/app/Home/Index.castle the web server always returns HTTP 404 Not Found. It looks like the mapping is not handled by ASP.NET engine, like I've been missing a step or two in the configuration. Any solution?
Because you are using IIS 6.0 the <system.webServer> section is ignored and you need to associate the .castle extension with the ASP.NET ISAPI filter in the IIS control panel.
Phil Haack blogged about how to achieve this with ASP.NET MVC and the .mvc extension. For you this would be the .castle extension:
I have a web service file in my project having a web method which is used for AutoCompleteExtender and which works fine when I debug it from VS.
But when I publish and host it on IIS, it's not working properly.
However, I tested the webservice method directly by typing the URL and it gave the desired output.
Is their a special setting needs to be done in IIS to make it working or any property of AutoCompleteExtender need to be set?
I had this issue as I moved a site from cassini to IIS7.5. After a lot of digging had to add the follwoing to the web.config in the system.webServer section. Hope it helps.
<modules runAllManagedModulesForAllRequests="true">
<remove name="ScriptModule" />
<add name="ScriptModule" preCondition="managedHandler" type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
</modules>
<handlers>
<remove name="ScriptHandlerFactory"/>
<add name="ScriptHandlerFactory" verb="*" path="*.asmx" preCondition="integratedMode" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
</handlers>
After a upgrade from ASP.NET 3.5 to 4.0 I have the same problem and can't get the extender to work. From firefox and firebug I recive a 500 Internal Server Error with the message
System.InvalidOperationException: Request format is invalid: application/json; charset=utf-8.
at System.Web.Services.Protocols.HttpServerProtocol.ReadParameters()
at System.Web.Services.Protocols.WebServiceHandler.CoreProcessRequest()
I have tested with the web.config settings suggested by http://msdn.microsoft.com/en-us/library/bb763183.aspx but recive configuration errors.
Try changing the order of the handlers (remove then add). In this example I have removed all but the AJAX/script handler.
<system.webServer>
<modules runAllManagedModulesForAllRequests="true" />
<handlers>
<remove name="WebServiceHandlerFactory-Integrated"/>
<remove name="WebServiceHandlerFactory-ISAPI-2.0"/>
<remove name="WebServiceHandlerFactory-ISAPI-2.0-64"/>
<remove name="WebServiceHandlerFactory-ISAPI-4.0_32bit"/>
<remove name="WebServiceHandlerFactory-ISAPI-4.0_64bit"/>
<!--<add name="WebServiceHandlerFactory-Integrated-4.0" ...</handlers>
Its not the problem of IIS or ath. Its a bug actually (I think). In your function in webservice to return the string array please check the parameter names or arguments to the function.
The name of the string parameter must be prefixText and that of int field should be count.
And there must be these two parameters for your functions in the webservice.
like this
[WebMethod]
public string[] getCountry(string prefixText, int count)
{
......
....
return ...
}
I was facing the same problem. AutoCompleteExtender was not working after hosting in IIS 7 Windows Server 2008 R2.
By changing the "Managed Pipeline Mode" of Application Pool from "integrated" to "Classic" worked for me.
This setting can be taken by selecting the application pool -> select Basic setting.
Thank you.
Try...this
go to start>run>inetmgr>
In the connections sidepane..select application pools
select the application pool that u hav assigned when deployed that project into iis(to check that go to sites>in connections pane...and right click on website that u have deployed and select manage website >advanced settings then at the top u wil able to see application pool)
then comeback and select that particular application pool in application pools in connections pane
right click on that particular application pool and select advanced settings..find out process model in that and select identity and browse through it and goto built in account and select local system.......then click ok...and get out of it...
I think it will work..it worked for me.....
I have just moved a site from a Windows 2003, IIS6 SQL 2005 server to a new one with Windows 2008, IIS7 and SQL 2008.
I am having problems with the Report Viewer.
I have installed the Report Viewer Re-distributable (I've tried 2005, 2005sp, 2008 and 2008sp)
I've Mapped a handler in IIS for
Reserved.ReportViewerWebControl.axd
to type
Microsoft.Reporting.WebForms.HttpHandler,
Microsoft.ReportViewer.WebForms,
Version=8.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a
However whenever I run a report on the website I get the following error message:
Could not load type 'Microsoft.Reporting.Microsoft.Reporting.WebForms.HttpHandler' from assembly 'Microsoft.ReportViewer.WebForms, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.TypeLoadException: Could not load type 'Microsoft.Reporting.Microsoft.Reporting.WebForms.HttpHandler' from assembly 'Microsoft.ReportViewer.WebForms, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
I am stumped. Any ideas?
I think you need to map to version 9.0.0.0 and not 8.0.0.0
you need to sure this setting should be in your live server web.config
<compilation debug="true">
<assemblies>
</assemblies>
<buildProviders>
<add extension=".rdlc" type="Microsoft.Reporting.RdlBuildProvider, Microsoft.ReportViewer.Common, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
</buildProviders>
<httpHandlers>
<add path="Reserved.ReportViewerWebControl.axd" verb="*" type="Microsoft.Reporting.WebForms.HttpHandler, Microsoft.ReportViewer.WebForms, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" validate="false"/>
</httpHandlers>
If you are running under IIS 7 it is worth checking the handler also has permission to execute.
After setting mine up I could see the handler was just throwing a 500 exception, on closer inspection it seems just adding the handler to the list is not enough. You must also edit its permission becuase by default it is not allowed to execute. Ticking the box to let it execute, and solved my problem immediately.
Also might be worthwhile trying this if any of the other suggestions here don't work -
http://social.msdn.microsoft.com/Forums/en-US/sqlreportingservices/thread/0152bb52-988d-43f5-9c3d-8d33512f46de/
"There were a number of problems with the Transition to IIS 7.
Considerable debugging was required.
FIRST ISSUE RESOLVED: Directory permissions for the IIS 7 application
pool identity (the default was Network Service) needed to be added so
that the IIS application pool could have access to the physical path
of the Website directory.
SECOND ISSUSE RESOLVED: A line needed to be added to the ASP.Net
application web.config file. Child of After
Added:
THIRD ISSUE RESOLVED The Default App pool upon install has .Net
Framework 2.0 as default. This was fine. The Default App pool setting
for Managed Pipeline Mode needed to be changed from 'Integrated'
(default) to 'Classic', this was the quick fix to keep my app running
as it had on IIS 6."
Changing managed pipeline mode to "classic" fixed it for me.
Looks like this issue has been resolved for a while now, but for anyone searching:
Note the assembly being referenced in the error:
Microsoft.Reporting.Microsoft.Reporting.WebForms.HttpHandler
It should just be Microsoft.Reporting.WebForms.HttpHandler - how we both ended up with that in our web.config is suspicious, but may have something to do with manually creating the handler in IIS and letting IIS write the handler key to the app's web.config (now of course I can't reproduce it).
For anyone moving to IIS7, bear in mind that the handler mapping now lives in <system.webServer> <handlers> and not <system.web> <httpHandlers> as it was in earlier versions. IIS7 will ignore the old httpHandlers section but you may be checking the settings there out of habit and getting frustrated that your settings aren't taking effect.
Just include CommanClassLibrary.dll in your project's Bin Folder and make sure on aspx page and config file your ReportViewer Web Control version should be same