by David Kiff
23. September 2009 15:25
I found myself repeating the same old try..catch logic within our WCF services. Quite often we would catch specific exceptions and re-throw them as fault exceptions, whereas the rest required logging and re-throwing.
I decided to create a wrapper around the class responsible for invoking the operations. That will allow us to add a generic try..catch around every operation, that we apply the behaviour to.More...
by David Kiff
22. September 2009 11:27
This blog post will describe how to secure your WCF services that are hosted within IIS 7.0, using Secure Sockets Layer.
Secure Sockets Layer (SSL) is a protocol primarily used for encryption of data between two parties, running at the Transport Layer.More...
by David Kiff
21. September 2009 16:41
I have spent around 4 hours trying to diagnose the follow exception:
“Unable to load one or more of the requested types”
This error message is extremely unhelpful, so I took a look at the stack, that suggested that EntityFramework was causing the exception:
Retrieve the LoaderExceptions property for more information. at System.Reflection.Module._GetTypesInternal(StackCrawlMark& stackMark) at System.Reflection.Assembly.GetTypes() at System.Data.Metadata.Edm.ObjectItemCollection.AssemblyCacheEntry.LoadTypesFromAssembly(LoadingContext context) at System.Data.Metadata.Edm.ObjectItemCollection.AssemblyCacheEntry.InternalLoadAssemblyFromCache(LoadingContext context)
The stack has contains a helpful message that I overlooked in my haste to fix the problem “Retrieve the LoaderExceptions property for more information”.
The next question is how do you retrieve “more information”? Where is that property? The answer lies within the ReflectionTypeLoadException, which contains the LoaderExceptions property (an array of helpful exceptions).
In the debugger it would have been easy to identify this, however this issue was appearing in our test environment with no debugging support. I ended up adding a try and catch around the offending code (found from the original stack trace), then casting the exception to ReflectionTypeLoadException and persisting the message and stack trace to a file:
try
{
//Do work
}
catch(Exception ex)
{
ReflectionTypeLoadException exception = ex as ReflectionTypeLoadException;
if(exception == null)
System.IO.File.AppendAllText("C:\\TestLog.txt", "Not a ReflectionTypeLoadException ex.");
else
{
foreach (Exception loaderException in exception.LoaderExceptions)
{
System.IO.File.AppendAllText("C:\\TestLog.txt", loaderException.Message);
System.IO.File.AppendAllText("C:\\TestLog.txt", loaderException.StackTrace);
}
}
}
7ebf465c-392f-4518-b535-bc6076189934|3|3.7
Tags:
by David Kiff
16. September 2009 08:00
I was talking to a friend not so long ago about documentation. My argument is that writing external documents in order to define the behaviour and interactions of software is (or should be) covered by the business/stakeholders in their requirements or with the acceptance tests that have been defined for the application. There is of course a need to document the technical details, such as why you did something the way you did, and I feel this is best covered from self describing, well written, Unit Tests. More...