Li Chen's Blog

  • Revisiting ASP.NET logging and tracing solutions

    1 Comment

    It has been several years since I researched the logging and tracing solutions last time so I need a revisit. ASP.NET always had tracing that can be turned on at the page level through page directive or the application level through the web.config file. The trace output can be either appended to the end of a page and viewed via trace.axd. ASP.NET tracing is different to System.Diagnostic tracing. Fortunately, ASP.NET 2.0 or later allows integration between the two. Dino has an excellent article on this subject.

    The ASP.NET tracing is most useful tracing events relating to page life cycle. For flexibility in filtering and sending trace data to different target, there are a few logging frameworks available, such as log4net, nlog and the Enterprise Library Logging Application Block. If an application can not be tied to a particular logging framework, then one can either use a common library, or roll your own.

    In .net 2.0 or later, there is actually an enhancement to the static Trace class called TraceSource. TraceSource is quite flexible and it allows filter both on the writer side through TraceSwitch and on the listener side through listeners configuration and filter. For a comparison between TraceSource and other frameworks, see the discussion on stackoverflow. For projects that need to minimize external dependency, TraceSource is an excellent choice. The only limitation to the TraceSource solution is the availability of listeners. .net framework comes with the 10 listeners:

    Microsoft.VisualBasic.Logging.FileLogTraceListener
    System.Diagnostics.ConsoleTraceListener
    System.Diagnostics.DefaultTraceListener
    System.Diagnostics.DelimitedListTraceListener
    System.Diagnostics.Eventing.EventProviderTraceListener
    System.Diagnostics.EventLogTraceListener
    System.Diagnostics.EventSchemaTraceListener
    System.Diagnostics.TextWriterTraceListener
    System.Diagnostics.XmlWriterTraceListener
    System.Web.WebPageTraceListener

    The KUADC project comes with 6 listeners:

    SqlTraceListener
    SmtpTraceListener
    OutputDebugStringTraceListener
    ConsoleTraceListener
    CustomTraceListener
    InMemoryTraceListener

    There are a few other trace listeners such as TCPTraceListener and UDPTraceListener can be found on searching Google.

  • Uploaded Silverlight sample for VBScript.net compiler

    No Comments

    I have uploaded Silverlight sample that uses my VBScript.net compiler to http://www.codeplex.com/aspclassiccompiler. It is available under the source tag in change set 31328 or later.

    I am not quite using the capabilities in Microsoft.Scripting.Silverlight yet. I want to take advantages of it when its document becomes available. For the time being, I created my own little host called VBScriptHost in the SilverlightApplication1 project.

    I modified App.xaml.cs to create an instance of VBScriptHost and expose it. In MainPage.xaml.cs, I created a ScriptScope object. This is the object that I feed host variables to VBScript. I then parse this object to the Execute method of a CompiledCode object.

    In the example, I passed MainPage itself with the variable name "page" to the VBScript. In order to expose the object hierachy of the MainPage, I have to expose MyButton using the x:FieldModifier="public" attribute; otherwise, it is an internal property and is hidden from the dynamic code. In future versions, I will modify my binder in an attempt to access the internal properties so that we do not have to change the access level of objects in the page.

  • Uploaded ASP Classic Compiler Build 0.5.4.34834. This build supports VS2010 and Silverlight.

    No Comments

    As usually, it can be downloaded from the source tab of http://www.codeplex.com/aspclassiccompiler.

    1. This version is built with DLR 0.92. It is compatible with VS 2010 beta 2.
    2. We have resolved all API difference with Silverlight so that Silverlight build of our VBScript.net compiler is available for the first time. We will upload some samples in the next weekly release.
    3. All the binaries are consolidated into the bin folder.

    Going forward, we will stay on DLR 0.92 for a while so that we have a stable build so fix the bugs in core features.