Wednesday, 17 July 2013

Using TypeScript to implement OOP inherited Loggers

TypeScript is a framework for creating compile type checking and simplifying OOP (Object Oriented Programming) in Javascript. It is a framework available on Codeplex and its primary initiator is Microsoft. The source code is freely available at the following Git url: https://git01.codeplex.com/typescript

Note, by using Git ,it did take some time to download the entire source code, as there are many files. I would like to have the Codeplex Projects available instead for Mercurial / Hg. The website of TypeScript is available here:
http://www.typescriptlang.org/

Note - there is also a video from Channel9 MSDN, where Anders Hejlsberg presents TypeScript: One of the employees from Microsoft involved in TypeScript then is Anders Hejlsberg. He is actually the core Developer. He is one of Microsoft best scientists/developers and he has also been very much involved in C# and LINQ. It is promising for TypeScript that such a well-known core developer is on the team. TypeScript offers a compiler, tsc (TypeScript compiler), that converts typescript files (.ts) to JavaScript files (.js).

TypeScript is basically a code generation language for Javascript that will make it easier to create and scale Object Oriented Javascript applications. But it is also more than that. It is an entire new way of developing Javascript that will let more developers with traditional C# background and application developers in general be able to create Javascript code with basic understanding in Javascript, but still let them write structured, object oriented Javascript. Many developers know enough Javascript to implement basic functionality, but to support Object Orientation via prototypes is a less common skill. Now, with the help of TypeScript, you can write code that looks a bit like C#, but generates the necessary Javascript to allow OOP paradigm and structuring of your code. You can also create modules, which are similar to namespaces, which are either external or internal modules. For exernal modules, RequireJs is often used. In this example we will use the simpler internal modules to create a simple set of loggers to be used in the web client with the help of TypeScript. Before I present the code, you can download a TypeScript Visual Studio 2012 plugin from here:

TypeScript Visual Studio 2012 plugin

Please note, there are more editors capable of editing typescript and generating Javascript, such as Sublime Text. There is though little doubt that the best editor for TypeScript files (.ts) is Visual Studio, preferably the 2012 Version. The files you reference in the html files will still be Javascript, of course. TypeScript will usually generate a .js file, a js.min file and a source map with the extension js.map, which is needed for debugging your TypeScript code.

To generate source map files, download the Web Essentials plugin for Visual Studio from here:

Visual Studio Web Essentials Extensions for VS2012

You can also download this extension from Tools-Extensions in Visual Studio. After you have installed the Web Essentials Extensions, go to the option Options-Web Essentials-TypeScript. Activate the options Generate Source Map, Show Preview Window, Minify Generated Javascript, Compile TypeScript on Save and Add Generated files to Project. You obviously want to check in all four file types into your Version Control System (VCS), the .ts, .js, .js.min and .js.map files. Note that editing the .ts file in Visual Studio will generate the .js, js.min and .js.map files. The .js file will be shown in a preview window. Experienced Javascript programmers that are comfortable with prototypes in Javascript will note how TypeScript generates closures, iffys (immediately executing functions) and use prototypes to support OOP. The problem is that the syntax does not scale well with deep inheritance and OOP in Javascript. TypeScript converts your TypeScript code to Javascript and aids you in realising OOP based Javascript and also provided compile type checking. Let's first generate a TypeScript Application. Note that you can add TypeScript to an existing MVC Application for example. It is easiest to begin with the project solution for TypeScript for initial testing, HTML Application With TypeScript:
Note that TypeScript do work with ordinary Web Projects also such as MVC Applications where the Views and Scripts resides (GUI Project in your solution).

You can add a new TypeScript file explicitly:

Check that your options for Web Essentials are correct before you continue:

I also add the following NuGet packages in this sample: jquery, jquery.ui.combined and toastr with the Install-Package command in Package Manager Console in VS2012. It is not uncommon to add RequireJs also if you will create external modules with TypeScript. Here, we will create a simple external module.

Let's look at a TypeScript file with Loggers next:
/// <reference path="TypeDefinitions/jqueryui.d.ts" />
/// <reference path="TypeDefinitions/jquery.d.ts" />
/// <reference path="TypeDefinitions/toastr.d.ts" />

// Module App.Util.Loggers 
module App.Util.Loggers {

    export enum LogLevel {
        Information  = 0,
        Warning = 1,
        Error = 2,    
    }

    // Interface ILogger
    export interface ILogger {
        Log(message: string): void;
        LogLevel: LogLevel; 
    }

    export class BaseLogger {

        private logLevel : LogLevel;

        constructor(logLevel: LogLevel) {
            this.LogLevel = logLevel;
        }
        
        get LogLevel() {
            return this.logLevel; 
        } 

        set LogLevel(logLevel) {
            if (this.logLevel != logLevel) {
                this.logLevel = logLevel; 
            }
        }

    }

    // Class DialogLogger
    export class DialogLogger extends BaseLogger implements ILogger {

        private anchorId: string; 
        private modal : bool;

        constructor(logLevel: LogLevel, anchorId : string, modal? : bool) {
            super(logLevel); 
            this.AnchorId = anchorId; 
            this.Modal = modal; 
        }

        public Log(message: string): void {

            var dialog = $("#" + this.AnchorId).dialog({
                title: message,
                buttons: {
                    Ok: function () {
                        $(this).dialog("close");
                    }
                },
                modal: this.Modal
            });                 

            switch (this.LogLevel) {
            
                case LogLevel.Information:
                    dialog.parent().addClass("ui-icon-information");       
                    break;

                case LogLevel.Error:               
                    dialog.parent().addClass("ui-state-error");       
                    break;

                case LogLevel.Warning:
                    dialog.parent().addClass("ui-state-warning");       
                    break;

            }
          
        }

        get AnchorId() {
            return this.anchorId;
        }

        set AnchorId(anchorId: string) {
            if (this.anchorId != anchorId) {
                this.anchorId = anchorId; 
            }
        }

        get Modal(){
            return this.modal; 
        }

        set Modal(modal : bool) {
            if (this.modal != modal) {
                this.modal = modal; 
            }
        }

    }

    //Class ToasterLogger
    export class ToasterLogger extends BaseLogger implements ILogger {

        constructor(logLevel: LogLevel) {
            super(logLevel);
        }

        public Log(message: string): void {

            switch (this.LogLevel) {

                case LogLevel.Information:
                    toastr.info(message);
                    break;

                case LogLevel.Error:
                    toastr.error(message); 
                    break;

                case LogLevel.Warning:
                    toastr.warning(message); 
                    break;

            }
        
        }    
    }

    //Class ConsoleLogger
    export class ConsoleLogger extends BaseLogger implements ILogger {

        constructor(logLevel: LogLevel) {
            super(logLevel); 
        }

        public Log(message: string): void {
            switch (this.LogLevel) {

                case LogLevel.Information:
                    console.info(message);
                    break;

                case LogLevel.Error:
                    console.error(message);
                    break;

                case LogLevel.Warning:
                    console.warn(message);
                    break;

            }
        }
    }


}


