RSS

Oracle ODP.NET provider and BLOBs over internet environment

Here’s a problem. If you run your queries in an environment where the DB and the .NET code are geographically close and the ping times are short, you are less likely to notice this issue. But when running them in totally different locations you may see very poor performance up to behavior which is impossible to work with.

To cut a long story short, after narrowing the problem down, the bad performance was unique to columns with LOB types. Googling this issue showed that this is due to Oracle’s ODP.NET provider. It seems like by default, ODP.NET will not fetch LOBs data by default but defer it until explicitly requested by the calling application.

Luckily, this behavior can be controlled by setting the InitialLOBFetchSize of the OracleCommand. By default it is set to 0 which means ‘defer’. You can set it to the number of bytes you would like to retrieve or simply to -1 to fetch it entirely. From the docs.

“By default, InitialLOBFetchSize is set to 0. If the InitialLOBFetchSize property value of the OracleCommand is left as 0, the entire LOB data retrieval is deferred until that data is explicitly requested by the application. If the InitialLOBFetchSize property is set to a nonzero value, the LOB data is immediately fetched up to the number of characters or bytes that the InitialLOBFetchSize property specifies.”

Read more here:

“When InitialLOBFetchSize is set to -1, the entire LOB data is prefetched and stored in the fetch array.”

Personally I think that the default should be exactly the opposite. It is the responsibility of the developer to include or exclude LOB columns in the SELECT clause. If the developer attempted a “SELECT *” he will notice the lag and will have to modify the query.

I also think that it is a shame that these properties must be set in code and cannot be tweaked in the config file.

Additional tips
Here are some additional tips. They do not relate to the obvious tips of fine tuning your queries or database, but to the amount of data is to be passed over the network.

  • There is also a InitialLONGFetchSize that you can set to -1 to allow prefetch of LONG and LONG RAW data types.
  • If you set the CommandTimeout property to 0, it will be infinite (that goes also for MySQL, SQLServer and DB2). You must take into consideration that setting the LOBFetchSize to -1 will solve just the prefetch problem but the data might still take a lot of time to be fetched. Also note that the different documentations do not recommend setting the timeout to infinite, but perhaps you should still increase it for queries that are supposed to retrieve lots of data.
  • You should also consider changing the Connection Timeout. This is usually done via the connection string. Consult http://www.connectionstrings.com how to do this.
  • Change your queries to retrieve not the entire table but explicit columns that you actually need.
 
Leave a comment

Posted by on 22/12/2013 in Software Development

 

Tags: , , ,

First attempt at AngularJS and ASP.NET’s PageMethods & WebMethods

If you need the example, right click this link, Save As and rename to zip.

I made a first attempt at AngularJS and was particularly interested in how I can use it alongside ASP.NET Ajax. The reason is because I am very fond of PageMethods and WebMethods for Ajax, as they are extremely simple and trivial to use. I know that just by writing this short introduction some AngularJS religious fans are shaking their heads in disagreement. That’s OK.

AngularJS seems nowadays like one of the hottest frameworks so I thought I to try it out. I did some reading (the AngularJS homepage shows really helpful examples), saw some videos and experimented a bit. My purpose: see if AngularJS can be good as a templating solution. Comparing to other solutions, what I really liked about AngularJS was that it is embedded within the html itself. Note: AngularJS is much more than “just templates” (the html is not just referred to as a collection of DOM elements but as The “View” in MV* architectures) – but that’s off topic. So in comparison for example to jsrender, which I’ve been using lately, AngularJS just integrates into the html, allowing you to manipulate it using JavaScript controllers. This is very convenient because your favorite editor will colorize everything as usual. That’s just a short description of one of the advantages. To be fair I lack the experience to describe the gazillions of advantages of AngularJS. But again, this is off topic.

What I am interested in is something that I will be comfortable working with, that will also be reliable and long lasting. Without going too much into details, there are many libraries, 3rd party controls and frameworks that failed to stand up to some or all of these requirements. Sometimes when you figure out that a library is not living up to standards, it might be after lots of your work was already written using it and it’ll be very difficult or even impossible to back out. Then you have to start working around problems and this could be a pain. Which is why I would rather not become too dependent on things that might later prove to be a constraint.

Having said that, this might explain why I would rather try to integrate AngularJS with ASP.NET Ajax. The latter is something so convenient to me that I’d hate to give it up. Similarly, although jQuery is one major library that I’m working with daily and by far it is a huge success, I’m still using the good ol’ ASP.NET Ajax over jQuery’s Ajax wrappers. I manage to integrate them together with ease so that’s a comfy.

The problem was that after I experimented a little with AngularJS “hello world” samples, I tried to do the most trivial thing: make an Ajax call outside of AngularJS framework and then apply the results using AngularJS. In short, I wasn’t trying to code “in AngularJS” but to use it for templating only. Using jsrender, what I would do is perform a simple ajax call and in the callback use the results and templates, followed by injecting the html onto the page. Very simple. In AngularJS, initially, I couldn’t find a way to do that. That is, I could not find a way to change the $scope property from outside the controller. Perhaps there are ways to do that, but I failed to make a simple ajax call and set the results as a datasource.

