andyfrench.info

I always seem to be setting up development machines and need to install the same set of tools over and over. To help me keep track of them I’m starting a list:

The problem

I was recently writing automated integration tests against a WCF service using NUnit when out of the blue all the tests failed and kept failing. An examination of the exceptions thrown showed that in each case a CommunicationException was being thrown because of a timeout.

What was most perplexing was that the apparent timeouts were being reported immediately but the client configuration was set to defaults:

<system.serviceModel>
        <bindings>
            <wsHttpBinding>
                <binding name="WSHttpBinding_EnquirySubmissionService" closeTimeout="00:01:00"
                    openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
                    bypassProxyOnLocal="false" transactionFlow="false" hostNameComparisonMode="StrongWildcard"
                    maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
                    messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true"
                    allowCookies="false">
                    <!-- snip -->
                </binding>
            </wsHttpBinding>
        </bindings>
        <!-- snip -->
  </system.serviceModel>
</configuration>

The service was using WsHttpBinding and was hosted by IIS over HTTPS. The service was also secured using TransportWithMessageCredential and UserName credentials on the message (i.e. username and password).

The solution

Firstly I enabled tracing on the service by modifying the Web.config file to include the following:

<system.diagnostics> 
    <sources> 
        <source name="System.ServiceModel" switchValue="Information,ActivityTracing" propagateActivity="true"> 
            <listeners> 
                <add name="xml" /> 
            </listeners> 
        </source> 
        <source name="System.ServiceModel.MessageLogging"> 
            <listeners> 
                <add name="xml" /> 
            </listeners> 
        </source> 
    </sources> 
    <sharedListeners> 
        <add initializeData="C:\logs\TracingAndLogging-client.svclog" type="System.Diagnostics.XmlWriterTraceListener" name="xml" /> 
    </sharedListeners> 
    <trace autoflush="true" />
</system.diagnostics>

I then queried the service again to promote a timeout communication exception. I found the trace log contained:

System.ServiceModel.Security.MessageSecurityException: Message security verification failed. ---> System.ComponentModel.Win32Exception: The event log file is full
at System.Diagnostics.EventLog.InternalWriteEvent(UInt32 eventID, UInt16 category, EventLogEntryType type, String[] strings, Byte[] rawData, String currentMachineName) 
at System.Diagnostics.EventLog.WriteEvent(EventInstance instance, Byte[] data, Object[] values) 
at System.Diagnostics.EventLog.WriteEvent(String source, EventInstance instance, Object[] values) 
at System.ServiceModel.Security.SecurityAuditHelper.WriteEventToApplicationLog(EventInstance instance, Object[] parameters) 
at System.ServiceModel.Security.SecurityAuditHelper.WriteMessageAuthenticationSuccessEvent(AuditLogLocation auditLogLocation, Boolean suppressAuditFailure, Message message, Uri serviceUri, String action, String clientIdentity) 
at System.ServiceModel.Security.SecurityProtocol.OnIncomingMessageVerified(Message verifiedMessage) 
at System.ServiceModel.Security.TransportSecurityProtocol.VerifyIncomingMessageCore(Message& message, TimeSpan timeout) 
at System.ServiceModel.Security.TransportSecurityProtocol.VerifyIncomingMessage(Message& message, TimeSpan timeout)

So, the problem actually was that the event log was full! Having emptied the event log everything started working again.

Here’s a quicky that’s bugged me a few times and I can never remember the solution.

Sometimes when you download a .chm file, open it and try to navigate around you get an “address is not valid” error such as the following:

The solution is quick and simple:

1. Right-click the .chm file and then click Properties.
2. Click the Unblock button.
3. The .chm file may now be opened and will work normally.

I have recently been working on an established project which makes use of the Global Assembly Cache (GAC) for most of the assemblies in the application. I have found the experience quite frustrating because keeping the assemblies in sync with the code has been tedious. But I realised I wasn’t really sure if using the GAC was a good idea or not so I’ve done a bit of research.

“Each computer where the common language runtime is installed has a machine-wide code cache called the global assembly cache. The global assembly cache stores assemblies specifically designated to be shared by several applications on the computer.

You should share assemblies by installing them into the global assembly cache only when you need to. As a general guideline, keep assembly dependencies private, and locate assemblies in the application directory unless sharing an assembly is explicitly required. In addition, it is not necessary to install assemblies into the global assembly cache to make them accessible to COM interop or unmanaged code.” *

OK, so there’s the first point. Microsoft suggest, “You should share assemblies by installing them into the global assembly cache only when you need to”.

The GAC is useful for deploying assemblies to be shared by a set of applications but I like the possibility of XCOPY deployments. However, deploying an assembly to the GAC is reported to improve its load performance compared to assemblies not located in the GAC. In addition strongly named assemblies are reported to load faster from the GAC because they are verified at the time they are installed rather than at runtime. In effect the .NET framework skips runtime verification for assemblies loaded from the GAC.

Back to Microsoft:

“There are several reasons why you might want to install an assembly into the global assembly cache:

• Shared location.

Assemblies that should be used by applications can be put in the global assembly cache. For example, if all applications should use an assembly located in the global assembly cache, a version policy statement can be added to the Machine.config file that redirects references to the assembly.

• File security.

Administrators often protect the systemroot directory using an Access Control List (ACL) to control write and execute access. Because the global assembly cache is installed in the systemroot directory, it inherits that directory's ACL. It is recommended that only users with Administrator privileges be allowed to delete files from the global assembly cache.

• Side-by-side versioning.

Multiple copies of assemblies with the same name but different version information can be maintained in the global assembly cache.

• Additional search location.

The common language runtime checks the global assembly cache for an assembly that matches the assembly request before probing or using the codebase information in a configuration file.” **

I find reasons such as side-by-side versioning quite compelling. I for one have worked on projects where various open source tools refer to different versions of other libraries. Getting all of the assemblies to live together in a single application directory can be a challenge. However, it must be noted that earlier in the article quoted above states:

“You should share assemblies by installing them into the global assembly cache only when necessary. As a general guideline, keep assembly dependencies private and locate assemblies in the application directory unless sharing an assembly is explicitly required.” **

* Global Assembly Cache
** Working with Assemblies and the Global Assembly Cache

I recently had a problem getting Fiddler to show the traffic to and from an application running on localhost when viewing the application with Internet Explorer. I completely forgot the workaround so thought a post on the subject would help.

There are some known issues with Fiddler and this is one of them. In short, both Internet Explorer and the .Net framework are setup not to send requests for localhost through a proxy. Of course Fiddler is a proxy and therefore will not receive the traffic.

One workaround is to use your machine name instead of localhost. So, http://localhost:8081/mytestpage.aspx becomes http://mymachinename:8081/mytestpage.aspx.

Another is to insert a dot (.) immediately after localhost. So, http://localhost:8081/mytestpage.aspx becomes http://localhost.:8081/mytestpage.aspx.

See also

The Fiddler website - http://www.fiddler2.com/fiddler2/