The Javascript generated from the Logger.ts TypeScript file is:
var __extends = this.__extends || function (d, b) {
    for (var p in b) if (b.hasOwnProperty(p)) d[p] = b[p];
    function __() { this.constructor = d; }
    __.prototype = b.prototype;
    d.prototype = new __();
};
var App;
(function (App) {
    (function (Util) {
        /// 
        /// 
        /// 
        // Module App.Util.Loggers
        (function (Loggers) {
            (function (LogLevel) {
                LogLevel[LogLevel["Information"] = 0] = "Information";
                LogLevel[LogLevel["Warning"] = 1] = "Warning";
                LogLevel[LogLevel["Error"] = 2] = "Error";
            })(Loggers.LogLevel || (Loggers.LogLevel = {}));
            var LogLevel = Loggers.LogLevel;

            var BaseLogger = (function () {
                function BaseLogger(logLevel) {
                    this.LogLevel = logLevel;
                }
                Object.defineProperty(BaseLogger.prototype, "LogLevel", {
                    get: function () {
                        return this.logLevel;
                    },
                    set: function (logLevel) {
                        if (this.logLevel != logLevel) {
                            this.logLevel = logLevel;
                        }
                    },
                    enumerable: true,
                    configurable: true
                });

                return BaseLogger;
            })();
            Loggers.BaseLogger = BaseLogger;

            // Class DialogLogger
            var DialogLogger = (function (_super) {
                __extends(DialogLogger, _super);
                function DialogLogger(logLevel, anchorId, modal) {
                    _super.call(this, logLevel);
                    this.AnchorId = anchorId;
                    this.Modal = modal;
                }
                DialogLogger.prototype.Log = function (message) {
                    var dialog = $("#" + this.AnchorId).dialog({
                        title: message,
                        buttons: {
                            Ok: function () {
                                $(this).dialog("close");
                            }
                        },
                        modal: this.Modal
                    });

                    switch (this.LogLevel) {
                        case LogLevel.Information:
                            dialog.parent().addClass("ui-icon-information");
                            break;

                        case LogLevel.Error:
                            dialog.parent().addClass("ui-state-error");
                            break;

                        case LogLevel.Warning:
                            dialog.parent().addClass("ui-state-warning");
                            break;
                    }
                };

                Object.defineProperty(DialogLogger.prototype, "AnchorId", {
                    get: function () {
                        return this.anchorId;
                    },
                    set: function (anchorId) {
                        if (this.anchorId != anchorId) {
                            this.anchorId = anchorId;
                        }
                    },
                    enumerable: true,
                    configurable: true
                });


                Object.defineProperty(DialogLogger.prototype, "Modal", {
                    get: function () {
                        return this.modal;
                    },
                    set: function (modal) {
                        if (this.modal != modal) {
                            this.modal = modal;
                        }
                    },
                    enumerable: true,
                    configurable: true
                });

                return DialogLogger;
            })(BaseLogger);
            Loggers.DialogLogger = DialogLogger;

            //Class ToasterLogger
            var ToasterLogger = (function (_super) {
                __extends(ToasterLogger, _super);
                function ToasterLogger(logLevel) {
                    _super.call(this, logLevel);
                }
                ToasterLogger.prototype.Log = function (message) {
                    switch (this.LogLevel) {
                        case LogLevel.Information:
                            toastr.info(message);
                            break;

                        case LogLevel.Error:
                            toastr.error(message);
                            break;

                        case LogLevel.Warning:
                            toastr.warning(message);
                            break;
                    }
                };
                return ToasterLogger;
            })(BaseLogger);
            Loggers.ToasterLogger = ToasterLogger;

            //Class ConsoleLogger
            var ConsoleLogger = (function (_super) {
                __extends(ConsoleLogger, _super);
                function ConsoleLogger(logLevel) {
                    _super.call(this, logLevel);
                }
                ConsoleLogger.prototype.Log = function (message) {
                    switch (this.LogLevel) {
                        case LogLevel.Information:
                            console.info(message);
                            break;

                        case LogLevel.Error:
                            console.error(message);
                            break;

                        case LogLevel.Warning:
                            console.warn(message);
                            break;
                    }
                };
                return ConsoleLogger;
            })(BaseLogger);
            Loggers.ConsoleLogger = ConsoleLogger;
        })(Util.Loggers || (Util.Loggers = {}));
        var Loggers = Util.Loggers;
    })(App.Util || (App.Util = {}));
    var Util = App.Util;
})(App || (App = {}));
//@ sourceMappingURL=Logger.js.map

As noted before, TypeScript generates this Javascript file and can also create a minified Version, in addition a sourceMappingURL is also set to give the Javascript file(s) a source map, so we can debug the TypeScript file. You edit the .ts file and edit the .ts file. TypeScript in other ways lets you work in a higher level Language than Javascript to let you work with more familiar code and also adds compilation type level safety and checking. Whenever you edit and save the .ts file, the generation of a .js, js.min and js.map files are done. Note that this can take some seconds when you work in the IDE. I expect future versions of TypeScript to have a quicker compiler. I have used TypeScript 0.9.1 in this example.

I test out the Logger.ts TypeScript file above with the following HTML:
<html lang="en">
<head>
    <meta charset="utf-8" />
    <title>TypeScript HTML App</title>
    <link rel="stylesheet" href="app.css" type="text/css" />
    <script src="app.js"></script>
    <link href="content/toastr.min.css" rel="stylesheet" />
    <script src="Scripts/jquery-1.6.4.min.js"></script>
    <script src="Scripts/jquery-ui-1.10.3.min.js"></script>
    <link href="content/themes/base/jquery.ui.all.css" rel="stylesheet" />
    <script src="Scripts/toastr.min.js"></script>
    <script src="Scripts/Logger.js"></script>
</head>
<body>
    <h1>TypeScript Logging demo</h1>

    <script type="text/javascript">

        function consoleLogger() {
            var logger = new App.Util.Loggers.ConsoleLogger(App.Util.Loggers.LogLevel.Warning);
            logger.Log("Hello from console logger!"); 
        }

        function toastrLogger() {
            var logger = new App.Util.Loggers.ToasterLogger(App.Util.Loggers.LogLevel.Information);
            logger.Log("Hello from toastr logger!");
        }

        function dialogLogger() {
            var logger = new App.Util.Loggers.DialogLogger(App.Util.Loggers.LogLevel.Error, "dialog-message", true);
            logger.Log("Hello from dialog logger!");
        }

    </script>

    <div id="content">

        <input type="button" value="Test console logger" onclick="consoleLogger()" />

        <input type="button" value="Test toastr logger" onclick="toastrLogger()" />

        <input type="button" value="Test dialog logger" onclick="dialogLogger()" />

        <div id="dialog-message" style="display: none">
            <p>This dialog was launched by App.Util.Loggers.DialogLogger!</p>
        </div>

    </div>

</body>
</html>
As you can see from the TypeScript code above, we generated Javascript where one BaseLogger class was inherited three times. We used the high level constructs of TypeScript such as:
  • class - Ability to defined a class/closure,container in TypeScript
  • module - Ability to create a module (internal in this case) that can assemble a collection of classes, Interfaces, Methods/functions in a namespace like collection or closure/container. Note I set the module name and namespace App.Util.Logging.
  • export - Here we define the visible members of our module
  • Interface - Interfaces or code contracts are a new concept in TypeScript - for Javascript that is.
  • enums - Enums are supported in TypeScript!
  • implements - keyword to implement an Interface
  • constructor - constructors are supported in TypeScript (you can have a multiple overloads)
  • extends - defines which baseclass to inherit
  • super - calling the base class constructor - this is required for derived classes in TypeScript.


We also use some features in TypeScript here:

  • Access level identifiers - we can use public, private - even static
  • Strong typing - we define a function parameter to be for example of type string by suffixing the data type with a colon in between. This is removed from the generated Javascript, but it gives you compile time type checking and safety previously not available in Javascript except another Third party framework
  • Compile time error checking - When you type errors in the .ts file, the errors are actually listed in the Error List in Visual Studio.


The code above also uses TypeScript Type definition files, with the extension .d.ts. You can see that I have put a reference at the top of the TypeScript file. For internal modules, you use this technique. For external modules, you can use RequireJs to avoid adding the script references in the HTML file, with the AMD loader.

Boris Yankov has collected a large collection of d.ts files here:
https://github.com/borisyankov/DefinitelyTyped These are required files, such that TypeScript can understand and consume Third party Libraries within the Typescript .ts file. A positive side effect of this is compile level syntax checking and IntelliSense. Using Third party libraries for Javascript such as Jquery, KnockoutJs, Toastr and Jquery UI (plus a ton of others) have never been more easy to work with. We all know the difficulties around writing correct Javascript with correct casing, well now TypeScript will throw in a compiler clever enough to check that you write correct TypeScript and consume Third party Libraries correct for you. This will make an impact on how we code Javascript.

Does this mean that Javascript will be "hidden" under the covers of TypeScript? No, definitely a solid background in Javascript is always positive when it comes to web Client Development. But TypeScript will enable developers not conformtable with Javascript to write more Javascript. And in the end, this will help more developers create better and more scalable Javascript Applications. There is no need to write pure Javascript always, when TypeScript can let you structure your code in a more natural manner with traditional OOP Language. This will help developers becoming more productive, deliver functionality quicker and help the industry shift a little bit more towards Javascript. Douglas Crockford has often ridiculed parts of Javascript as being a bunch of bologny, but there are also The Good Parts. I will actually say that TypeScript should be such a good part. It is of course important that the Javascript generated from the TypeScript is correct. With Anders Hejlsberg at the core team, we have no reason to speculate that TypeScript is really a promising Javascript framework, coming soon to a developer box near you.

Note: I have also used EcmaScript 5 Properties in the sample above. IE 8 should support ES5, and newer browsers too. To support Ecmascript 5, edit the Project file and make sure you add ES5 as the version:

<PropertyGroup Condition="'$(Configuration)' == 'Debug'">
    <TypeScriptTarget>ES5</TypeScriptTarget>
    <TypeScriptIncludeComments>true</TypeScriptIncludeComments>
    <TypeScriptSourceMap>true</TypeScriptSourceMap>
    <TypeScriptModuleKind>AMD</TypeScriptModuleKind>
  </PropertyGroup>
  <PropertyGroup Condition="'$(Configuration)' == 'Release'">
    <TypeScriptTarget>ES5</TypeScriptTarget>
    <TypeScriptIncludeComments>false</TypeScriptIncludeComments>
    <TypeScriptSourceMap>false</TypeScriptSourceMap>
    <TypeScriptModuleKind>AMD</TypeScriptModuleKind>
  </PropertyGroup>

Note in the Project file above, I set the TypeScriptTarget to ES5, to support Ecmascript 5 properties. I think that one must also use Properties in TypeScript if your target audience can use it. It is, after all a more correct way of doing OOP.

I have worked some with Javascript, but often I work individually on projects with Javascript. Collaborating and sharing Javascript is often hard to do. The structured code of TypeScript will make it easier for more developers and large part of entire teams to work with and enhance Javascript frameworks. More work will be done on the clients and richer user experiences will be the result (RIAs). This was just an introduction to TypeScript, but I find it a very promising technology. If you want to play around with the source code above, I have packaged the solution in a ZIP file here:
TypeScriptLogger.zip

