RIA Services error but not used - asp.net

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.

Related

The definition of this report is not valid or supported by this version of Reporting Services

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>

ClaimsAuthenticationManager is not invoked

I'm facing a weird issue with the WIF ClaimsAuthenticationManager. I have registered the custom implementatin of the ClaimsAuthenticationManager in the web.config file:
<identityConfiguration>
<claimsAuthenticationManager type="<namespace>.CustomClaimsTransformer,<assembly>" />
<claimsAuthorizationManager type="<namespace>.CustomAuthorisationManager,<assembly>" />
....
When i run the application in the IISExpress the authenticate method of the ClaimsAuthenticationManager gets invoked. However, it's not being invoked ever since i deployed the application on IIS 7.5.
Is there any configuration that needs to be done?
In the system.webserver part of your web.config do you have the ClaimsAuthorizationModule set,
eg
<add name="ClaimsAuthorizationModule" type="Microsoft.IdentityModel.Web.ClaimsAuthorizationModule, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
For .NET 4.5 you have to add this:
<add name="ClaimsAuthorizationModule" type="System.IdentityModel.Services.ClaimsAuthorizationModule, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="managedHandler" />
ClaimsAuthenticationManager is not invoked automatically. One needs a plumbing code for that unless they are using WS-Federation.
You can do it in an PostAuthenticateRequest event handler for the HttpApplication.
A good example is located in the http://github.com/thinktecture/Thinktecture.IdentityModel.45 project. Search for ClaimsAuthenticationHttpModule.cs which invokes it.

asp.net mvc deployment

Ive managed to get asp.net mvc up and running on an iis6 server, but I keep getting silly messages like 'System.Web.Mvc.HtmlHelper' does not contain a definition for 'RenderPartial'
I've got all the required dlls and even installed mvc from
http://www.microsoft.com/downloads/details.aspx?FamilyID=c9ba1fe1-3ba8-439a-9e21-def90a8615a9&displaylang=en
any clues about what Im missing?
Cheers
RenderPartial is an extension method and is defined in System.Web.Mvc.
So check out if you have in root Web.config lines adding System.Web.Extensions assembly:
<add assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
in <configuration> <system.web> <compilation> <assemblies> node.
Thanks all for your suggestions and also more importantly for your contributions which has made this site the great site. I dont know what I would do without this site and you guys. Thanks
this link fixed it, replacing the compilers section of the web config did it 'System.Web.Mvc.HtmlHelper' does not contain a definition for 'RenderPartial' - ASP.Net MVC
You are most probably missing this from your web.config:
<add namespace="System.Web.Mvc.Html"/>

Report Viewer problem after moving to new server

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

ASP.NET Website's BIN directory and references

Imagine the following solution:
Website ABC.com (not Web Application)
BLL (business logic layer in a seperate assembly)
DTO (dto objects in their own assembly)
DAL (data access layer in it's own assembly as well).
The BLL has a reference to the DAL.
The BLL has a reference to the DTO layer.
The Website project references the BLL.
When one compiles the website project, the following DLLs will appear in the BIN directory:
BLL.dll
DTO.dll
DAL.dll
When one goes to preview the site, an error occurs about not having the necessary assembly references... Now if one right clicks on the website project, Add Reference, and explicitly add the reference to the missing assemblies, it will work fine.
It seems to me like ASP.NET pulls the referenced assemblies of the referenced assembly being added/referenced in the website.
Why does one need to add explicit references to the references of the references... ? Sorry if I'm not wording this correctly or if it confusing.
I think the problem may have to do with using a web site project, as oppossed to a Web Application. I can't remember off the top of my head, but there's something funky about the way web site projects are compiled, as oppossed to web application projects.
Here is a good article on your question Compilation and Deployment.
It has something to do with "WebSites" being compile at runtime. Hopefully the above article will answer your question.
Just tested this scenario today for the project I'm on. You should be just fine just adding your assembly in Web.config as:
<compilation debug="true">
<assemblies>
<clear/>
<add assembly="mscorlib"/>
<add assembly="System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
<add assembly="System.Configuration, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
<add assembly="System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
<add assembly="System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
<add assembly="YourBLLLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
</assemblies>
</compilation>
Also your assemblies should stay in the famous ./bin folder of your web site's root.
GL!

Resources