After some time it occurred to me that I was working wrong with AngularJS. I figured that if I can’t call the AngularJS controller from outside, I need to change the datasource from the inside. Therefore I made the PageMethods ajax call from within the controller and then it worked as expected.

So the result is as follows. This is my ASP.NET Default.aspx:

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" %>

<!DOCTYPE html>
<html>
<head runat="server">
    <title></title>
</head>
<body ng-app>
    <form id="form1" runat="server">
    <asp:ScriptManager runat="server" EnablePageMethods="true">
        <Scripts>
            <asp:ScriptReference Path="http://code.angularjs.org/1.0.8/angular.js" />
            <asp:ScriptReference Path="~/JScript.js" />
        </Scripts>
    </asp:ScriptManager>
    <div ng-controller="TestCtrl" ng-init="init()">
        {{source}}
    </div>
    </form>
</body>
</html>
  • Line 1: Well, this is a Default.aspx page because we’re using ASP.NET here.
  • Line 8: ng-app tag to indicate an AngularJS app.
  • Line 10: Enable PageMethods.
  • Lines 12-13: AngularJS framework and my own js file containing the AngularJS controller.
  • Line 16: Use my TestCtrl controller with this div element and activate the init() function when the page (view) loads.
  • Line 17: This is the name of the property that it’s value will be displayed and changed following the ajax call. It’ll be initialized in the controller later on.

And the JavaScript AngularJS controller I wrote (JScript.js):

function TestCtrl($scope, $timeout) {
    $scope.source = 10;
    $scope.init = function () {

        PageMethods.Inc($scope.source, function (result) {
            $scope.$apply(function () {
                $scope.source = result;
                $timeout(function () {
                    $scope.init();
                }, 100);
            });
        });

    }
}
  • Line 2: The source property. Initialized to a value of 10.
  • Line 3: The init() method. This is called by AngularJS because in the html I placed an ng-init in the div.
  • Line 5: The ASP.NET Ajax call. Can be any ajax call here: jQuery, ASP.NET Ajax or whatever you prefer. Note that I’m passing the current value of ‘source’ as an argument to the server which will increment this value.
  • Line 6: In AngularJS you have to call $apply to invoke AngularJS framework for calls outside the framework. Here’s a quote from the docs:

    “$apply() is used to execute an expression in angular from outside of the angular framework. (For example from browser DOM events, setTimeout, XHR or third party libraries). Because we are calling into the angular framework we need to perform proper scope life cycle of exception handling, executing watches.”

    Without $apply this code doesn’t seem to refresh the updated binding onto the html.

  • Line 7: In the callback, change the source property of the controller.
  • Lines 8-10: Using the AngularJS $timeout function to schedule consecutive recursive calls to the init() method. The ‘source’ is expected to increment endlessly.

That’s it. If you run this code you’ll see that it endlessly calls the server using ASP.NET Ajax and updates the AngularJS ‘source’ property as expected.

“Philosophy”
Although AngularJS looks very tempting and sexy, what’s important to me is to have ease of use and not to be too dependent. Like so many frameworks that seemed so appealing at one time, AngularJS too has the potential to be looked at as an ancient dinosaur one day. That’s OK. I work with a dinosaur on a daily basis (ASP.NET WebForms). I believe that every single developer with several years of experience in any environment, can provide examples to libraries and frameworks that once were considered the pinnacle of technology. Not many survive as new technologies and ideas are being thought of everyday. Therefore I think that you should choose something that you’ll feel comfortable to work with and not just because it is now very hot. Just browse this article, and you’ll find the 10 hottest client side frameworks of today. While their fans argue between themselves which is better (Backbone.JS? AngularJS? Ember.js?), I think that it’s quite clear that not all ten will remain in that list for years to come. Something else will become “hot”. What then? you can’t just replace your website’s framework every couple of months just because some other technology became “hotter” than what you have selected. Therefore, do not pick the hottest. Pick what’s working for you and your team. If it’s AngularJS, great. If it is Backbone JS, great. If you rather keep a more classic approach by manipulating the DOM using jQuery or the amazing Vanilla JS – that’s great too. Just don’t bind yourself to something because of the wrong reasons.

Summary
In fairness, I think AngularJS looks very interesting. The concepts seems to be very good. Separation of concerns, testing and advocation of single page applications as true applications. In fact, I’m looking forward to using AngularJS in a real project. However, my main concern over AngularJS is that it seems to me like it is a somewhat “too-closed” of a framework and that you must and abide by “the rules”. While it has advantages as it conforms you to do things “properly, their way”, it is also a disadvantage because if eventually you’ll run into a situation that AngularJS doesn’t do what you expect it to – you’ll have a problem. Then you might want to revert to some non-AngularJS such as jQuery but this is strongly discouraged. You’re welcome to read this very helpful post and replies. You’ll get an idea why you shouldn’t mix the two.

In case you’re asking yourself, I consider both jQuery and ASP.NET Ajax as “open” libraries. They are not frameworks. You can work with them in your website and you can work without. You can decide to adapt newer patterns & plugins and even other libraries. You can use plain JavaScript to manipulate the DOM any way you require with or without them. In short, they are not constraining.

 
Leave a comment

