Friday, July 31, 2009

Interoperability Problem with WCF Web Service Solved

I've spoken to many of my friends about how WCF services do not work with older system (and some time modern system like Flex). Well it is my bad that I didn't search for a solution. Sorry! I didn't search for the 'problem' itself.
Now, when I was generating WSDL file from my .svc, I good a strange thought. I didn't want to give 1 WSDS and 3 xsd imports (yeah 3 xsd:import.. see your WSDL), I wanted to flatten it a bit and give single WSDL. While searching for the solution, I found this article by Christain Weyer. It revealed to me that lack of 'single and complete' WSDL file is the problem for old consumers. I highly encourage you to visit his blog and see the solution by yourself.

Friday, July 24, 2009

Wix with util:User

Wix installer is my latest adventure. It's good but few thing may leave you scratching you head for hours. One of them is user right assignment.
I wanted to give ASPNET user some access right to my MSMQ. So defining user went like this (after that I gave permission):
<util:User Id="aspnet" Name="ASPNET" / >
Everything worked fine, until my product was uninstalled (for testing... in real life people will love it). Uninstaller 'owned' the ASPNET user and deleted while uninstalling the product. Leaving system corrupt. I had to rescue my system's dangled processes by re-registering ASP.NET. And found (hit and try) this is the right way:
<util:User Id="aspnet" Name="ASPNET" CreateUser="no" UpdateIfExists="no" />
I don't know much about it but this worked and 'happy ending' is all I want at the starting of my weekends :)
Happy Weekends 2 u 2!

Thursday, July 16, 2009

Don't flush the Session after an exception occurs

I recently moved my all 'flush' at central location i.e. on session closed. And I close session in "finally" block of the code, to ensure that it really gets closed (not really).
So code would look like

//Use Session like never used before
//closes session that was assigned to the thread

CloseCurrentSession in NhibernateSessionManager would look like this,

ISession session = GetCurrentContextSession();
if(session != null && session.IsOpen)
session.Flush(); //evil is here

I was proud of this solution until I got into a database exception in my main code (which happens rarely after I write millions of lines of code).
If any such exception occurred and you try to flush, you will be delighted with another exception when you use session.Flush() It says "don't flush the Session after an exception occurs". For undisclosed reason, I couldn't use autoflush (reserved for next blog may be ;)

I believe there are alternate solutions but I as I told, I am lazy (like any other ORM), so I reverted back to my 'Flush manually' everytime when you make some entity dirty. Pretty shitty stuff huh???

Anyways, thanks for reading the blog even though the title "Don't flush the Session after an exception occurs" tells it all and inside matter is just ramblings.