Entity Framework Links

                I just completed a POC on Entity Framework using LINQ To Entities(L2E). I will start posting the valuable findings and workarounds that took a lot of my time. Meanwhile to get started below are few links:

A real good one as it compares the constructs generated with LINQ To SQL(L2S). LINQ To SQL at present looks much better comprehensive & simple (after all it’s done by C# team ). But when you need to support multiple databases you have to look beyond it & that’s a major reason of moving to it. There are a few others which can be found here (look for Michael Pizzo comment) though I would have stayed with L2S if it worked with multiple DBs.

Other good one seems to be this. The official link to the MSDN is here.  Useful EF FAQ by Danny Simmons can be found here (he rocks even the most active official forum). Watch my blog for further updates on LINQ To Entites.

Logging Best Practices

I have been using Log4Net for all my projects though Logging Application Block from Enterprise Library seems to be equally good. There is a full fledged war out there between two, but I don’t see a major motivation to move to latter (inspite of .NET framework logging being built around tracesources). Log4Net has got many trace levels which you can flip through your config file – FATAL, ERROR, DEBUG, WARN & INFO. They start from most limited logging to maximum.

Normally I see myself using ERROR & DEBUG, as most of the time it’s hard to communicate with developers when they have to draw line between others. My minimum instructions (though not enough see post script at end of this post) are

1) Use ERROR LEVEL for all Exception Logging (ensure that you hook into unhandled exceptions)
2) Use DEBUG level for Activity Logging (this is bit tricky and there are no straight guidelines for this). Activity Logging needs to be more contextual with revlevant information to your domain. Some programmers also use this to find performance bottlenecks in their system during production.

I will briefly elaborate steps to get started with Log4Net for above (skip them if you aren’t looking for them):

1) Add reference to log4net.dll into your project (This is required per project).

2) Modify your config file to add a log4net configsection & specify various appenders. This config is the for the main projects not class library projects. E.g. you have Presentation (ASP.NET) & Data Access Layer (C# Class Library) only web.config of your presentation project should be altered.

<?xml version=”1.0″ encoding=”utf-8″?>
<configuration>
<configSections>
<!–This is a must addition–>
<section name=”log4net” type=”log4net.Config.Log4NetConfigurationSectionHandler,log4net” />
</configSections>
<log4net>
<appender name=”RollingFileAppender” type=”log4net.Appender.RollingFileAppender,log4net”>
<param name=”File” value=”C:\\HRESWeb.log” /><!–File where the log should reside–>
<param name=”AppendToFile” value=”true” />
<!– FOR DATE BASED ROLL BACKUP –>
<param name=”rollingStyle” value=”Date” />
<param name=”datePattern” value=”yyyyMMdd” />
<layout type=”log4net.Layout.PatternLayout,log4net”>
<!–Pattern to add timestamp, type, etc.–>
<param name=”ConversionPattern” value=”%d [%t] %-5p %c [%x] – %m%n” />
</layout>
</appender>
<root>
<level value=”ERROR” /> <!–Just change the level to DEBUG for informative logging–>
<appender-ref ref=”RollingFileAppender” />
</root>
</log4net>
</configuration>

3) Add an entry in the AssemblyInfo.cs of the project whose config you edited in the second step.

[assembly: log4net.Config.XmlConfigurator(ConfigFile = "ConsoleApplication7.exe.config")]
or for Web.config
[assembly: log4net.Config.XmlConfigurator(ConfigFile = "Web.config")]

4) Start logging

Normally you would create a static ILog Object per class by specifying the class type as parameter & then use Debug & Error Methods for Logging

static readonly ILog log = LogManager.GetLogger(typeof(Program));
log.Debug(“Debug Message”); // No need to check if Debug level is enabled. Log4Net does that internally
log.Error(“Error Message”);

// A sample method with minimum features
public void SomeActivity()
{
try
{
log.Debug(“Entering”); // Activity Logging; context information here e.g. patient you processing, claim you working
//… Do Something
log.Debug(“Exiting”); // Activity Logging;
}
catch (Exception ex)
{
log.Error(“Description : “, ex); // This would also take inner exceptions if any
throw; //Don’t forget this
}
}

Logging is also normally implemented via AOP (I had posted a similar article using Unity on CodeProject, though this one deals with transactions).

A recommendation is that exceptions should also be posted in the Windows Event Logs (you can create a category for your application), the motivation being that this increases visibility & is easy for production guys to locate them instead of wading through your text, Udi organizes the same thought here.

I have seen few applications giving preference to Database logging. The same can be enabled via log4net (it’s just an appender). The thought process that goes into selecting database is normally easy search (say you want to retrive all errors occoured during last peek load or corelation queries). Another benefit is security – as DB entries are more secure than file system. But sometimes this additional security may cause delays in getting logs or make the process too rigid. To add to this, you need to consider purging logging records, performance impact on DB Server, license cost (if required), etc. Hence, it’s good to have flat files logging while creating custom applications, and provide multiple choices in case you are architecting a product.

Finally, if you are creating RIA / thin client apps (Silverlight, XBAP, Clickonce), you may not be able to create a log locally on client machine. I recommend that you implement logging for such applications also by sending messages to Web server / App Server, as it becomes quite necessary in few cases to know what’s going wrong on these clients. Checking if activity logging is enabled or not (assuming exception logging is always on) remains a challenge here.

P.S. An effective way to find out how good your logging is, ask developers to debug without breakpoints (IDE) during development. If they can do it just by looking at log file, you are on your way, else you might have to get ready for post production nightmares .

WWE with Silverlight

Happy to see this :) – WWE & Silverlight getting together

Debugging an XBAP / WCF application – Windows Vista + VS.NET 2008

Recently I was working on project involving XBAP & WCF. As usual WCF was providing the data to my XBAP presentation layer. The problem I immediately ran into was debugging XBAP. After searching over the web the closet I could was this link. A bunch of developers in my team who were using Windows XP got it working but somehow my machine running on Vista didn’t give in. Hence I decided to take the task myself up. After few trails & errors I got things moving as per below. Hope it saves your hair.

Step 1) Ensure that partial trust (Right Click Project in Solution Explorer -> Properties) is selected. Note debugging in full trust is easy (just F5 would work placing a break point in Service implementation) but that might give you a false sense of comfort considering the publish of XBAP applications work only in partial trust.

Partial Trust

Step 2) Ensure that you have already published your project once. Right Click Project -> Publish -> Give a localhost site name e.g. http://localhost/RootPOC & click on finish.

Publish

Step 3) Important one. Click on debug tab. Select the start external program radio button & give the PresentationHost.exe path. Beneath in start options enter the command line options as

-debug (your publish location + projectname.xbap) – debugSecurityZoneUrl (your WCF Service Url)

E.g. -debug “http://localhost/RootPOC/WpfBrowserApplication5.xbap” -debugSecurityZoneUrl http://localhost/WcfServiceWF

Debug Options

Step 4) Ensure the WCF Service debug option is set to true in web.config (assuming you have hosted WCF Service in IIS) <compilation debug=”true“>

Step 5) Run the application (F5). Click on Debug Menu -> Attach Process to select PresentationHost.exe. Then say ok.

Attach Process Dialog

Step 6) Now you can place a break point anywhere in your WCF Service. When you perform an action you would see that execution breaks at your breakpoint.

Break Point

That’s it. You all set to debug WCF from an XBAP application on Windows Vista / VS 2008. Happy coding!!!