Posted by on 27/10/2013 in Software Development

 

Tags: , ,

Force a website to https using IIS Custom Error pages

A well common requirement for secure websites is not only to support https but to make it mandatory. The problem is that if you require an SSL from your website, the end user receives an ugly 403.4 message that informs that SSL is required. Why doesn’t IIS have a simple check box in the “Require SSL” dialog to “auto redirect requests to https” is unclear to me, but in this post I’ll explain how simple it is to accomplish this without writing any code at all.

So, in order to force a website to https and redirect normal http requests to https you have various methods. At times I did this using server code: detect if you’re running a normal http and redirect from the server. But recently I attempted this using simple IIS configuration. The idea is as follows:

  1. Tweak IIS to require SSL. By default, this will inform the user of a 403.4 auth error.
  2. Using IIS’ Custom Errors feature, customize the 403.4 to redirect to https.

Before we start: naturally, you need a valid SSL certificate for this procedure to work. If you just need a test certificate for development and practice, you can IIS to generate a dummy certificate for you like so:

  1. In IIS Manager, select the Server name on the left.
  2. Go into Server Certificates in the Features View.
  3. In the Actions pane on the right, select Create Self-Signed Certificate.

To enable SSL on your website after you have installed an SSL certificate:

  1. In IIS Manager, select the target website.
  2. On the Actions pane on the right, click Bindings.
  3. In the opening dialog, click Add, select “https” and then select the desired certificate.
  4. Test that SSL is working by browsing to https.

Now we can configure a redirect to https.

Tweaking IIS to require SSL

Open IIS and select the target website or virtual application. In the Features View, select SSL Settings.

1Select “Require SSL” and “Accept”. Do not select “Require” or this won’t work at all.

2

Now if you try to browse to http as usual, you should see a 403.4 message like so:

5

Using Custom Error pages

In order to use custom Error pages, this feature must be installed. If you notice that your IIS does not provide the Error Pages feature, simply install it (the screenshot below is from Windows 7):

3

In IIS, select on the left the target server, website or application. On the Features View select Error Pages under IIS (note: this is NOT the same as .NET Error Pages under ASP.NET):

4

In the right pane select “Edit Features Settings…”

6

In the dialog that opens, select “Custom error pages” and click OK. This means that when you when we configure a redirect later on,  it will actually be in effect:

7

Finally, we have to define a new “error page” rule, to handle 403.4 and perform a redirect. Just click on the Add in the Actions pane to the right and fill-in the desired redirect rule details:

8

Eventually, this would look like this:

10

That’s it. Now if you browse to http you should be redirected to https. The web.config looks as follows:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <httpErrors>
            <remove statusCode="403" subStatusCode="4" />
            <error statusCode="403" subStatusCode="4" path="https://localhost" 
responseMode="Redirect" />
        </httpErrors>
    </system.webServer>
</configuration>

 
Leave a comment

Posted by on 21/06/2013 in Software Development

 

Tags: , , ,

Handling unhandled Task exceptions in ASP.NET 4

This blog post isn’t intended to explain how to use IsFaulted or any other method for handling Task exceptions in a specific block of code, but how to provide a general solution to handling unhandled Task exceptions, specifically in ASP.NET. The problem dealt with in this post is a situation that a developer didn’t handle an exception in the code for whatever reason, and the process terminates as a result.

I came across a problematic situation – in a production environment, an ASP.NET IIS process seems to be terminating and initializing constantly. After some research, it turned out that there’s a certain Task that was raising exceptions, but the exceptions were not handled. It seems like the Application_Error handler was not raised for these exceptions. It seems that in .NET 4, unhandled Task exceptions terminate the running process. Fortunately, Microsoft changed this behavior in .NET 4.5 and by default the process is no longer terminated. It is possible to change that behavior to the previous policy by tweaking the web.config, although I find it hard to think why one would want to do that, except maybe in a development environment in order to be aware that such unhandled exceptions exist.

Back to .NET 4, we still have to prevent termination of the process. The first issue was to find how to catch unhandled Task exceptions, as it became clear that Application_Error wasn’t handling these exceptions. I googled for a solution. Turns out that there’s an UnobservedTaskException event that is designated for this exact purpose. It’s a part of the TaskScheduler class. Whenever an unhandled Task exception is thrown, it may be handled by event handlers wired to this event. The code block below is an example how this event can be put into use in a global.asax file.

    void Application_Start(object sender, EventArgs e)
    {
        // Code that runs on application startup
        System.Threading.Tasks.TaskScheduler.UnobservedTaskException += TaskScheduler_UnobservedTaskException;
    }

    void TaskScheduler_UnobservedTaskException(object sender, System.Threading.Tasks.UnobservedTaskExceptionEventArgs e)
    {
        e.SetObserved();
    }

As you can see, when you call the SetObserved() method, this marks the exception as “handled”, and the process will not terminate.

Note, that the exception is basically thrown when the Task is GC-ed. This means that as long as there are references to the Task instance it will not be garbage collected and an exception will not be thrown.

