I have a WCF service than in my development and production environments works without any trouble but in my test environment it will occasionally throw a CommunicationObjectFaultedException. This has been very difficult to track down but it seems to happen only after going a long time with out calling it.
The client is a web applictaion running on two load balanced servers, the WCF service is hosted in IIS and running on two load balanced servers.
There is no difference in the WCF configuration between the three environments so I believe there must be something different in the way the servers are set up. What are some things I can ask my server admins to check? (I don't have proper access to these servers to check stuff myself).
You may want to enable tracing on the server in order to get more detailed error information. Can you ask your admins to enable that?
<configuration>
<system.diagnostics>
<sources>
<source name="System.ServiceModel"
switchValue="Information, ActivityTracing"
propagateActivity="true">
<listeners>
<add name="traceListener"
type="System.Diagnostics.XmlWriterTraceListener"
initializeData= "c:\log\Traces.svclog" />
</listeners>
</source>
</sources>
</system.diagnostics>
</configuration>
MSDN link here. I'll update my answer for any additional information you can post.
Good luck!
Related
I'm using a third party CMS which is using a custom SessionStateProvider which is inheriting from System.Web.SessionState.SessionStateStoreProviderBase. System.Web.SessionState.SessionStateModule is used as SessionStateModule.
I need to allow concurrent request per session with a writable session. This can be done using the aspnet:AllowConcurrentRequestsPerSession setting when using the AsyncSessionStateModule from here. This would meet my requirement but this requires the provider to inherit from Microsoft.AspNet.SessionState.SessionStateStoreProviderAsyncBase and the provider from the third party CMS does not.
I understand this can be achieved by implementing ISessionStateModule but this seems high risk and easy to get wrong. Is there already a SessionStateModule somewhere which meet my requirements (it seems like I cannot be the first to run into this issue)?
Allows concurrent requests per session
Writable session (i.e. no SessionStateBehavior.ReadOnly to achieve concurrent request)
Supports a provider inheriting from System.Web.SessionState.SessionStateStoreProviderBase
Or am I missing something here and can this be achieved in an easier way?
I have used the Microsoft.AspNet.SessionState.SessionStateModule in a couple of different scenarios.
Microsoft.AspNet.SessionState.InProcSessionStateStoreAsync - This provider is included in the NuGet package and is a lot simpler to use as it does not require an external dependency. However, you need to ensure the user is hitting the same web-server. If you have a multiple server deployment, this requires "sticky sessions" on the load balancer.
Microsoft.Web.Redis.RedisSessionStateProvider - This provider requires 2 additional NuGet packages (Microsoft.Web.RedisSessionStateProvider and StackExchange.Redis) and an instance of Redis. While Redis is indeed very powerful, it may take some tweaking to get running smoothly. Do an internet search for "StackExchange Redis Timeout" and you will see a common problem that people face with this driver. I would only recommend this configuration in a multiple server configuration where you do not have "sticky sessions" on your load balancers.
Example web.config settings:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<appSettings>
<add key="aspnet:AllowConcurrentRequestsPerSession" value="true" />
</appSettings>
<system.webServer>
<modules>
<remove name="Session" />
<add name="Session" type="Microsoft.AspNet.SessionState.SessionStateModuleAsync" preCondition="integratedMode" />
</modules>
</system.webServer>
<!-- Option 1: InProcSessionStateStoreAsync -->
<sessionState mode="Custom" customProvider="InProcSessionStateStoreAsync" cookieless="UseCookies">
<providers>
<add name="InProcSessionStateStoreAsync" type="Microsoft.AspNet.SessionState.InProcSessionStateStoreAsync" />
</providers>
</sessionState>
<!-- Option 2: RedisSessionStateProvider -->
<sessionState mode="Custom" customProvider="RedisSessionStateProvider" cookieless="UseCookies">
<providers>
<add name="RedisSessionStateProvider" type="Microsoft.Web.Redis.RedisSessionStateProvider" connectionString="..." />
</providers>
</sessionState>
</configuration>
As a side note, it looks like the AspNetSessionState project may already come with CosmosDB and Sql providers. YMMV - But you could try one of those if you wanted an external state server other than Redis. I ended up going with Redis mainly because it was used elsewhere in my app.
I've got informed that following the general Microsoft recommendation our web servers will be reconfigured; among other things the allowSubDirConfig setting should be set to false. Thus, our ASP.NET applications must use a single Web.config at their root level (which is quite okay for our applications by the way).
However, ASP.NET MVC uses a "non root level" configuration file (by default!) for the Views directory, which contains a simple (but important?) web server related section:
<system.webServer>
<handlers>
<remove name="BlockViewHandler" />
<add name="BlockViewHandler"
path="*"
verb="*"
preCondition="integratedMode"
type="System.Web.HttpNotFoundHandler" />
</handlers>
</system.webServer>
Regarding to a post by Phil Haack this is security related, hence important.
Since the other .NET Framework related sections still work, because the ASP.NET runtime does not obey the allowSubDirConfig setting, an ASP.NET MVC application still works too. So the ignored web server configuration doesn't really attract attention during general usage, although i've a bad feeling about it.
Isn't that a lousy idea? If web servers are configured that way (by recommendation), how vulnerable are those ASP.NET MVC applications out there?
The HttpNotFoundHandler has a path attribute which means you can add it to the root config file and point path to the Views folders and you would not be altering the security level in any way:
<system.webServer>
<handlers>
<remove name="BlockViewHandler"/>
<add name="BlockViewHandler" path="Views/*" verb="*" preCondition="integratedMode" type="System.Web.HttpNotFoundHandler" />
</handlers>
</system.webServer>
This will work with a basic web.config file, but beware if you are adding/removing handlers as part of your application. Handlers that come before the BlockViewHandler could still deliver content from the Views subfolder (but then I believe this is also the case with the standard web.config in the Views directory unless you remove the handler there specifically).
Generally speaking IIS will not serve .cshtml files from the Views folder (unless specifically allowed) even if the system.webServer section is missing/ignored in the Views subdirectory.
But it would serve other files (e.g. html,css,js) which would be blocked by the BlockViewHandler handler which could be regarded as reduced security.
I have a website which contains a small Silverlight plugin that calls a very simple WCF service to save values in Session.
It works fine on my PC and works ok only on my computer on the server (hosting provider). I noticed that for all machines that have Silverlight Developer Edition installed my Silverlight app works fine, however for all machines that have Silverlight Generic Edition installed my application fails when calling WCF service with the following message:
Additional information: [MessageXmlProtocolError]
Arguments:
Debugging resource strings are unavailable. Often the key and arguments provide sufficient information to diagnose the...
I have crossdomain.xml and clientaccesspolicy.xml files in place which should be correct and I am using basicHttpBinding with no security. Also, there is no issues with developer editions. Can anyone help? (Silverlight version = 4)
The issue is that the response received is not what the WCF service was expecting. From the MSDN documentation, MessageXmlProtocolError is:
"A problem occurred with the XML that was received from the network. See the inner exception for more details."
This means that you need to see what the inner exception is in order to determine the actual cause.
If the WCF service is hosted in IIS on a specific URL, it could be that the senders are not authorized to access that URL in the web site. We've had this issue more than once.
Ways to help troubleshoot the problem include:
1) Install the SDK on a computer having the problems to see if you can get the full exception.
2) Use WCF tracing by adding a block like the following to your web.config (assuming the WCF service is hosted in IIS):
<system.diagnostics>
<sources>
<source name="System.ServiceModel"
switchValue="Information, ActivityTracing"
propagateActivity="true">
<listeners>
<add name="traceListener"
type="System.Diagnostics.XmlWriterTraceListener"
initializeData="c:\log\WebTrace.svclog" />
</listeners>
</source>
</sources>
</system.diagnostics>
3) Use a tool like fiddler to trace the request and response from the WCF client to see if you can track down the issue.
I just added some code that changes wcf service url to make sure it runs on the correct server. This fixed the problem
I'm submitting a request to a web service, but I'm receiving some errors. They've asked to see an example of the xml request and response. I used Visual Studio to consume the web service, so I'm just calling a method in my code - I don't actually see any xml.
Is there a way to grab the XML request and response as XML or at least a text string?
Thanks
The easiest way to do this is using a 3rd party tool, like Fiddler . You'll be glad you started using this tool anyway.
You could use Fiddler.
I had to debug what was going across the line recently and tools like wireshark and fiddler are great tools for debugging the request and response unless you are using HTTPS or you are debugging on your local machine and executing the client and the web service locally.
I found a method that allows you to see the details of both the request and response without having to modify a single line of your code.
.NET has a feature built in called tracing. By enabling tracing for the System.NET namespace you can capture everything.
Here are the steps to enable.
Add the following code to your app.config in your client applications.
<system.diagnostics>
<trace autoflush="true" />
<sources>
<source name="System.Net">
<listeners>
<add name="System.Net"/>
</listeners>
</source>
</sources>
<sharedListeners>
<add name="System.Net"
type="System.Diagnostics.TextWriterTraceListener"
initializeData="System.Net.trace.log" />
</sharedListeners>
<switches>
<add name="System.Net" value="Verbose" />
</switches>
</system.diagnostics>
Now when you execute your client application you can go into the folder that your executable was run from and find the file System.Net.trace.log
You will then find in the log file your request and the servers response. The great thing about this solution is you do not have to install or run anything extra. However the solution is probably only a solution for developing or diagnosing something in test or stage environment rather than production. However I am assuming because you mention creating the solution in Visual Studio and it not working that you are clearly in the development stage.
I was going to use ELMAH for our ultimate automatic error logging but recently realized that ASP.NET Health Monitoring does a same work (perhaps). Now I want to know (please) if they are alternatives of each other just like log4net and entlib?
ELMAH is for error monitoring, pure and simple. Easy to see the errors via a readout, RSS feeds, etc. Health monitoring is more of a full instrumentation solution.
Want the easy answer?
Look at how to setup Health Monitoring
Look at how to setup ELMAH
ELMAH is a very quick pluggable solution for error monitoring it has a very specific task (that is does beautifully). Health Monitoring is more of the shotgun see/monitor everything approach and involves much more setup work. Oh yeah, need to make a change? It's open source, grab it, change it as you like.
I have not used Health Monitoring in ASP.NET but I have used ELMAH and it is simply amazing. It literally takes only 2 minutes to setup and then you can see all the errors. There are also so many options to display the errors. Try out ELMAH you are going to love it.
ASP.NET Health Monitoring will automatically generate messages for events like app domain startup and shutdown and heartbeats and many other information about the web application. Logging frameworks don't support such features, but you can route the Health Monitoring system events to your logging framework of choice. Some frameworks even support this out of the box, such as CuttingEdge.Logging. Here is an configuration example of a CuttingEdge.Logging where the health events are forwarded to a logging provider:
<?xml version="1.0"?>
<configuration>
<configSections>
<section name="logging"
type="CuttingEdge.Logging.LoggingSection, CuttingEdge.Logging" />
</configSections>
<system.web>
<healthMonitoring heartbeatInterval="0" enabled="true">
<providers>
<!-- We're configuring the web event provider here. -->
<add name="LoggingWebEventProvider"
type="CuttingEdge.Logging.Web.LoggingWebEventProvider, CuttingEdge.Logging"
loggingProvider="DebugLogger" />
</providers>
<rules>
<add name="Custom Event Provider"
eventName="All Events"
provider="LoggingWebEventProvider"
profile="Default" />
</rules>
</healthMonitoring>
</system.web>
<logging defaultProvider="DebugLogger">
<providers>
<!-- Configure your favorite provider here. -->
<add name="DebugLogger"
type="CuttingEdge.Logging.DebugLoggingProvider, CuttingEdge.Logging"
description="Debug logging provider"
threshold="Debug" />
</providers>
</logging>
</configuration>