Thursday, March 19, 2009

log4net with WCF Services

This week I ‘ve been working on adding tracing to a WCF IIS hosted application. It all started pretty easy since already has an appender for

So, I created a little wrapper around the log4net library and called the Debug function. My project had both aspx pages and svc services. These services were implemented in a separate dll (not in the web project). Oh! I forgot to mention that I wanted to use the AspNetRaceAppender so I could watch the trace in the trace.axd ‘page’.

But it was not working… I had a few debug entries and nothing appeared on the trace page. The ‘wired’ part was that if I’d copied and pasted the same debugging line in the aspx code behind’s it’d worked! So what’s up with that?

I started googling around I found close to nothing about log4net and WCF services. And that’s why I decided to post the solution here. Trying around many different scenarios I found the solution. You have to enable your wcf services to get the HttpCopntext from the web application. And in order to do that, you need to add the following line in your web app’s web.config file.

<serviceHostingEnvironment aspNetCompatibilityEnabled="true" />

Add that line inside the system.serviceModel part. Also, you have to add the following attribute to your services’s classes.

[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Required)]

Hope this helps somebody!

P.S: All the code I write is “works on my machine” certified ;)


Read Full Post

Thursday, March 12, 2009

Forget what I said about SQL Data Services :(

Remember my two posts about Microsoft Sql Data Services (Starting Up With SDS and Writing Data To The Cloud)?, well, they are both wrong now. Not wrong but old.

This week I read on the SDS blog that they will introduce relational data base features (which I think it’s great) but also that they are removing the good old ACE model.

Read the original post here

Edit: I just read a new post from the SDS team were they answered a few questions from developers.

This is what I asked them and what they answered:

You say, you will no longer support the ACE model since Windows Azure has the same data model. If I’m going to put my application in Windows Azure (as I did) my best option for data is SDS, right? As I understood, Microsoft’s approach for cloud computing was Windows Azure as the platform for developers and SDS to store the data. And now you say I can use Windows Azure storage… what’s the difference? What’s the path to follow?

The best storage option for an Azure Services Platform application depends on your application. At a very high level, if you require the features of a relational database, use SDS. If you require basic blob or “schemaless” storage, then Windows Azure Storage is for you. Both will be key capabilities available to developers in the overall Azure Services platform.

Read the whole Q&A session here.

Read Full Post