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
Related
I just started using Visual Studio and tried to duplicate a tutorial by Bob Tabor. Trying to display a HTML file using Browser connect.
Here's what I'm doing:
New project
Web ASP.NET Web Application
Empty
Add new item --> HTML page
Add 'test" to to title and body
Try to view in browser - get http://localhost:51962/HtmlPage1.html
with no response
Browser dashboard says no connections
Added to web.config:
<system.webServer>
<handlers>
<add name="Browser Link for HTML" path="*.html" verb="*"
type="System.Web.StaticFileHandler, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
resourceType="File" preCondition="integratedMode" />
</handlers>
</system.webServer>
But nothing seems to work. Could someone provide the proper steps?
I think it might be a server issue. localhost is a connection to a MySQL database called final project. BlueWater is the name of my computer. I'm able to connect to the Mysql database. I made sure I was using 4.5.2 and also that our web.config files match. Thanks again for your help. Here's a screenshot of Server Explorer:
I tried to replicate your issue and the results were as desired. Let me add screenshots so that you can follow through. I am using Visual Studio 2015 Community on Windows 10 with 4.5.2 .NET Framework.
Starting a new project
Choosing the type of project
Adding an HTML page
Adding test to HTML page
(Clicked on Google Chrome to run the project)
Running the project
My Web.config looks like this:
<?xml version="1.0" encoding="utf-8"?>
<!--
For more information on how to configure your ASP.NET application, please visit
http://go.microsoft.com/fwlink/?LinkId=169433
-->
<configuration>
<system.web>
<compilation debug="true" targetFramework="4.5.2"/>
<httpRuntime targetFramework="4.5.2"/>
</system.web>
<system.codedom>
<compilers>
<compiler language="c#;cs;csharp" extension=".cs"
type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
warningLevel="4" compilerOptions="/langversion:6 /nowarn:1659;1699;1701"/>
<compiler language="vb;vbs;visualbasic;vbscript" extension=".vb"
type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.VBCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
warningLevel="4" compilerOptions="/langversion:14 /nowarn:41008 /define:_MYTYPE=\"Web\" /optionInfer+"/>
</compilers>
</system.codedom>
</configuration>
Can you replicate these steps?
EDIT: DCR and I weren't able to get IISExpress to show web page. So, we decided to troubleshoot multiple areas. Here's what worked.
IIS Webserver was running, so we decided to leverage that (if you don't have IIS you can install it by going to Start > Control Panel > Programs > Turn Windows features on or off > choose Internet Information Services > OK).
We went to http://localhost and ensured that IIS welcome page was seen
We closed Visual Studio 2015 Community and reopened it as an administrator
Right click WebApplication1 project. Click Properties
Click Web on the left side menu
Start action was chosen. Ellipse (...) button was clicked and HtmlPage1.html page was selected
Under servers there's a dropdown. Local IIS was chosen. Project URL changed to http://localhost/WebApplication1
Click on create virtual directory. Successful message was noticed
Save the project changes
Press F5
Page appears as desired on http://localhost/WebApplication1/ URL
https://chat.stackoverflow.com/rooms/97122/discussion-between-dcr-and-zedfoxus has some more things that could help others troubleshoot similar problem.
Attempts were made to review answers from Unable to launch the IIS Express Web server source as well.
I found the issue to be an issue with my html source and where I was placing my Scripts.Render() and Styles.Render() methods. I placed each method outside of the html tags. Looking at the source from Firefox showed me that there were some html tags that were incorrectly closed. So I placed the #Scripts.Render() methods within the body tags and the #Styles.Render() methods in the head tags and the Browser Links started working again.
For the one who is still not getting in the visual studio like i wasn't before, try the following steps which worked for me.
install browser-sync if not installed globally through npm refer here
open a command prompt in the folder where your code is residing & run following command:
browser-sync start --files="**/*"
you will get dashboard link of browser-sync running locally. Go their and grab piece of code which needs to be embedded in the html file before body tag.
once you do that, and open your html, you will get the following message on the page & visual studio detects your browser as connected.
Don't know whether this is bug in VS or something.
I am using RDLC reporting in a ASP.Net Web Application. In development version my Reports works perfectly but when i deploy it on IIS on Server, I got the below error.
I have checked the version of Report viewer, its same...
Server Error in '/' Application.
The definition of this report is not valid or supported by this version of Reporting Services. The report definition may have been created with a later version of Reporting Services, or contain content that is not well-formed or not valid based on Reporting Services schemas. Details: Data at the root level is invalid. Line 1, position 1.
Add below dll to /bin folder
Microsoft.ReportViewer.Common.dll
Microsoft.ReportViewer.ProcessingObjectModel.dll
Microsoft.ReportViewer.WebForms.dll
Expand File Publish Options, and then check Allow this precompiled
site to be updateable.
Remove the following lines from Web.config:
<buildProviders>
<add extension=".rdlc" type="Microsoft.Reporting.RdlBuildProvider, Microsoft.ReportViewer.WebForms, Version=15.0.0.0, Culture=neutral, PublicKeyToken=89845DCD8080CC91" />
</buildProviders>
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 two different versions of a Silverlight 5 project using Ria services. Both work locally. The older version (A) works when deployed to ISS7. The new version (B) does not. There is user/password authentication that fails for version B with the error:
Load operation failed for query 'Login'. the remote server returned an error: NotFound.
Referencing various SO and MSDN posts over the past week, I have tried many troubleshooting techniques. Adding error logging as suggested here to the web.config results in the following being logged:
The service '/ClientBin/MyApp-Web-Services-AuthenticationService.svc' does not exist.
Researching that led to finding this forum post which suggests creating a dummy .svc file with the name/path it is looking for. The result:
The service '/ClientBin/DBCRM-Web-Services-AuthenticationService.svc' cannot be activated due to an exception during compilation. The exception message is: The ending bracket '>' for the 'ServiceHost' directive is missing in the '.svc' file..
The details of the above error aren't largely important as it was a blank .svc file I supplied. It merely served to confirm that fact that the project was indeed dependent on it
Here's the kicker... the working version DOES NOT contain this file either, yet it does not throw an exception.
Searching for any reference to needing the service surprisingly turned up a result in both solutions. Both MyApp.Web.g.csfiles are identical (ran a CSDiff) and both contain the line:
public AuthenticationContext() :
this(new WebDomainClient<IAuthenticationServiceContract>(new Uri("DBCRM-Web-Services-AuthenticationService.svc", UriKind.Relative)))
{
}
Both have the same package/deploy settings. I am deploying to a file system, then copying the files over to IIS on my host server.
Questions:
Where is a setting that makes this .svc file a requirement? It's clearly not needed in version A, but is in version B. Again, file MyApp.Web.g.csis the only reference to it, and it exists in both versions.
MyApp.Web.g.cs is a generated file. What service in Visual Studio 2010 creates this file? Also, can I modify it to not include the call to the .svc file in question?
I'm going to start merging the two solutions together to see at which point the .svc file becomes neccessary. Any ideas in the meantime would be greatly appreciated!
WCF Ria Services registers an HttpModule in order to manage the wcf ria services calls. When the request arrive to the server that module read the url and understand which service to instantiate and which method to call. So it's absolutely normal that you don't find any .svc file
Don't mess with the .g.cs your problem isn't here.
Take a look at your web.config file, you should find rows like this
<system.web>
<httpModules>
<add name="DomainServiceModule" type="System.ServiceModel.DomainServices.Hosting.DomainServiceHttpModule, System.ServiceModel.DomainServices.Hosting, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
</httpModules>
...
</system.web>
and this
<system.webServer>
<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>
...
</system.webServer>
Besides making sure that the "DomainServiceModule" entries are present in Web.Config as stated above, another thing is that RIA requires ASP .NET compatibility mode to be enabled. Here is a link to Microsoft's deployment guide for RIA:
http://msdn.microsoft.com/en-us/library/ff426912(v=vs.91).aspx
In the third paragraph of the "Configure the Web Server" section, it states that you need the following in your Web.Config file:
<system.serviceModel>
...
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true" />
...
</system.serviceModel>
When this is missing, you get the behavior described in your question.
Before you do any of this make sure the regular bin folder is actually deployed containing your actual code.
I was deploying with MSDEPLOY to a new server and it did not deploy bin folder. You're not going to get anywhere without that!
Sorry for the vague title, as I really can't explain this problem succinctly.
Basically I have Windows Server 2008 x64, IIS7, ASP.NET 2.05, and I have a site running in a Classic AppPool (and no I cannot run in Integrated).
When trying to load an *.aspx file for the first time (i.e. after installing site, restarting the server, etc) I get this error:
HTTP Error 500.0 - Internal Server Error
The page cannot be displayed because an internal server error has occurred.
Module: IsapiModule
Notification: ExecuteRequestHandler
Handler: PageHandlerFactory-ISAPI-2.0-64
Error Code: 0x800710dd
Logon Method: Anonymous
Logon User: Anonymous
The handler is the default IIS7 one:
<add name="PageHandlerFactory-ISAPI-2.0-64" path="*.aspx" verb="GET,HEAD,POST,DEBUG" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework64\v2.0.50727\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv2.0,bitness64" responseBufferLimit="0" />
I even tried adding in my own handler for aspx that looked like this:
<add name="aspx" path="*.aspx" verb="GET,HEAD,POST,DEBUG" modules="IsapiModule" scriptProcessor="C:\Windows\Microsoft.NET\Framework64\v2.0.50727\aspnet_isapi.dll" resourceType="Unspecified" preCondition="classicMode,runtimeVersionv2.0,bitness64" />
The only thing that did was change the Handler part of the error notification to say IsapiModule.
The odd thing is that this error only occurs the first time (or when the server has been idle for hours). As soon as I see this error, if I refresh the page it's all fine and dandy again.
I even tried deleting the web.config file and that did absolutely nothing.
I can't seem to find a single answer for this problem on the internet.
Edit: I enabled Failed Request Tracking and this is what it shows:
MODULE_SET_RESPONSE_ERROR_STATUS
Warning ModuleName="IsapiModule", Notification="EXECUTE_REQUEST_HANDLER", HttpStatus="500", HttpReason="Internal Server Error", HttpSubStatus="0", ErrorCode="The operation identifier is not valid.
(0x800710dd)", ConfigExceptionInfo=""
And right before the error it shows:
NOTIFY_MODULE_START ModuleName="IsapiModule", Notification="EXECUTE_REQUEST_HANDLER", fIsPostNotification="false", fIsCompletion="false"
Now when I compare this to a successful run the difference is that the error produces MODULE_SET_REPONSE_ERROR_STATUS whereas the successful run doesn't (and then goes on to produce the correct HTML output).
Edit: I took a simple app and tried to get that running and I received the same error. But when the apppool was in Integrated mode it ran fine! Unfortunately I cannot migrate our app to integrated for reasons I cannot specify but I narrowed it down to the app pool. Also I don't have to restart the server to repro the error, instead recycling the app pool will do.
Summary:
- As mentioned below there's nothing in the Event Logs to indicate failure. I combed through all logs in Event Viewer
Best thing to do is enable Failed Request Tracing in the IIS section of the web site. You can then enable some filters which give you much more detailed information.
You can do this through the IIS Manager. Click your web site, then in the IIS section of the Features View, double-click "Failed Request Tracing Rules".
It's most likely not already enabled, so from the rightmost column select "Edit Site Tracing". Check the "Enable" checkbox and make note of the directory.
You can then either add a rule in that screen or go to your application and open the "Failed Request Tracing Rules" IIS feature from there.
From the rightmost column again, click "Add..." Then go through the wizard and set up the logging.
Load your page that's throwing the error again. Go to the logging folder and double-click the XML file. There's an XSL in that directory. Don't nuke it, cuz once it's gone it won't get recreated. :s The transformed XML will show you more info than you can possibly hope for.
I just this evening used that to discover a custom error page that I configured was using ~/ instead of "/", causing IIS to die.
When ASP.NET application starts loading, you may have some code that may take too long to execute, probably too big application variables or resources initialization.
The best way is to setup some sort of ping monitor, lot of ISPs provide pinging monitors that can monitor your html url on regular interval, that may help keeping your application all time alive !!
Try looking into initialization procedures of your asp.net app, you may want to increase some timeout values !!
Sounds like something while starting up the app pool. But it should be logging the actual error in the event viewer. Or you could turn CustomErrors off to debug it. The thing is, you need to see the actual error to figure out what's going on.
Do you have an unhandled exception handler in your ASPX code (something like Global Application_Error)?
You should be able to catch the exception and log it if it's coming from the ASPX code (which is quite possible).
I've seen sporadic errors like this before, I just can't remember the underlying cause at the moment.
How to: Handle Application-Level Errors
Well I don't know what was causing this but a clean install of the VM I was using fixed it. Hurrah!
You must add this script on your web.config:
<system.webServer>
<handlers>
<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" />
<add name="ScriptHandlerFactoryAppServices" verb="*" path="*_AppService.axd" preCondition="integratedMode" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
</handlers>
I hope this help ! Cheer.