Happy coding with TypeScript! I suggest you watch the video where Anders Hejlsberg explains TypeScript on the TypeScript website. If you have access to Pluralsight, there is a 4 1/2 hour long video covering TypeScript fundamentals in quite a complete manner. I have watched this entire course and it is quite good.

Sunday, 14 July 2013

MEF and Memory in MEF 2

MEF - or Managed Extensibility Framework - is Microsoft's official Inversion Of Control (IoC) and Dependency Injection (DI) framework. Although MEF is not a true DI container, it has a lot of features compared to many other IoC frameworks. However, MEF is often measured as a slow IoC framework in tests and therefore is not very tempting to use. MEF on the other side is readily available in .NET. If you use .NET 4.5, you will have access to MEF 2 features such as ExportFactory. The worst feature in MEF is arguable the way the IoC container disposes objects. If you have a nonshared Part or instance (i.e not a singleton, but a part you can instantiate multiple instances of), and this instance type implements IDisposable, most likely this object will not be disposed until the container is teared down. This is not a desired feature, as object instances will accumulate and memory consumption of your application using MEF will go up. With the aid of ExportFactory, we can be able to free up object instances on demand. Let's use the ServiceLocator to get our instances from ExportFactory. When you use ExportFactory, you call CreateExport(), which returns an ExportLifetimeContext<T>. This object can then be used to dispose the object. By disposing the ExportLifetimeContext<T>, the object that was created with the ExportFactory is truly disposed and released at the same time from the IoC, finally making it possible to gather with Garbage Collection (GC), in the end freeing up memory. The code for retrieving the object instance via an ExportFactory can look like this:

    [Export]
    public class ExportFactoryProvider<T>
    {

        [Import]
        public ExportFactory<T> Factory { get; set; }

    }

Let's test out this ExportFactoryProvider with service locator. First let's create a part we can test. Let's say we got a simple view model:

    [Export(typeof(ITestViewModel))] 
    public class TestViewModel : ITestViewModel, IDisposable
    {

        public void SayHello(string message)
        {
            Debug.WriteLine(string.Format("Hi {0}!", message));
        }

        public void Dispose()
        {
            Dispose(true);
            GC.SuppressFinalize(this); 
        }

        private void Dispose(bool p)
        {
            Console.WriteLine("Disposed TestViewModel");
        }

    }

We can then create an instance of the TestViewModel using ServiceLocator using this:

            var serviceFactory = ServiceLocator.Current.GetInstance<ExportFactoryProvider<ITestViewModel>>().Factory;

            var testViewModelExport = serviceFactory.CreateExport(); 
            MessageBox.Show("About to dispose an instance of ITestViewModel: ");

            testViewModelExport.Value.SayHello("Johnny");
            testViewModelExport.Dispose();

As you can see above, we must first use the ExportFactoryProvider, then call CreateExport, then use the Value property and then use the ExportLifetimeContext<T> to control the disposing of the object from the IoC container. But as you can see, we must do some juggling to keep a reference to the lifetime context and the instance itself. These two objects are inherently tied together. Let's create a generic class to keep them together.

    [Export]
    [PartCreationPolicy(System.ComponentModel.Composition.CreationPolicy.NonShared)]
    public class ExportFactoryInstantiator<T> : IPartImportsSatisfiedNotification
    {

        [Import]
        public ExportFactory<T> Factory { get; set; }

        public T Instance { get; private set; }

        private ExportLifetimeContext<T> lifeTime;

        public void OnImportsSatisfied()
        {
            lifeTime = Factory.CreateExport();
            Instance = lifeTime.Value;
        }

        public bool DisposeOnDemand()
        {
            if (lifeTime == null)
                return false;
            lifeTime.Dispose();
            return Instance == null; 
        }

    }

You can use the class above, ExportFactoryInstantiator to create NonShared parts (object instances) via ExportFactory and via the instance created access the Instance property to get to the actual object and use the method DisposeOnDemand, which returns true if the object was set to null during the execution of this method. You can also see that we use IPartImportsSatisfiedNotification to await the resolution.

            var anotherTestViewModel = ServiceLocator.Current.GetInstance<ExportFactoryInstantiator<ITestViewModel>>();
            anotherTestViewModel.Instance.SayHello("Bob");
            anotherTestViewModel.DisposeOnDemand(); 
Note that the instance now can be easily worked against. However, still it is a bit verbose, we can create a static method to help us with that:

        public static ExportFactoryInstantiator<T> ResolveViaExportFactory<T>()
        {
            return ServiceLocator.Current.GetInstance<ExportFactoryInstantiator<T>>();
        }

We have finally reduced the complexity of being able to dispose MEF parts on demand in our applications:

            var yetAnotherTestViewModel = ResolveViaExportFactory<ITestViewModel>();
            yetAnotherTestViewModel.Instance.SayHello("Joey");
            yetAnotherTestViewModel.DisposeOnDemand(); 

To sum up, MEF 2 provides a feature where we can now dispose parts from the container on demand. This is a great improvement and will reduce the issues around memory leaks substantially. If you have complex viewmodels, disposing a view model high up in the object graph will usually dispose all child view models, properties and so on and reduce memory usage. But always be careful when disposing objects from your container. You must be sure that the object will not be useful anymore. In this StackOverflow thread you can also see an example of how to use a Part only when you need it, inside a using block: Nicholas Blumhardt on using ServiceLocator and ExportFactory As you can see, I use Nicholas Blumhardt's code as a starting point and refine it a bit to reduce complexity and tie together the Instance and provide DisponseOnDemand method. You must yourself judge when to release a part, be it a view model or some other resource. The using block are handy when you are sure you do not need the instance more than temporarily. You should consider doing that instead of importing many parts to your view model. Yes, the object creation of your view models will be quicker and yes, the execution will in fact be slower because of the need to create imported parts on demand via ServiceLocator, but at the same time, your application will keep a very low memory profile. I haven't had the opportunity to test out the code above yet against production code, so do not use it in production without verifying its validity in for example Red Gate ANTS Memory Profiler and testing it. I would like to hear from other developers using MEF and have experienced its memory usage woes for more views about MEF. If you have also tips against efficiency and performance of MEF containers, please let us other MEF developers know.

Monday, 1 July 2013

Creating a Fiddler Extension

This article will quickly describe how you can create a Fiddler Extension. A Fiddler Extension can be loaded into the tool Fiddler by creating a Class library in .NET programmed in C#. If you use Fiddler 2, target .NET 2 or .NET 3.5. If you use Fiddler 4 (beta), you must actually target .NET 4 (this is not documented well on the Fiddler website at Fiddler 2).

First off, install Fiddler 4, if you have not installed it yet. You need at least Visual Studio 2005, but if you work with extensions for Fiddler 4, you must target .NET 4 (Visual Studio 2010 or 2012). Fiddler extensions are implemented using interfaces. Create a new solution in Visual Studio and select creating a Class Library. First off, add a reference to Fiddler.exe in your Fiddler installation folder. This exe file usually resides in the folder C:\Program Files (x86)\Fiddler2, the default location for installing Fiddler. After referencing the Fiddler executable, add also a reference to System.Windows.Forms, if your Fiddler extension will modify the GUI directly.

Here is a sample Fiddler extension that will remove a host by typing the command e.g. RemoveHost www.yourhosthere.com in the QuickExec command bar in Fiddler. Here www.yourhosthere.com is the hostname which is an example of a server to remove in the listing of Fiddler's capture of traffic. This Fiddler extension will remove all captures where we have a HTTP Header that contains a Host value of ww.yourhosthere.com We use the interface IHandleExecAction to add support for QuickExec here.

In addition, the Fiddler extension fakes the UserAgent by setting it to Violin. This extension is based on the tutorial at Fiddler website and the video of the Pluralsight course for Fiddler, which I have fully watched. The author, Robert Boedigheimer does an excellent job of explaining the possibilities of Fiddler tool at a basic, intermediate and advanced level. To add support for this we implement the interface IAutoTamper. Here is the source code of the extension I ended up writing in Visual Studio 2012. Remember to target .NET 4 Framework to support Fiddler 4!

using System;
using System.Collections.Generic;
using System.Text;
using System;
using System.Windows.Forms;
using Fiddler;


namespace TestFiddlerExtension
{
    public class Violin : Fiddler.IAutoTamper, IHandleExecAction    // Ensure class is public, or Fiddler won't see it!
    {
        string sUserAgent = "";

        public Violin()
        {
            /* NOTE: It's possible that Fiddler UI isn't fully loaded yet, so don't add any UI in the constructor.

               But it's also possible that AutoTamper* methods are called before OnLoad (below), so be
               sure any needed data structures are initialized to safe values here in this constructor */

            sUserAgent = "Violin";
        }

        public void OnLoad() { /* Load your UI here */ }
        public void OnBeforeUnload() { }

