Integrating Azure CDN into an ASP.Net MVC application

Using a CDN has a multitude of advantages. I won't go into details about them here. You can Google around for more info ;-)

In the examples one can find online on how to integrate a CDN into an MS MVC application, we see typical examples using the CDN of common libraries like jQuery:

See "Using a CDN" at http://www.asp.net/mvc/overview/performance/bundling-and-minification

It's plain and simple:

var jqueryCdnPath = "http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.7.1.min.js";

bundles.Add(new ScriptBundle("~/bundles/jquery",
                jqueryCdnPath).Include("~/Scripts/jquery-{version}.js"));

But what if you want to use your own scripts through a CDN like Azure? This works nicely (in BundleConfig):

bundles.Add(new ScriptBundle("~/bundles/jquery", CdnRoot + "/bundles/jquery")
                .Include("~/Content/Scripts/Lib/jquery-{version}.js"));

where CdnRoot is the path to the CDN endpoint, like: //my-endpoint.azureedge.net

This way, the CDN will load the resources from the bundle like in a normal case, store it in its cache, and return it the next times a user requests them. No need to upload the files to the CDN, and changes to the code behind the bundle is taken into account automatically.

ASP.Net Web API + OData + $inlinecount

So, I had a nice single page application querying data from a Web API backend. As I wanted to allow searching and paging, I used the OData extensions and all was well. Until I needed to know the total number of items in the dataset after having it filtered using $filter, $top and $skip. At the time, I didn't find any easy way to do it, so I implemented a second query to the API to return the total number of items. Problem is, this second query returned the total number of items and didn't take into account any filtering I had applied in the OData query (using $filter). I let that dormant for a while...

Then came the need to have a nice navigation footer, and I used this component: http://botmonster.com/jquery-bootpag/

This component just needs to know the number of pages and at which page it currently is. But then again, we need to know the number of items to know the number of pages to display. Back at square one ;-)

I looked for ways to implement this once again and found more info this time (technology matured or better search query in Google?). Some articles suggested to force the verbose mode of OData (by using "&$format=verbosejson" or adding an accept header with a value of "application/json;odata=verbose"), to no avail. I would always receive an array with the X items I requested using the $top parameter and nothing else.

Until I came across these 2 posts on SO:
http://stackoverflow.com/questions/18428763/web-api-odata-inlinecount-not-mapped
and http://stackoverflow.com/questions/18197041/reconstructing-an-odataqueryoptions-object-and-getinlinecount-returning-null

In short, here is what I had to change:

[Queryable(AllowedQueryOptions = AllowedQueryOptions.All)]
public IQueryable Get()
{
return m_oItems.AsQueryable();
}

changed to:

public PageResult Get(ODataQueryOptions options)
{
IQueryable results = options.ApplyTo(m_oItems.AsQueryable());
return new PageResult(results as IEnumerable, Request.GetNextPageLink(), Request.GetInlineCount());
}

Then in my JS file, I added "&$inlinecount=allpages" to my query and where I would treat the data blob returned by $.getJSON as an array, I simply use data.Count to have the number of items that match my query, and data.Items as my array of items.

The solution looks so simple now, but took me some time to figure out. Hope this helps...

IE8 not recognized in ASP.Net 1.1 applications

As always, I install the latest versions of anything when they become available (sometimes even betas). So did I for Internet Explorer 8.0 when it was released... And all of a sudden, my trusty applications made with ASP.Net 1.1 went berzerk. Things that used to work with IE7 and Firefox simply stopped working. This included external components we bought, like the ComponentArt suite. NavBars could not be clicked, drop-down menus behaved in strange ways, and so on.

I dug a bit and found the problem. My browser was not detected as it should. The
"Request.Browser.Browser" command returned "Unknown" instead of the expected "IE". But why?

I remarked that on my Vista x64 machine, the 32 bits browser would have these issues, but not the 64 bits version of IE. I compared the "User-Agent" HTTP header and saw these values:

32 bits:
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; WOW64; Trident/4.0; GTB6; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; InfoPath.2; .NET CLR 1.1.4322; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618; FDM; OfficeLiveConnector.1.3; OfficeLivePatch.0.0)

64 bits:
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Win64; x64; Trident/4.0; .NET CLR 2.0.50727; SLCC1; Media Center PC 5.0; .NET CLR 3.5.30729)

I checked the browscap.ini and machine.config files on the server, but couldn't change them in any useful way.

Could the difference in length be the problem? In a Microsoft article on TechNet (http://technet.microsoft.com/en-us/library/bb496341.aspx) they say that the length of this header should remain shorter than 200 characters. In the first case, it is definitely longer...

So I dug further, looking for ways to shorten that User-Agent string. Many articles and blog talked about the following key to change in the registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\User Agent\Post Platform

I did this, but only the User-Agent of the 64 bits instance of IE seemed to care. I searched through the registry for the "OfficeLivePatch" key I can only see in the 32 bits instance, and found it it the following key:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent\Post Platform

As you can see, there is "Wow6432Node" in there, which corresponds to 32 bits applications running on a 64 bits OS. Exactly my case ;-)

I renamed the "Post Platform" key into "Post Platform-" and restarted the browser and... bingo :-) The browser is detected as IE 8.0 and everything works fine...

Now I need to find out why, when I open a new tab or a new instance of IE 8, the content is not loaded, as it continuously shows "Connecting...". I need to open one or more tabs before a connection can be made. It also happens when opening popup windows, which is even more annoying (in that case, I need to reopen the popup with Ctrl-N until it works).

To be continued...

Access a WinDev/HyperFile DB from ASP.Net

I spent some time figuring this out, so this might be useful to someone else...

Mission: access a WinDev DB through ODBC from a C# Web Service

Steps:

• download the ODBC drivers from windev: http://www.pcsoft.fr/st/telec/modules-communs-11/wx11_54b.htm;
• decompress the ZIP-encoded installer (twice) like this: http://www.vbfrance.com/infomsg_WINDEV-VB_34754.aspx;
• copy the DLL files to "%winroot%\system";
• manually create the ODBC driver in the registry like this: http://www.developer.com/db/print.php/3712461. Don't forget to also create an entry in the "CustomDriver" key under "HKEY_LOCAL_MACHINE\Software\ODBC\ODBCINST.INI\ODBC Drivers". The DLL to use in the registry is "WD110hfo.dll";
• create a DSN in the ODBC control panel using the newly created driver;
• in your code, use the traditional OdbcConnection object to use the DSN created above;

This should be it ;-)

Thanks WinDev for making our work so complicated...