Depending on the TaskCreationOptions, the raised events and event handling may vary in behavior. For example, if you have nested Tasks throwing exceptions, and the TaskCreationOptions is set to be attached to the parent, a single UnobservedTaskException event will be raised for all those exceptions, and you may handle each of these exceptions differently, if required. The incoming exceptions in such a case are not “flattened” but nested as well, and you may iterate recursively on the different exceptions in order to treat each and everyone independently. However, you may call on the Flatten() method to receive all the exceptions in the same “level” and handle them as if they were not nested.

In a test page, a button_click event handler raises three exceptions. The nested exceptions are AttachedToParent, which affects how they will be received in the UnobservedTaskException event handling. I added a GC_Click button and event handler to speed things up:

    protected void Button_Click(object sender, EventArgs e)
    {
        Task.Factory.StartNew(() =>
        {
            Task.Factory.StartNew(() =>
            {
                Task.Factory.StartNew(() =>
                {
                    throw new ApplicationException("deepest exception");
                }, TaskCreationOptions.AttachedToParent);

                throw new ApplicationException("internal exception");
            }, TaskCreationOptions.AttachedToParent);

            System.Threading.Thread.Sleep(100);
            throw new ApplicationException("exception");
        }, TaskCreationOptions.LongRunning);
    }

    protected void GC_Click(object sender, EventArgs e)
    {
        GC.Collect();
    }

You can see in the Watch window, how these exceptions are received in the event handler by default:
1

And with the Flatten() method:
2

Note: If the Task creation is set differently, for example to LongRunning, each exception will have its own event handling. In other words, multiple UnobservedTaskException event handlers will be raised.

Now comes the other part where you would probably want to Log the different exceptions. Assuming that you would want to log all the exceptions, regardless of their “relationship”, this is one way to do it, assuming a Log method exists:

    void TaskScheduler_UnobservedTaskException(object sender, System.Threading.Tasks.UnobservedTaskExceptionEventArgs e)
    {
        e.SetObserved();
        e.Exception.Flatten().Handle(ex =>
        {
            try
            {
                Log(ex);
                return true;
            }
            catch { return true; }
        });
    }

The Handle method allows iteration over the different exceptions. Each exception is logged and a true if returned to indicate that it was handled. The try-catch there is designated to ensure that the logging procedure itself won’t raise exceptions (obviously, you may choose not to do that). You should also take into account that if you would like to implement some kind of particular logic that determines whether the exception should be handled or not, you may choose to return false for exceptions not handled. According to MSDN, this would throw another AggregateException method for all the exceptions not handled.

Next step: apply the exception handling to an existing application in production.
If this code is to be incorporated during development, simple change to global.asax would do. But this had to be incorporated in a running production environment. If this is a web site, then it would still be possible to patch the global.asax. Just have to schedule a downtime as ASP.NET will detect a change to global.asax and the application will be restarted. The biggest advantage is of course the ability to change the global.asax in a production environment as ASP.NET will automatically compile it.

But for a web application this is different. As the global.asax.cs is already compiled into an assembly in a production environment, there are basically two options: either compile the solution and deploy an upgrade, or write an http module. Writing a module probably makes more sense as you don’t have to compile and deploy existing assemblies. You just have to add an HttpModule to an existing web app.

Here’s an example for such a module:

    public class TaskExceptionHandlingModule : IHttpModule
    {
        public void Dispose() { }

        public void Init(HttpApplication context)
        {
            System.Threading.Tasks.TaskScheduler.UnobservedTaskException += TaskScheduler_UnobservedTaskException;
        }

        void TaskScheduler_UnobservedTaskException(object sender, System.Threading.Tasks.UnobservedTaskExceptionEventArgs e)
        {
            e.SetObserved();
            e.Exception.Flatten().Handle(ex =>
            {
                try
                {
                    Log(ex);
                    return true;
                }
                catch { return true; }
            });
        }

        private void Log(Exception ex)
        {
            // TODO: log the exception
        }
    }

All that is left to do is place the compiled http module in the bin folder and add a reference to it in the web.config. Note: The location within the web.config may vary depending on the version of the IIS used.

<httpModules>
<add name="TaskExceptionHandlingModule" type="TaskExceptionHandlingModule.TaskExceptionHandlingModule, TaskExceptionHandlingModule"/>
</httpModules>

Notice that changing the web.config and placing the module in the bin folder of the web application will cause it to restart, so this has to be done at a coordinated downtime.

Assuming the module was placed in the correct location and that the web.config was properly configured, the process is no longer expected to terminate due to unhandled task exceptions, and those exceptions should now be logged.

 

 
Leave a comment

Posted by on 26/05/2013 in Software Development

 

Tags: ,

Getting the parameters and values of the SoapMessage

Sometimes it’s a good practice to be able to process a WebService request’s argument. You may want to consider various things: logging the arguments, detecting specific arguments for some business logic implementation or validation of the passed-in values (security).

For the sake of this post, the arguments will be logged using the following code, but then again – you should think “bigger”. Anyway, here’s the logging code:

public static class Logger
{
    public static void LogParameters(NameValueCollection map)
    {
        foreach (string item in map)
        {
            System.Diagnostics.Debug.WriteLine("{0}={1}", item, map[item]);
        }
    }
}