        public void AutoTamperRequestBefore(Session oSession)
        {
            oSession.oRequest["User-Agent"] = sUserAgent;
        }
        public void AutoTamperRequestAfter(Session oSession) { }
        public void AutoTamperResponseBefore(Session oSession) { }
        public void AutoTamperResponseAfter(Session oSession) { }
        public void OnBeforeReturningError(Session oSession) { }

        public bool OnExecAction(string sCommand)
        {
            string[] args = Fiddler.Utilities.Parameterize(sCommand);

            string command = args[0];

            if (command.ToLower() == "removehost")
            {

                if (args == null || args.Length != 2)
                {
                    FiddlerApplication.UI.SetStatusText("Specify host to remove");
                    return false;
                }

                string host = args[1];

                FiddlerApplication.UI.actSelectSessionsWithRequestHeaderValue("Host", host);
                FiddlerApplication.UI.actRemoveSelectedSessions();
            }

            return true; 

        }


    }
}


As you can see from the source code above, whenever we want to perform actions against the Fiddler GUI, we use the Fiddler.FiddlerApplication.UI object. This object has got methods for working with the Fiddler GUI. The class Fiddler.FiddlerUtilities has utility methods against fiddler. To work against Sessions (the individual rows of the Capture), we can see we can work against the Session by implementing IAutoTamper. The signature of the methods of these interfaces usually gives us the information we need, so our interface implementations can implement the behaviors of each specified interface. In addition to visiting the Project Properties of the Class Library and ensuring that .NET 4 framework is targeted, check that the Post build actions does the following:

copy "$(TargetPath)" "%userprofile%\My Documents\Fiddler2\Scripts\$(TargetFilename)"

The post action will compile the Fiddler Extension inside the class library and copy the DLL file to the users documents folder and subfolder Fiddler2\scripts folder. This is the users personal Fiddler Extensions. If you want to make your Fiddler extension available to all users, copy the compiled DLL file into the Scripts folder where Fiddler is installed, usually the folder:

C:\Program Files (x86)\Fiddler2



This article shows how you can create Fiddler extensions. This powerful HTTP Debugging proxy tools for analyzing network traffic is excellent and is able to capture traffic from diverse sources as WCF services bound to HTTPS or HTTP protocols, to acting as a reverse proxy for capturing traffic from mobile devices and regular capture of HTTP(S) traffic from a web browser.

Saturday, 29 June 2013

Optimistic concurrency in Sql Server

This article will quickly describe how to enable optimistic concurrency in Sql Server. Optimistic concurrency is implemented in Sql Server through the use of row versioning and snapshots. Snapshots take two forms and both modes can be enabled. Snapshot isolation (SI) and Read Commited Snapshot Isolation (RCSI). To enable these two modes do the following (Example AdventureWorks2012):

ALTER DATABASE AdventureWorks2012
SET READ_COMMITTED_SNAPSHOT ON

ALTER DATABASE AdventureWorks2012
SET ALLOW_SNAPSHOT_ISOLATION ON

To check the status of your databases to see if these two flags are enabled:

SELECT DATABASE_ID,
NAME,
SNAPSHOT_ISOLATION_STATE_DESC,
IS_READ_COMMITTED_SNAPSHOT_ON
FROM sys.databases
For example, on my database, running this script returned the following: The column SNAPSHOT_ISOLATION_DESC concerns SI (Snapshot Isolation) and can take the following values:
  • IN_TRANSITION_TO_OFF
  • OFF
  • ON
  • IN_TRANSITION_TO_ON
  • OFF
The reason for having four states and not just two is that this command can take long time and a DBA can be blocked by running transactions in progress. To enable RCSI, a DBA must usually have exclusive access to the database and therefore no transactions in progress. The column READ_COMMITTED_SNAPSHOT_ON can have the values 0 or 1, where 0 means it is disabled and 1 means it is off. Make note that the database tempdb is created, if you have not enabled SI (and/or) RCSI earlier for your database instance. This database keeps the version history required to make snapshots work.

Saturday, 1 June 2013

Implementing a generic Singleton in C#

This article will present the necessary code to implement a generic Singleton class in C#. Singletons are implemented in code, where you want to be sure there is one and only one instance of an object. An alternative is static classes, but static classes can only contain static methods and static properties / fields. Often your class be a non-static class, and in some contexts it is desired to be sure there is only one instance. There are some help in Inversion of Control (IoC) such as MEF to create a singleton (PartCreationPolicy.Shared), but sooner or later a need for creating a singleton is present. Let us first review the code for the generic singleton:

    public class Singleton<T> where T : new()
    {
        private static readonly T instance;

        static Singleton()
        {
            instance = new T();
        }

        public static T Instance
        {
            get { return instance; }
        }

        private Singleton()
        {

        }

    }

The Singleton Instance property is static and returns the private static readonly instance field of type T. It is important that the Instance property is returning the same instance here obviously, which is why we do not have a setter on this property. We constrain the Singleton class to have the generic constraint new, such that we can easily instantiate the object of type T. As you can see, we do not support specifying an overloaded constructor on the object of type T here. Without the use of the new generic constraint, one would have to instantiation via Activator.CreateInstance or some other means. In addition, we add a private default constructor, we do not want consumers to instantiate new Singleton objects of this class. For a demonstration of this, let us take this sample class, with a simple derived class:

    public class ProgramManager
    {
        private Guid guid;

        public ProgramManager()
        {
            guid = Guid.NewGuid();
        }

        public void PrintGuid()
        {
            Console.WriteLine("Guid is:" + guid);
        }

    }
 
    public class OperationManager : ProgramManager
    {



    }

I have created these three classes in a simple console application, this is how the running demo looks like:

            var programManager = Singleton<ProgramManager>.Instance;
            var secondProgramManager = Singleton<ProgramManager>.Instance;
            var operationManager = Singleton<OperationManager>.Instance;
            var secondOperationManager = Singleton<OperationManager>.Instance;
            programManager.PrintGuid();
            secondProgramManager.PrintGuid();
            operationManager.PrintGuid();
            secondOperationManager.PrintGuid();
            Console.WriteLine("Press any key to continue ..."); 
            Console.ReadKey(); 

The output is:

Guid is:842edf61-56c7-4916-a766-783e911361c8
Guid is:842edf61-56c7-4916-a766-783e911361c8
Guid is:987a113e-c664-4681-b9fb-6d463768327a
Guid is:987a113e-c664-4681-b9fb-6d463768327a
Press any key to continue ... .


Of course, the guids above will differ for each execution of the console application, but note that we got the same Guid in both cases for the two different classes. Our Singleton<T> Instance property always returns the same object, and keeps via the generic type argument separate instances of the Singleton generic instance demonstrated here. This shows this generic Singleton class can be used for many different scenarios. One feature I would like to add is the possibility to specify which constructor to call in the instantiation of the object of type T. I have not found a correct way to implement this yet using the code above.

Sunday, 26 May 2013

Creating a WCF ServiceBehavior to enforce HTTPS

The following code will enforce your WCF Services to use HTTPS:

using System;
using System.ServiceModel;
using System.ServiceModel.Description;

namespace TestHttpsRequiredServiceBehavior
{

    public class RequireHttpsServiceBehavior : Attribute, IServiceBehavior
    {

        public void AddBindingParameters(ServiceDescription serviceDescription, System.ServiceModel.ServiceHostBase serviceHostBase, System.Collections.ObjectModel.Collection endpoints, System.ServiceModel.Channels.BindingParameterCollection bindingParameters)
        {
        }

        public void ApplyDispatchBehavior(ServiceDescription serviceDescription, System.ServiceModel.ServiceHostBase serviceHostBase)
        {
        }

        public void Validate(ServiceDescription serviceDescription, System.ServiceModel.ServiceHostBase serviceHostBase)
        {
            foreach (var se in serviceDescription.Endpoints)
            {
                if (string.Compare(se.Binding.Scheme, "https", true) != 0)
                    throw new FaultException("This service requires HTTPS!");
            }
        }

    }
}

The WCF services you can create can then apply this WCF ServiceBehavior using an attribute on the WCF Service implementation class:

  [RequireHttpsServiceBehavior]
    public class Service1 : IService1
    {
        public string GetData(int value)
        {
..

Of course, you have to enable HTTPS also on your machine and set up your Visual Studio solution consuming the WCF service to use HTTPS.

Monday, 13 May 2013

Creating an assembly aware DataContractResolver in WCF

If you have coded some in WCF, you will sooner or later have experienced the issue where you want to derive a data contract and create a WCF service with an operation that returns a base class, but the WCF service in fact can return derived classes. In any case, when you use inheritance with data contracts, there are issues around the serialization and deserialization. The solution for now has been to decorate the base class with the KnownTypeAttribute of all the derived classes that should be supported. Clearly, this strategy only works in the simplest scenarios and sooner or later you will have runtime exceptions while serializing and deserializing as the WCF service operations execute. A solution to this, is to create a custom DataContractResolver. This custom object will inherit from the DataContractResolver and customize the serialization and deserialization process. For this to work, you will have to set the DataContractResolver on WCF operations and make the necessary adjustments both on the serverside and the clientside. I have created a custom ServiceHostFactory that sets the DataContractResolver for all WCF operations for all endpoints. For some scenarios, this is not desired, but the source code shows how we can globally apply this DataContractResolver to all WCF operations. The ServiceHostFactory is called WebEnabledServiceHostFactory and looks like this:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Reflection;
using System.ServiceModel;
using System.ServiceModel.Activation;
using System.ServiceModel.Description;
using System.Web;

namespace TestServiceHostFactory.IIS
{

    public class WebEnabledServiceHostFactory : ServiceHostFactory
    {

        private static readonly object _locker = new object(); 

        private static Dictionary _serviceLookup = new Dictionary();

        private static readonly string _dataContractAssemblyName = "Types";

        private static Assembly _dataContractAssembly;

        private static AssemblyAwareDataContractResolver _dataContractResolver;

        static WebEnabledServiceHostFactory()
        {
            lock (_locker)
            {
                _serviceLookup.Add(typeof(ICalculatorService), typeof(CalculatorService));
                _serviceLookup.Add(typeof(ICustomerService), typeof(CustomerService)); 
            }
        }

        protected override ServiceHost CreateServiceHost(Type serviceType, Uri[] baseAddresses)
        {
            ServiceHost host = new ServiceHost(_serviceLookup[serviceType], baseAddresses);

            ServiceEndpoint endpoint = host.AddServiceEndpoint(serviceType, new WebHttpBinding(), "web");
            ServiceEndpoint endpointWs = host.AddServiceEndpoint(serviceType, new WSHttpBinding(), "ws"); 

            endpoint.EndpointBehaviors.Add(new WebHttpBehavior());

            ServiceMetadataBehavior smb = new ServiceMetadataBehavior { HttpGetEnabled = true };
            host.Description.Behaviors.Add(smb);

            foreach (ServiceEndpoint serviceEndpoint in host.Description.Endpoints)
            {
                foreach (OperationDescription operation in serviceEndpoint.Contract.Operations)
                {
                    DataContractSerializerOperationBehavior serializerBehavior = operation.OperationBehaviors
                        .OfType<DataContractSerializerOperationBehavior>().FirstOrDefault();
                    
                    if (serializerBehavior == null)
                    {
                        serializerBehavior = new DataContractSerializerOperationBehavior(operation);
                        operation.OperationBehaviors.Add(serializerBehavior); 
                    }

                    if (_dataContractAssembly == null)
                        _dataContractAssembly = Assembly.Load(_dataContractAssemblyName);

                    if (_dataContractResolver == null)
                        _dataContractResolver = new AssemblyAwareDataContractResolver(_dataContractAssembly); 
                   
                    serializerBehavior.DataContractResolver = _dataContractResolver;

                }
            }

            return host;
        }

    }

}

This WCF ServiceHostFactory derived class both supports web operations and sets a custom DataContractResolver, AssemblyAwareDataContractResolver. This data contract resolver is assembly aware, i.e. it can traverse an assembly, look for all types (classes), decorated with the DataContract attribute, signifying that this class is a data contract. As you can see in the ServiceHostFactory code above, we loop through all the WCF endpoints, then loop through all the operations (OperationDescription) inside the Contract property of the Endpoint, next we look at the OperationBehaviors if there is already added a DataContractSerializerOperationBehavior and if not, we add such an object. We finally specify the DataContractResolver of this behavior which we set to our custom AssemblyAwareDataContractResolver. Note that we add the assembly in the constructor to this object. We know in this special case that the assembly is in the Types project. An alternative would be to expose a public property for example to set the name of the assembly (i.e. project), where the assembly resides. Another alternative would be to support multiple assemblies where data contracts will reside. For most cases, most developers has got their data contracts set up in a Common project and assembly, along with Service Contracts. Let's look at the source code of AssemblyAwareDataContractResolver next:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Reflection;
using System.Runtime.Serialization;
using System.Web;
using System.Xml;
using System.Collections.Concurrent;
using System.Text;
using System.Diagnostics;
using System.IO;

namespace TestServiceHostFactory.IIS
{

    public class AssemblyAwareDataContractResolver : DataContractResolver
    {

        private ConcurrentDictionary dictionary = new ConcurrentDictionary(); 

        private Assembly assembly;

        public AssemblyAwareDataContractResolver(Assembly assembly)
        {
            this.assembly = assembly;
            FamiliarizeWithDataContracts(assembly); 
        }

        private void FamiliarizeWithDataContracts(Assembly assembly)
        {
            DataContractSerializer serializer = new DataContractSerializer(typeof(Object), null, int.MaxValue, false, true, null,
                       this);
            StringBuilder stringBuilder = new StringBuilder();

            foreach (Type type in assembly.GetTypes())
            {
                SerializeDataType(serializer, stringBuilder, type);
            }

            //foreach (Type type in assembly.GetTypes())
            //{
            //    SerializeDataType(serializer, stringBuilder, type);
            //    DeserializeDataType(serializer, stringBuilder);

            //}
        }


        //private static void DeserializeDataType(DataContractSerializer serializer, StringBuilder stringBuilder)
        //{
        //    string serialized = stringBuilder.ToString();

        //    using (XmlReader xmlReader = XmlReader.Create(new StringReader(serialized)))
        //    {
        //        object deSerialized = serializer.ReadObject(xmlReader);
        //    }
        //}


        private static void SerializeDataType(DataContractSerializer serializer, StringBuilder stringBuilder, Type type)
        {
            if (type.GetCustomAttributes().Count() > 0)
            {
                var dataContract = Activator.CreateInstance(type);
                using (XmlWriter xmlWriter = XmlWriter.Create(stringBuilder))
                {
                    try
                    {
                        serializer.WriteObject(xmlWriter, dataContract);
                    }
                    catch (SerializationException se)
                    {
                        Debug.WriteLine(se.Message);
                    }
                }

                Debug.WriteLine(stringBuilder.ToString());

            }
        }

        /// 
        /// Serialization will use this overload
        /// 
        public override bool TryResolveType(Type type, Type declaredType, DataContractResolver knownTypeResolver, out XmlDictionaryString typeName, out XmlDictionaryString typeNamespace)
        {
            string name = type.Name;
            string namesp = type.Namespace;

            typeName = new XmlDictionaryString(XmlDictionary.Empty, name, 0);
            typeNamespace = new XmlDictionaryString(XmlDictionary.Empty, namesp, 0);

            if (!dictionary.ContainsKey(type.Name))
                dictionary.TryAdd(name, typeName);

            if (!dictionary.ContainsKey(type.Namespace))
                dictionary.TryAdd(namesp, typeNamespace);

            return true;
        }

        /// 
        /// Deserialization will use this overload 
        /// 
        public override Type ResolveName(string typeName, string typeNamespace, Type declaredType, DataContractResolver knownTypeResolver)
        {
            XmlDictionaryString tName;
            XmlDictionaryString tNamespace;

            if (dictionary.TryGetValue(typeName, out tName) && dictionary.TryGetValue(typeNamespace, out tNamespace))
                return this.assembly.GetType(tNamespace.Value + "." + tName.Value);
            else
                return null;         
        }

    }
}

Make note that we familiarize the AssemblyAwareDataContractResolver by looping through all types and serialize them (default types and classes), using Activator.CreateInstance and serialize the object. This is done to set up a dictionary data structure (from the Concurrent assembly). Of course, this will have some overhead, which is why we use the same AssemblyAwareDataContractResolver instance in the ServiceHostFactory for quick serialization and deserialization, once inited. You can also see that we derive from the DataContractResolver class and override ResolveName (used during deserialization) and TryResolveType (used during serialization). Next, we need some service to test out WCF with these new capabilities. Lets first look at the data contracts involved in the Types project (class library):

using System.Runtime.Serialization;


namespace Types
{

    [DataContract]
    public class Customer
    {

        [DataMember]
        public string Name { get; set; }
    
    }

    [DataContract]
    public class RegularCustomer : Customer
    {

    }

    [DataContract]
    public class VIPCustomer : Customer
    {

        [DataMember]
        public string VipInfo { get; set; }

        [DataMember]
        public Customer Attache { get; set; }
    }

    [DataContract]
    public class PreferredVIPCustomer : VIPCustomer
    {

    }

}


Make note we have inheritance here of our data contracts, and that we have not set the KnownType attribute on the base class for the derived classes. After all, we want our WCF service to be assembly aware, right? Let's define a service contract next. This resides in the WCF service application, but should be moved to the Types project.

using System.ServiceModel;
using System.ServiceModel.Web;
using Types;

namespace TestServiceHostFactory.IIS
{

    [ServiceContract(Namespace = "http://www.foo.bar.com")]
    public interface ICustomerService
    {

        [OperationContract]
        [WebGet] 
        Customer GetCustomer(string name);

    }

}

The implementation is in the same project, CustomerService:

using Types;

namespace TestServiceHostFactory.IIS
{

    public class CustomerService : ICustomerService
    {

        public Customer GetCustomer(string name)
        {
            if (!name.Contains("VIP"))
                return new Customer { Name = name };
            else
            {
                var result = new VIPCustomer { Name = name, VipInfo = "VIP: " + name, Attache = new Customer { Name = "Geoffrey" } };
                return result;
            }
        }

    }

}

We also need a Customer.svc file to expose our service:

<% @ ServiceHost Language="C#" Service="TestServiceHostFactory.IIS.ICustomerService" Factory="TestServiceHostFactory.IIS.WebEnabledServiceHostFactory" %>

The <system.serviceModel> section of the web config file in this example is empty, as the complexity of setting up endpoints and behaviors are taken care of in the custom service host. The next step is to connect to this WCF CustomerService and check that the automatic resolution of inheritance in the data contracts of the assembly Types is taken care of with our custom (AssemblyAware)DataContractResolver. I have created a simple console project with a main method inside where I put the client initialization code and the set up a channel factory to communicate with the service. I know the endpoint to go against.

using System;
using System.Linq;
using System.Reflection;
using System.ServiceModel;
using System.ServiceModel.Description;
using TestServiceHostFactory.IIS;

namespace TestServiceHostFactory.Client
{
    class Program
    {
        static void Main(string[] args)
        {

            WSHttpBinding binding = new WSHttpBinding();
            EndpointAddress endpoint = new EndpointAddress("http://localhost:51229/Customer.svc/ws");

            ChannelFactory customerService = new ChannelFactory(binding, endpoint);

            Assembly dataContractAssembly = Assembly.Load("Types");

            foreach (var operationDescription in customerService.Endpoint.Contract.Operations)
            {
                var serializerBehavior = operationDescription.OperationBehaviors.OfType<DataContractSerializerOperationBehavior>().FirstOrDefault();
                if (serializerBehavior == null)
                {
                    serializerBehavior = new DataContractSerializerOperationBehavior(operationDescription);
                    operationDescription.OperationBehaviors.Add(serializerBehavior);
                }
                serializerBehavior.DataContractResolver = new AssemblyAwareDataContractResolver(dataContractAssembly);
            }

            ICustomerService c = customerService.CreateChannel();

            var cust = c.GetCustomer("VIP Tore Aurstad");

            Console.WriteLine("Press any key to continue ...");
            Console.ReadKey();
        }

    }
}

I set up a binding instance of type WsHttpBinding (since this must match the .AddServiceEndPoint calls defined on the ServiceHost on the server side, which is performed inside the WebEnabledServiceHostFactory), and create an Endpoint with an address, which matches the address set up of the Service Application project set up. To see this url, choose a WCF service application project, right click and select properties and click on the Web tab pane and look at the Project Url, where the port number should be described. I create a new ChannelFactory to go against the ICustomerService WCF service (interface). Also note that the client side must have set up its corresponding AssemblyAwareDataContractResolver. You will want to reuse the same object for and not instantiate it as I have done here, for efficiency reasons, after all - remember the FamiliarizeWithDataContract call. For this demonstration, I have not done this optimization. We then use the CreateChannel method of the ChannelFactory and create the connection between the client and the server. Now we can call the WCF operation GetCustomer. We pass in the string "VIP Tore Aurstad", and if you look at the logic, this will return a VIPCustomer object. This is a derived class of the Customer data contract type. Although we have not specified KnownType attribute, we still avoid runtime crash, since our DataContractResolver is now assembly aware. To sum up, from .NET Framework version 4.0, WCF offers you to take control of how DataContracts are resolved during serialization and deserialization. If you have a project (class library) with many data contracts, you should consider using a class hierarchy to reduce the number of classes used for data contracts. Many developers avoid inheritance in data contracts that are used with WCF, because of the costs around maintaining the KnownType attributes. In fact, many developers are not sure what to do when they encounter these runtime exceptions in the first place. By taking your time to implement an assembly aware DataContractResolver, you are reducing a maintenance cost around adding KnownType to your data contracts. Of course, this means you must have an efficient implementation of this. Note what I said about the client code needs to keep a reference to the instance of AssemblyAwareDataContractResolver when you loop through endpoints and operations. For this simple implementation, this issue did not matter. It is expected that the FamiliarizeWithDataContract method is quick enough, but you should consider parallelizing it further to register the serializing data ccontracts. If you extract the client code above into a ChannelManager or similar, you can cache this object into a static variable, such that the overhead is mminimal. This cost compared to the reduced maintenance cost of inheritance and KnownType should be worth the effort. In addition, by better supporting inheritance with data contracts, you should be able to design better class hierarchies for your data contracts and implement DRY in your data contracts.

Sunday, 12 May 2013

Creating a web enabled service via ServiceHostfactory in WCF

This article will explain how a service host factory can create a webenabled service in WCF. Obviously, you should consider extending this ServiceHostFactory to consider security and other extensions to it. Start by creating a WCF Service Application in Visual Studio. Add references to System.ServiceModel, System.ServiceModel.Web and System.ServiceModel.Activation. Let's first look at the ServiceHostFactory class itself:

    public class WebEnabledServiceHostFactory : ServiceHostFactory
    {

        private static readonly object locker = new object(); 

        private static Dictionary serviceLookup = new Dictionary();

        static WebEnabledServiceHostFactory()
        {
            lock (locker){
             serviceLookup.Add(typeof(ICalculatorService), typeof(CalculatorService));
            }
        }

        protected override ServiceHost CreateServiceHost(Type serviceType, Uri[] baseAddresses)
        {
            ServiceHost host = new ServiceHost(serviceLookup[serviceType], baseAddresses);

            ServiceEndpoint endpoint = host.AddServiceEndpoint(serviceType, new WebHttpBinding(), "web");

            endpoint.EndpointBehaviors.Add(new WebHttpBehavior());

            ServiceMetadataBehavior smb = new ServiceMetadataBehavior { HttpGetEnabled = true };
            host.Description.Behaviors.Add(smb);

            return host;
        }

    }

This ServiceHostFactory class derived from the base class ServiceHostFactory. It just overrides the CreateServiceHost method and adds a service endpoint with the AddServiceEndPoint method of ServiceHost and uses the WebHttpBinding. A ServiceEndPoint instance is returned by this method and we add the WebHttpBehavior to the endpoint. In addition, we add a ServiceMetdataBehavior to the host.Description.Behaviors property of the ServiceHost with HttpGetEnabled set to true, so we get the familiar testpage of the .svc file in a web browser. Note that we use a simple static dictionary for reading the mapping between the service contract and its implementation class. Let's then add a simple service contract:

    [ServiceContract(Namespace = "http://www.foo.bar.com")]
    public interface ICalculatorService
    {

        [OperationContract]
        [WebGet]
        double Subtract(double x, double y);

        [OperationContract]
        [WebGet] 
        double Add(double x, double y);

    }

Note that we not only have specified the method of the ServiceContract as using OperationContract, but we also decorate the method with the WebGet attribute to support WCF Web programming model (i.e. consuming the WCF Service via HTTP + Web browser) The WCF implementation of this interface and WCF service contract is done next:

    public class CalculatorService : ICalculatorService
    {
        public double Subtract(double x, double y)
        {
            return x - y;
        }

        public double Add(double x, double y)
        {
            return x + y;
        }
    }

Add a svc file called Calculator.svc next, specifying the calculator service and the custom ServiceHostFactory above:

<% @ ServiceHost Language="C#" Service="TestServiceHostFactory.IIS.CalculatorService" Factory="TestServiceHostFactory.IIS.WebEnabledServiceHostFactory" %>

Note that the endpoint in the service host defines the end point with an address of "web", when we right click the Calculator.svc file the file is opened in a web browser with a generated address, with a random port assigned. When I right click the Calculator.svc file, the following URL was used in this example: http://localhost:51229/Calculator.svc To for example call the Subtract method of the ICalculatorService, we use the following URL in the web browser: http://localhost:51229/Calculator.svc/web/Subtract?x=12&y=3 This returns the following result: <double>9<double> In case JSON is the desired ResponseFormat, just change the signature of the ServiceContract classes to specify this, for example:
        [OperationContract]
        [WebGet(ResponseFormat=WebMessageFormat.Json)]
        double Subtract(double x, double y);
In this example, the result will just the number 9. If objects are returned, JSON object syntax will be returned. Our web.config has an empty block for <system.serviceModel>
 <system.serviceModel>
 </system.serviceModel>
This shows that we can auto-configure web services as desired in for multiple WCF services using a ServiceHostFactory and setting up bindings and behaviors out-of-the box. This reduces complexity and configuration that has to go into web.config and the <system.serviceModel> section, which specifies WCF. In addition, if you want to add WCF services that are web-enabled out-of-the box, the code above can be a starting point.

Sunday, 5 May 2013

Accessing WCF service that is REST-enabled in a web browser

Developers using WCF most often will expose and consume these services in intranet business applications. But sometimes, it is desired to expose services through a web browser.

To expose a WCF service to a web browser, it is possible to do this using the WCF web programming model, based upon the ideas of REST (Representational State Transfer). This article will show how this can be achieved in WCF, using some easy adjustments. Make note that it is possible to allow both a traditional access and web based access, it boils down to activating and adding the necessary endpoints.

First off, let us take the default WCF Service Library template as a starter point.


    public class Service1 : IService1
    {

        [WebGet(UriTemplate="GetData?value={value}")] 
        public string GetData(int value)
        {
            return string.Format("You entered: {0}", value);
        }

        ..

    }

The difference between the code above and the one in the template, is that the service method implementation class Service1 is attributed with the WebGet attribute. In addition, an UriTemplate is added. The WebGet attribute is used to support HTTP GET operations. To use the POST, PUT or DELETE operation in HTTP, use the HttpInvoke attribute. To be able to use this WCF HTTP Programming model you not only have to add a reference to the System.ServiceModel assembly, but also System.ServiceModel.Web assembly. In addition, add the following using statement:
using System.ServiceModel.Web;
Next, some changes must be done in the configuration files for the project where WCF service is located. Open the web.config (or app.config) of the project containing the WCF service. Check that you have the following in the system.servicemodel section:

<system.serviceModel>
    <services>
      <service name="HelloWorldWCFService.Service1">
        <host>
          <baseAddresses>
            <add baseAddress = "http://localhost:8734/Service1/" />
          </baseAddresses>
        </host>
        <!-- Service Endpoints -->
        <!-- Unless fully qualified, address is relative to base address supplied above -->
        <endpoint address="" binding="basicHttpBinding" contract="HelloWorldWCFService.IService1">
          <!-- 
              Upon deployment, the following identity element should be removed or replaced to reflect the 
              identity under which the deployed service runs.  If removed, WCF will infer an appropriate identity 
              automatically.
          -->
          <identity>
            <dns value="localhost"/>
          </identity>
        </endpoint>
        <endpoint address="http://localhost:8733/Service1/mex" binding="mexHttpBinding" contract="IMetadataExchange"  /> 
        <endpoint address="net.tcp://localhost:8080/Service1" binding="netTcpBinding" contract="HelloWorldWCFService.IService1" />
       
        <endpoint address="http://localhost:8734/Service1/Web/" binding="webHttpBinding" contract="HelloWorldWCFService.IService1" behaviorConfiguration="webBehaviorConfig" />
        
        <!-- Metadata Endpoints -->
        <!-- The Metadata Exchange endpoint is used by the service to describe itself to clients. --> 
        <!-- This endpoint does not use a secure binding and should be secured or removed before deployment -->
        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
        
       
      </service>
    </services>
    <behaviors>
      <endpointBehaviors>
        <behavior name="webBehaviorConfig">
          <webHttp />
        </behavior>
      </endpointBehaviors>
      <serviceBehaviors>

        <behavior>
          <!-- To avoid disclosing metadata information, 
          set the values below to false before deployment -->
          <serviceMetadata httpGetEnabled="True" httpsGetEnabled="True"/>
          <!-- To receive exception details in faults for debugging purposes, 
          set the value below to true.  Set to false before deployment 
          to avoid disclosing exception information -->
          <serviceDebug includeExceptionDetailInFaults="False" />
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>


That was a lot of config. In fact what is key to note here is just that we add an endpoint that has the webHttpBinding endpoint. The address is the URL that will be used to access the service, as the prefix combined with the UriTemplate of each WCF operation that is exposed. In addition, the endpointBehaviors element is added with a behavior where we give it a name and add the webHttp element. Also, note that the attributes httpGetEnabled and httpsGetEnabled is set on the serviceMetadata element. To access the web-enabled WCF service in this example, open a web browser and enter the following URL:
http://localhost:8734/Service1/Web/GetData?value=42


The returned data is in the form of an XML, which is the default output format. It is possible to change the output format into JSON for example, to integrate the data returned with Javascript and Ajax in modern web browsers.
This will give you a start to test out accessing the WCF service through a web browser. Of course, when exposing WCF service on the web, security considerations should be taken. Most often, it comes down to what should be done when a new attack vector is made available. Obviously, more often than not, you will want to limit which users can access the web service. In addition, the service should not expose sensitive data, without security considerations. There are also limits in which data can be passed in an URL. When you use the WebInvoke attribute, more complex objects can be passed into a service, but still, the object being passed in must be serializable into an XML.

Also note that the UriTemplate must match the naming of the parameters to the WCF method. There are limitations to which data types can be passed in a query string. An explanation of the format one must follow when it is required to pass, say a DateTime, check out the following MSDN article:
WCF Web HTTP Programming Model Overview

It is easy to change the output from XML to JSON.

We will now look at calling the same WCF Method used above through jQuery and its $.ajax method. First, change the signature of the WCF service:
        [WebInvoke(ResponseFormat=WebMessageFormat.Json, BodyStyle=WebMessageBodyStyle.Wrapped)] 
        public string GetData(int value)
        {
            return string.Format("You entered: {0}", value);
        }
Note that we do not specify the Method property of WebInvoke, which defaults to POST verb of HTTP. We have also changed from WebGet to WebInvoke. Next, adding a MVC 4 application to act as a client, add the following code to your global.asax code behind file (Global.asax.cs) in this project:
     
        protected void Application_BeginRequest(object sender, EventArgs e)
        {

            HttpContext.Current.Response.AddHeader("Access-Control-Allow-Origin", "http://localhost:*/");

            if (HttpContext.Current.Request.HttpMethod == "OPTIONS")
            {
                HttpContext.Current.Response.AddHeader("Cache-Control", "no-cache");
                HttpContext.Current.Response.AddHeader("Access-Control-Allow-Methods", "GET, POST");
                HttpContext.Current.Response.AddHeader("Access-Control-Allow-Headers", "Content-Type, Accept");
                HttpContext.Current.Response.AddHeader("Access-Control-Max-Age", "1728000");
                HttpContext.Current.Response.End();
            }
        }

The code above is to added to fix compability issues in Chrome and Firefox to allow Ajax calls to the WCF service (IE did not need this fix). Add the following content to the Index.cshtml file of the added MVC Project:
  <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.7.0/jquery.min.js"></script>

    <script type="text/javascript">

        function testPosting() {

            jQuery.support.cors = true;

            var enteredValue = $("#txtValue").val();
            var data = { value: enteredValue };

            var payload = JSON.stringify(data);

            $.ajax({
                type: 'POST',
                url: 'http://localhost:8734/Service1/Web/GetData',
                contentType: 'application/json',
                dataType: 'text',
                data: payload,
                error: function (request, status, error) {
                    alert(request.responseText + " " + status + " " + error);
                },
                success: function (msg) {
                    var result = JSON.parse(msg);
                    console.log(result);
                    $("#results").append(result.GetDataResult + "<br />");
                }
            });

        }

    </script> 
Adding jquery above is not necessary, since the MVC template has already added this. Next, a method called testPosting is added. Here, a call to the $.ajax method is added. The $.ajax metod specifies the url of the WCF service. Also note that the service should be on the same server and preferably the same port to avoid security issues. Of course, your service can access remote servers in its code. This means that the Web Application and the WCF Service preferably should be installed on the same server. Cross-domain scripts are usually disallowed in web browsers today. But the option for your WCF services to access remote servers is of course not affected by this limitation. The dataType is set to 'text', but it could be 'json'. Instead, the json is parsed in the success callback. Further on, the name of the argument of your WCF method must match the constructed json object being passed into the method.


We need a simple GUI also to test the combination of WCF, REST, Ajax and JSON (GUI below is just a mockup in Google Blogger):
 

Enter an integer:



The code in the Global.asax.cs file was obtained by reading this article: Method 405 fix for WCF

This shows that WCF services can provide XML, JSON, Ajax and REST capabilities and not just be an intranet web services provider, as its typical use. Of course, often WCF will feel a bit heavy weight when all you want is to expose web services to your Clients. But again, often you want to create Intranet style web applications too, where you want some of your services and their methods provide web access. This will make it easier to use existing WCF services hosted in IIS through for example WAS to be utilized by mobile clients. The information which these methods of your WCF services will usually be services that are not sensitive, or else one has to provide security mechanisms around the web access. One possible way of adding security is to provide a token or similar information in the JSON payload being sent over to the server. If the WCF service verfies the token sent in, the information will then be sent back again to the client. For example, the client could log in to a web application which uses a Security Token Service or similar to log in. If WIF is used, the client will get a FedAuthCookie as a certification of a valid user. The user can then relay the necessary information over to the WCF Rest-enabled service to inspect the users claims or similar. One could use a digital signature or similar. I will look at WCF REST security tokens and related topics in the near future. The level of security will be lower than what is possible in many other types of bindings being used in WCF such as wsFederationBinding or similar.

This article shows that WCF can be used in many web scenarios. I have not touched the topics of WebServiceHost and calling the REST-enabled services through code and not JavaScript. If you want a web-enabled WCF service, chances are higher that you want to reach the WCF service through jQuery + Ajax or similar using JSON as information interchange format. There are a multitude of topics to cover here and the developer should be aware that it is a learning curve to start using WCF for the web.

Friday, 5 April 2013

Stopping a process with Powershell and the Out-GridView

Powershell can display a nice menu where the user can select e.g. a single or a multiple element in an arbitrary gridview, with the cmdlet Out-GridView. Let's see how this can be done to support stopping a single process of which the user chooses to stop. Of course, this is already available in Task Manager, but it is always nice to see that Powershell can give us a dedicated way of doing this also.

Here is the script for doing this, in the function Stop-SelectedProcess:

            
function Stop-SelectedProcess(){            
            
    Write-Host Select the process to stop ...            
    Start-Sleep 2            
                
    $selectedProcess = $null             
    Get-Process | Out-GridView -OutputMode Single -Outvariable selectedProcess            
                
    if ($selectedProcess -eq $null -or $selectedProcess.Count -eq 0)             
    {            
        return;            
    }             
            
    Stop-Process $selectedProcess            
            
}            
            
Stop-SelectedProcess
Make note how the Out-GridView cmdlet which we pipe the result from Get-Process to is specified to have an -OutputMode of single (i.e. choose one item at a time)and a -OutVariable also set, also note the missing $-sign after -OutVariable, this is correct. This shows how we can present the user with a nice menu to choose for while running the command. This is easier than asking the user to select a process to stop by e.g. PID or #-line number.

This is just another example of how modern as a scripting language Powershell really is.

Word of caution at the end - never stop a process you are not sure of what runs. I stopped the process smss process the other day, because I thought it was Sql Management Studio. Needless to say, I experienced my first BSOD in Windows 8 ..

Screenshot of the action:

Thursday, 4 April 2013

Dynamic modules in Powershell as objects

This article will show how dynamic modules can act as objects for Powershell. With this technique, it is possible to create object definitions in Powershell if you want more object orientation for your scripts. Let's first look at the Manifest file for the dynamic module. The file modasobj.psd1 contains the following:

#Module manifest for module 'modasobj            
#Generated by: Tore Aurstad            
            
@{            
ModuleVersion = '1.0'            
Guid = 'C9B7488B-507C-470C-B93E-6B040A5EF2AC'            
Author='Tore Aurstad'            
Description='Demonstrates use of modules as objects'            
            
ScriptsToProcess = @('modasobj.ps1')            
            
}
The manifest file will always have the name MODULENAME.psd1, where MODULENAME is the folder name under one of your $env:psmodulepath folders. As we see, we define the Guid, Author, Description and ModuleVersion. For non-dynamic modules, we specify more properties in the hashtable of our manifest .psd1 file for our Powershell modules. An overview of the manifest properties to set is here:

How to write a module manifest
We define our module as objects definitions in the other file, modasobj.ps1
function New-Address {            
            
 New-Module -AsCustomObject -Name Address {            
    $House = $null            
    $Street = $null            
    $Town = $null            
    $County = $null            
    $Country = $null            
    $PostCode = $null             
            
    Export-ModuleMember -Variable *            
            
 }            
            
}            
            
function New-Person {            
 New-Module -AsCustomObject -Name Person {            
    $Name = $null            
    $Address = $null            
    $Occupation = $null             
    $Age = $null            
    $NiNo = $null              
            
    Export-ModuleMember -Variable *            
            
  }            
            
}
Here we see the use of New-Module cmdlet, followed by the flag -AsCustomObject and the -Name flag followed by the name of the custom object we want to create. To play around with this object, we can just create a new Person object and set its address to be an Address object. Some output of this follows.


PS C:\users> import-module modasobj -verbose -force
VERBOSE: Loading module from path 'C:\Users\Tore Aurstad\Documents\WindowsPowerShell\Modules\modasobj\modasobj.psd1'.
VERBOSE: Loading module from path 'C:\Users\Tore Aurstad\Documents\WindowsPowerShell\Modules\modasobj\modasobj.ps1'.
VERBOSE: Dot-sourcing the script file 'C:\Users\Tore
Aurstad\Documents\WindowsPowerShell\Modules\modasobj\modasobj.ps1'.
PS C:\users> $me = New-Person
PS C:\users> $me


Address    :
Age        :
Name       :
NiNo       :
Occupation :

PS C:\users> $me.Age = 34
PS C:\users> $me.Name = 'Tore Aurstad'
PS C:\users> $me.Occupation = 'System Developer'
PS C:\users> $me.Occupation = 'Systems Developer'
PS C:\users> $me.Address = 'Kyavegen 1 7045 Trondheim'
PS C:\users> $me.Address.Country = 'Norway'
Property 'Country' cannot be found on this object; make sure it exists and is settable.
At line:1 char:1
+ $me.Address.Country = 'Norway'
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [], RuntimeException
    + FullyQualifiedErrorId : PropertyAssignmentException

PS C:\users> $me.Address.County = 'Sør-Trøndelag'
Property 'County' cannot be found on this object; make sure it exists and is settable.
At line:1 char:1
+ $me.Address.County = 'Sør-Trøndelag'
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [], RuntimeException
    + FullyQualifiedErrorId : PropertyAssignmentException

PS C:\users> $address = New-Address
PS C:\users> $me.Address = $address
PS C:\users> $address.Country = 'Norway'
PS C:\users> $me


Address    : @{Country=Norway; County=; House=; PostCode=; Street=; Town=}
Age        : 34
Name       : Tore Aurstad
NiNo       :
Occupation : Systems Developer

PS C:\users> $address.County = 'Sør-Trøndelag'
PS C:\users> $address.House = '1'
PS C:\users> $address.PostCode = '7045'
PS C:\users> $address.Street = 'Kyavegen'
PS C:\users> $address.Town = 'Trondheim'
PS C:\users> $me

Address    : @{Country=Norway; County=Sør-Trøndelag; House=1; PostCode=7045; Street=Kyavegen; Town=Trondheim}
Age        : 34
Name       : Tore Aurstad
NiNo       :
Occupation : Systems Developer

PS C:\users>

PS C:\users> $me.GetType()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     False    PSCustomObject                           System.Object


PS C:\users> $address.GetType()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     False    PSCustomObject                           System.Object


PS C:\users> $me | Get-Member


   TypeName: System.Management.Automation.PSCustomObject

Name        MemberType   Definition
----        ----------   ----------
Equals      Method       bool Equals(System.Object obj)
GetHashCode Method       int GetHashCode()
GetType     Method       type GetType()
ToString    Method       string ToString()
Address     NoteProperty System.Management.Automation.PSCustomObject Address=@{Country=Norway; County=Sør-Trøndelag...
Age         NoteProperty System.Int32 Age=34
Name        NoteProperty System.String Name=Tore Aurstad
NiNo        NoteProperty  NiNo=null
Occupation  NoteProperty System.String Occupation=Systems Developer


PS C:\users>

As you can see, I had to adjust above the way I was setting $me.Address properties by having to declare a new address object $address and set its properties to see the changes reflected in the parent object $me. Both objects are of type PSCustomObject. As we can see, when we pipe our object variable to the cmdlet Get-Member, we get a nice listing of our members and derived members. This shows how custom objects can be made inline in Powershell. Of course, Powershell can create objects easily with the New-Object cmdlet and by specifying a library object either in .NET or created by you, but this shows how you don't have to recompile and create an object specification or class, you can have Powershell create for you, with dynamic modules and the -AsCustomObject and -Name flags set inside the function. In addition, you need to use the cmdlet Export-ModuleMember-Property *, such that your properties are visible for consumers of the dynamic module.

If you want to remove the module again, use:
remove-module modasobj*

Modules are a huge topic and this article shows one of their many ways of being created.

Using Powershell to generate new Guids

Guids, or Globally Unique Identifiers, are often used by developers and others to attribute a unique id to an arbitrary object. For example, those who have used WiX to create MSI-based installers, often need to create a new GUID all the time while writing the WiX code for the installer. Wouldn't it be great to use a Powershell command line to just generate new GUIDs? Here is a sample script how to do this:

            
<#
    .SYNOPSIS
        Creates a new Guid object and displays its GUI to the screen
    .DESCRIPTION
        Uses static System.Guid.NewGuid() method to create a new Guid object
    .EXAMPLE
        1. Create a new Guid is easy:
        New-Guid
#>            
function New-Guid () {            
            
 [System.Guid] $guidObject = [System.Guid]::NewGuid()            
 [Windows.Forms.Clipboard]::Clear();            
 [Windows.Forms.Clipboard]::SetText($guidObject.Guid)            
 Write-Host $guidObject.Guid            
            
}            
            
New-Guid


To call the function New-Guid just type its name. You will get new GUIDs without a hassle:


PS C:\users\Tore Aurstad> New-Guid
0d2cc38f-e6de-4049-ae6a-f168bf1ea670

PS C:\users\Tore Aurstad> New-Guid
f99044b3-a8a6-4092-a520-c58ae259a19e

PS C:\users\Tore Aurstad> New-Guid
4de11003-8bbf-4415-8fe3-e7ecf4be9ee0

PS C:\users\Tore Aurstad> New-Guid
cac473e7-1f01-4d2f-b99c-4fdb25ab9da1

PS C:\users\Tore Aurstad> 



Of course, this is very similar to creating a Console application with C#, we just call the static method NewGuid on the Guid class. In Powershell, variables can be strongly typed as shown here and to call a static method you just write [MyNamespace.MyClass]::MyStaticMethod. Note the double colon marks in the middle.

In addition to generating a new Guid, the clipboard contents is set to the Guid value, which means you can paste in the text where you want. I did not have to import any additional modules to reach the static function [Windows.Forms.Clipboard]::Clear() and [Windows.Forms.Clipboard]::SetText().