Simple POST and GET
“Regular” POST or GET requests are quite simple to process. All you have to do is place code in the constructor of the WebService, get the collection of arguments and do whatever you want with them:

[WebService(Namespace = "http://tempuri.org/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
public class MyService : System.Web.Services.WebService
{
    public MyService()
    {
        var request = this.Context.Request;
        NameValueCollection map = null;
        if (request.HttpMethod == "POST")
        {
            map = request.Form;

        }
        else if (request.HttpMethod == "GET")
        {
            map = request.QueryString;
        }

        if (map != null)
            Logger.LogParameters(map);
    }

    [WebMethod]
    [TraceExtension]
    public string GetGreeting(string name)
    {
        return "Hello " + name;
    }
}

SOAP
However, for SOAP this is a little more difficult. Although you can try to get the request contents and parse the arguments and their values, there’s a much more convenient way for doing so. .NET already parses the Soap message so why not use it? Apparently you can write a class that receives the parsed SoapMessage and take the arguments from there. In order to do so, you have to write two classes: one class will receive the SoapMessage, and the other class is an Attribute that will perform the hook between the called WebMethod and your class.

If you noticed, the GetGreeting WebMethod above has a TraceExtension Attribute (line 24 in the previous code block). Here is the code for it:

[AttributeUsage(AttributeTargets.Method)]
public class TraceExtensionAttribute : SoapExtensionAttribute
{
    public override Type ExtensionType { get { return typeof(TraceExtension); } }
    private int priority;
    public override int Priority
    {
        get { return this.priority; }
        set { this.priority = value; }
    }
}

Note that the Attribute inherits from SoapExtensionAttribute, which is a requirement to perform the hook to your class.
Also note that on line 4 above, the returned Type is that of the actual class that is going to receive the SoapMessage and handle it. See the class below:

public class TraceExtension : SoapExtension
{
    public override void ProcessMessage(SoapMessage message)
    {
        switch (message.Stage)
        {
            case SoapMessageStage.AfterDeserialize:
                var map = new NameValueCollection();
                for (int i = 0; i < message.MethodInfo.InParameters.Length; ++i)
                {
                    var p = message.MethodInfo.InParameters[i];
                    object val = message.GetInParameterValue(i);
                    map.Add(p.Name, val.ToString());
                }

                Logger.LogParameters(map);
                break;

            case SoapMessageStage.AfterSerialize:
                break;

            case SoapMessageStage.BeforeDeserialize:
                break;

            case SoapMessageStage.BeforeSerialize:
                break;
        }
    }

    public override object GetInitializer(Type serviceType)
    {
        return null;
    }

    public override object GetInitializer(LogicalMethodInfo methodInfo, SoapExtensionAttribute attribute)
    {
        return null;
    }

    public override void Initialize(object initializer)
    {
    }
}

The important code here is the override method of ProcessMessage. Here the SoapMessage is received in various stages of the deserialization (and serialization) that allow you flexibility should you require it. As you can see, in lines 8-14 there’s an iteration that loops over the input parameters. This way we receive the already parsed parameters which is what we wanted in the first place. Once we have the parameters in a NameValueCollection, we pass it to the handling method for further processing (logging, in this particular example).

Credits:
The code here is based mainly on the SoapExtension class example from MSDN.

If you’re interested to learn more about the life of the SoapMessage or other stuff that you can do with it, this link may interest you.

 
Leave a comment

Posted by on 03/04/2013 in Software Development

 

Tags:

HTML5 Drag and Drop Ajax file upload using jQuery File Upload plugin

If you just want the sample, right click this link, save as, rename to zip and extract.

This post is in a way a continuation of an earlier post, which explains how you can achieve an Ajax File Upload with ASP.NET. Only in this post I’ll focus on how to achieve this using HTML5 Drag and Drop features from a Windows Explorer.

Note: IE9 or below have limited Drag/Drop support so don’t expect this solution to work on those browsers.
Note 2: The FileUpload and jQuery used in this post are not the latest, so some changes maybe required to make this work well with newer versions.

In order to implement drag and drop to an existing File Upload solution, all you have to do is bind three events, two of them toggle CSS classes and have nothing to do with the upload itself, and one of them handles the actual ‘drop’. It’s not that the CSS classes are mandatory in order to get upload to work, it’s simply one of the ways to provide a feedback to the end-user that a drag operation takes place.

Before dragging, the page looks like so:
beforedrag

During the drag operation CSS classes provide a feedback to the user:
drag

The JavaScript used here:

$(function () {
    // file upload
    $('#fileupload').fileupload({
        replaceFileInput: false,
        formData: function (form) {
            return [{ name: "name1", value: "value1" }, { name: "name2", value: "value2"}];
        },
        dataType: 'json',
        url: '<%= ResolveUrl("AjaxFileHandler.ashx") %>',
        done: function (e, data) {
            $.each(data.result, function (index, file) {
                $('<p/>').text(file).appendTo('.divUpload');
            });
        }
    });

    // handle drag/drop
    $('body').bind("dragover", function (e) {
        $('.divUpload').addClass('drag');
        e.originalEvent.dataTransfer.dropEffect = 'copy';
        return false;
    }).bind("dragleave", function (e) {
        $('.divUpload').removeClass('drag');
        return false;
    }).bind("drop", function (e) {
        e.preventDefault();
        $('.divUpload').removeClass('drag');
        var list = $.makeArray(e.originalEvent.dataTransfer.files);
        $('#fileupload').fileupload('add', { files: list });
        return false;
    });
});

The code it quite self-explanatory, but nevertheless here’s a short explanation:

  • Lines 3-15: this is the same code from the previous post. It uses the jQuery FileUpload plugin for Ajax file upload.
  • Lines 18-21: handle a “drag start” event. This simply adds a CSS class to provide a feedback to the user.
  • Lines 22-24: handle a “drag leave” event, and removes the CSS class.
  • Lines 25-30: handles the “drop” event. This is the important stuff. We remove the CSS class that provides a feedback on the dragging, take the select files and add them to the File Upload plugin, which starts the upload. Note that the original files object from the event is converted to an array (“list”), and only then the information is passed on to the File Upload plugin. If you skip this the plugin might not work.
  • Lines 11-13: When done, the file names will be displayed as HTML elements. Change this to whatever you require.

The HTML looks like this:

<div class='divUpload'>
    <div class='file'><input id="fileupload" type="file" name="file" multiple="multiple" /></div>
    <div class='dropzone'><div>drag files here</div></div>
</div>

Not much here either. Mainly different DIVs which are displayed according to the drag/drop events.

  • Line 2: The original file input field.
  • Line 3: The DIV which appears upon drag.

Finally there’s the CSS. I have implemented it one way but naturally this can be done completely differently. The “trick” is to add the “drag” class on the top DIV, which causes the browser to use different CSS rules on the nested DIV elements. The file input field becomes hidden and the drag feedback is shown.

body, html, .divUpload
{
    height: 100%;
    margin: 0;
    overflow: hidden;
    background-color: beige;
}

.divUpload
{
    margin: 8px;
}

.divUpload.drag .file
{
    display: none;
}

.divUpload.drag .dropzone
{
    display: table;
}

.dropzone
{
    border: 3px dashed black;
    display: none;
    font-size: 20px;
    font-weight: bold;
    height: 95%;
    position: relative;
    text-align: center;
    vertical-align: middle;
    width: 99%;
    background-color: rgba(37, 255, 78, 0.33);
}

.dropzone div
{
    display: table-cell;
    vertical-align: middle;
}
  • Line 27: The dropzone is not hidden by default.
  • Line 16: When dragging takes place, the default file field is being hidden.

The result looks like this:
afterdrag

 
2 Comments

Posted by on 24/02/2013 in Software Development

 

Tags: , , ,

.NET 4 URL Routing for Web Services (asmx)

This post describes how to perform Url Routing to a Web Service. If you’re just interested in the solution, click here.

OK, this was a tough one.

The goal was to implement URL routing for an existing web site that has asmx Web Services. The intention was to allow white-labeling of the Web Services. You might argue why one would want to do that, so I’ll summarize by writing that one of the reasons to do so was that I wanted to enjoy URL Routing advantages, without having to rewrite the existing Web Services into a more “modern” alternative such as MVC. Other reasons are obvious: Web APIs are becoming more and more URL friendly and allow great flexibility.

Note that the web site is written in .NET 4 over IIS7, so I won’t get into how to configure routing or web services. You can read here about Routing, and specifically about Routing in WebForms here.

Unlike routing in MVC which you can’t really do without, in WebForms this is less trivial. In WebForm’s Routing we have the MapPageRoute method, but we have nothing specific for Web Services or other handlers. I already blogged about how to route to a handler (ashx), but I found it much less trivial to accomplish routing for Web Services, and in this post I’ll try to explain why.

Setup
The Web Service in this example has a simple HelloWorld method that returns a greeting:

using System.Web;
using System.Web.Services;

[WebService(Namespace = "http://evolpin/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
[System.Web.Script.Services.ScriptService]
public class MyWebService : System.Web.Services.WebService
{
    [WebMethod]
    public string HelloWorld(string name)
    {
        string product = HttpContext.Current.Request.RequestContext.RouteData.Values["product"] as string;
        return string.Format("Hello {0} from {1}", name, product);
    }
}
  • Line 6: very important – allow the Web Service to be invoked from a client script.
  • Line 12 I attempt to retrieve the {product} part from the Route data. This is an example for the desired white-labeling.

The Global.asax looks like this:

<%@ Application Language="C#" %>
<%@ Import Namespace="System.Web.Routing" %>
<script runat="server">
    void Application_Start(object sender, EventArgs e)
    {
        RegisterRoutes(RouteTable.Routes);
    }

    public static void RegisterRoutes(RouteCollection routes)
    {
        routes.Add(new System.Web.Routing.Route("{product}/xxx/{*pathInfo}", new WebServiceRouteHandler("~/MyWebService.asmx")));

        routes.MapPageRoute("", "{*catchall}", "~/Test.aspx");
    }
</script>

The web.config looks like this:

<?xml version="1.0"?>
<configuration>
  <system.web>
    <webServices>
      <protocols>
        <add name="HttpGet"/>
        <add name="HttpPost"/>
      </protocols>
    </webServices>
    <compilation debug="true" targetFramework="4.0" />
  </system.web>
</configuration>

The test page (Test.aspx) looks like this:
test page
And its code:

<%@ Page Language="C#" %>

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <script type="text/javascript" src="http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.8.3.min.js"></script>
</head>
<body>
    <form id="form1" runat="server">
    <script type="text/javascript">
        function doGet() {
            $.ajax({
                url: "http://localhost/Routing/" + $('#product').val() + "/xxx/HelloWorld?name=evolpin",
                type: "GET",
                success: function (result) {
                    alert(result.firstChild.textContent);
                }
            });
        }

        function doPostXml() {
            $.ajax({
                url: "http://localhost/Routing/" + $('#product').val() + "/xxx/HelloWorld",
                type: "POST",
                data: { name: 'evolpin' },
                success: function (result) {
                    alert(result.firstChild.textContent);
                }
            });
        }

        function doPostJson() {
            $.ajax({
                url: "http://localhost/Routing/" + $('#product').val() + "/xxx/HelloWorld",
                type: "POST",
                contentType: 'application/json',
                data: JSON.stringify({ name: 'evolpin' }),
                success: function (result) {
                    alert(result.d);
                }
            });
        }
    </script>
    <div>
        <input type="text" id='product' value='MyProduct' />
        <input type="button" value='GET' onclick='doGet();' />
        <input type="button" value='POST xml' onclick='doPostXml();' />
        <input type="button" value='POST json' onclick='doPostJson();' />
    </div>
    </form>
</body>
</html>
  • Lines 11-19 perform a GET with a query string.
  • Lines 21-30 perform a POST with regular text/xml content type.
  • Lines 32-42 perform a POST using JSON.

Note that all these JavaScript methods take the “product name” from the ‘product’ text box.

And finally, the C# client test code which will invoke the Web Service using SOAP looks like this:

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            using (localhost.MyWebService ws = new localhost.MyWebService())
            {
                ws.Url = "http://localhost/Routing/MyProduct/xxx";
                string s = ws.HelloWorld("evolpin");
            }
        }
    }
}

Line 9: Changing the target Url to the Route.

The code
After googling quite a lot (it seems like there’s very little information about this), I saw several posts that used the following solution:

using System.Web;
using System.Web.Routing;
public class WebServiceRouteHandler : IRouteHandler
{
    private string virtualPath;

    public WebServiceRouteHandler(string virtualPath)
    {
        this.virtualPath = virtualPath;
    }

    public IHttpHandler GetHttpHandler(RequestContext requestContext)
    {
        return new System.Web.Services.Protocols.WebServiceHandlerFactory().GetHandler(HttpContext.Current, "*", this.virtualPath, HttpContext.Current.Server.MapPath(this.virtualPath));
    }
}

While this solution works for SOAP, if you try to GET or POST, the route won’t work well and you’ll end up receiving the auto generated WSDL documentation instead of calling your actual method. This occurs because the route that I was using was an extensionless route and for reasons explained below, the factory was unable to establish which protocol to use, so it ended-up with the Documentation handler. The WebServiceHandlerFactory attempts to understand which handler should be used to serve the request, and to do so it queries the different protocols it supports (e.g. SOAP, GET, POST etc.). I’ll use a GET request in order to explain why this doesn’t work well. The GET request used in this example is:

http://localhost/Routing/MyProduct/xxx/HelloWorld?name=evolpin
  • ‘xxx’ is the Web Service alternate route name.
  • ‘MyProduct’ is the sample product using the white-label feature.
  • ‘HelloWorld’ is the web method name that I would like to invoke.
  • ‘name’ is the name of the argument.

WebServiceHandlerFactory

The above image shows how the factory iterates over the available server protocols in an attempt to locate one suitable to serve the request. Here are the different supported protocols:

ServerProtocolFactories

If we peak into one of the supported protocols, GET, we can see that it queries the PathInfo. If the PathInfo is too short, a null is returned and the factory will continue to search for a suitable protocol.

HttpGetServerProtocolFactory

The PathInfo in this sample GET request is empty (“”). This is because I’m using an extensionless route. To make a long story short, after drilling down into the internals, the PathInfo in IIS7 is built on the understanding what the actual path info is (e.g. /HelloWorld). Because of the extensionless URL, the IIS7 fails to determine what the PathInfo is and sets it to empty, as seen below:

IIS7WorkerRequest

Now that I realized that there’s a problem with extensionless URLs, as IIS can’t parse the PathInfo correctly, I tried changing the route by adding ‘.asmx’ to it, hoping that this will help to resolve the correct path info. So I changed Global.asax and Test.aspx to use the .asmx, and the new route looks like this:

http://localhost/Routing/MyProduct/xxx.asmx/HelloWorld

When I tried GET or POST (using xml for the response content type), the new route worked! IIS7WorkerRequest was able to parse the PathInfo and the GET/POST protocol classes “were content” and used successfully. However, when I tried to use JSON I got back the following error:

System.InvalidOperationException: Request format is invalid: application/json; charset=UTF-8.
   at System.Web.Services.Protocols.HttpServerProtocol.ReadParameters()
   at System.Web.Services.Protocols.WebServiceHandler.CoreProcessRequest()

Looking at HttpServerProtocol.ReadParameters, I could see that there’s an iteration which attempts to determine which reader class should be used, according not only to the request type (e.g. POST), but also according to the content type:

HttpServerProtocolReadParameters

So I placed a breakpoint in the Route handler and drilled down to see what readerTypes exist and found out that there were two: UrlParameterReader and HtmlFormParameterReader:

ref1

As the debugger showed that hasInputPayload was ‘true’, I realized that the HtmlFormParameterReader was the one used. Looking at the code there, it became clear why using JSON failed:

HtmlFormParameterReader

I realized that unless I am missing something, WebServiceHandlerFactory was simply not good enough because while it did solve the GET/POST and xml content-type routing issue, it wasn’t able to handle the JSON content, which I wasn’t willing to give up on.

I tried looking for a different approach, placed a breakpoint in the HelloWorld method and invoked it “old fashion way”, without any routing or JSON. This is what I saw in the debugger when I was searching for which handler was used:

ScriptHandlerFactory1

What’s this? It seems like the built-in ASP.NET handlers are not using the WebServiceHandlerFactory directly, but a certain ScriptHandlerFactory. OK, so let’s review the debugger when a JSON request is sent:

ScriptHandlerFactory2

It seems like for JSON, the “built-in mechanism” is not using the WebServiceHandlerFactory at all, but a RestHandlerFactory, wrapped by the ScriptHandlerFactory. I have been using the wrong factory all along! Here’s the GetHandler of ScriptHandlerFactory:

ScriptHandlerFactory

As you can see, the ScriptHandlerFactory is a wrapper that instantiates other handlers and wrappers according to the request method and content types. Using the ScriptHandlerFactory seems like the correct option in order to have routing invoke the web service correctly, with different request methods and content types.

Solution:
Unfortunately, for some reason ScriptHandlerFactory is internal and non-public. So I had to use Reflection to invoke it. However, this didn’t work well because I kept receiving wrong handler classes (especially when I removed the .asmx added before to the route). After doing some more Reflection research, and remembering that the logic for retrieving the handlers and protocols was very dependent on the PathInfo, I was looking for a way to change it. PathInfo is actually a getter-only property which is dependent how IIS resolves the path. Fortunately, it seems like the path can be changed by calling the HttpContext.RewritePath method. So the resulting code looks like this:

using System;
using System.Web;
using System.Web.Routing;
public class WebServiceRouteHandler : IRouteHandler
{
    private static IHttpHandlerFactory ScriptHandlerFactory;
    static WebServiceRouteHandler()
    {
        var assembly = typeof(System.Web.Script.Services.ScriptMethodAttribute).Assembly;
        var type = assembly.GetType("System.Web.Script.Services.ScriptHandlerFactory");
        ScriptHandlerFactory = (IHttpHandlerFactory)Activator.CreateInstance(type, true);
    }

    private string virtualPath;
    public WebServiceRouteHandler(string virtualPath)
    {
        this.virtualPath = virtualPath;
    }

    public IHttpHandler GetHttpHandler(RequestContext requestContext)
    {
        string pathInfo = requestContext.RouteData.Values["pathInfo"] as string;
        if (!string.IsNullOrWhiteSpace(pathInfo))
            pathInfo = string.Format("/{0}", pathInfo);

        requestContext.HttpContext.RewritePath(this.virtualPath, pathInfo, requestContext.HttpContext.Request.QueryString.ToString());
        var handler = ScriptHandlerFactory.GetHandler(HttpContext.Current, requestContext.HttpContext.Request.HttpMethod, this.virtualPath, requestContext.HttpContext.Server.MapPath(this.virtualPath));
        return handler;
    }
}
  • Lines 6-12 create a static ScriptHandlerFactory (no need to recreate it every time that the RouteHandler is used.
  • Lines 14-18 is a constructor that receives the virtual path for which the RouteHandler is instantiated for.
  • Lines 22-24: determine the pathInfo we want.
  • Line 26 modifies the PathInfo. This is the magic!
  • Line 27 invokes the logic of the ScriptHandlerFactory, which returns the appropriate handler according to the requset method and content type.

And the result (GET/POST, xml/JSON):

test page 2

SOAP (this was tested working with Soap 1.1 and 1.2):

soap1

Summary
I would be more than happy if someone has a better solution to this. The described solution here is still not complete. Besides the used Reflection, what’s missing is that the Documentation protocol (i.e. WSDL auto generation) should invoke the different methods using the {product} of the Url Route. If you try to use this solution and activate the HelloWorld method using the WSDL help page,  you’ll see that it uses the wrong url for invocation.

What’s good about this solution is that it’s very simple, it allows SOAP, GET, POST and JSON. It also allows you to use Url routing advantages, and without having to use the asmx extension in the route. In other words, complete Url Routing flexibility. I also successfully tested a version of this solution in IIS6.

Credits: I used the excellent ILSpy for Reflection, which is a very good substitute to Red-Gate’s not-free-any-more Reflector.

 
3 Comments

Posted by on 30/12/2012 in Software Development

 

Tags: ,

 
Follow

Get every new post delivered to your Inbox.

Join 60 other followers