Silverlight Project Template for Visual Studio 2005

For those of you who do not want to grab the Visual Studio 2008 beta and/or wait for the release, I have created a Silverlight Project Template for Visual Studio 2005. This template makes it possible to develop Silverlight solutions under Visual Studio 2005. Grab the installer here if you can’t wait, or read on for further information.

In case you are not familiar with Silverlight, here’s the short version: Silverlight is Microsoft’s new cross-browser, cross-platform plugin for creating rich interactive applications. Silverlight implements a subset of the .NET runtime and Windows Presentation Foundation in particular. Cross-platform means Windows and Mac OS X, so there is no Linux support yet, but the Mono project are working on their own implementation of Silverlight, dubbed Moonlight.

What I find particularly interesting is that Silverlight implements a new runtime platform known as the DLR, which makes it possible to use (and blend) dynamic languages such as Python, Ruby, and Jscript when creating Silverlight applications. More generally, the DLR is a runtime for dynamic languages of any kind, which makes it one of the most interesting recent additions to the programming universe.

Longing to fiddle with Silverlight, I came across documentation on how to create Silverlight assemblies in Visual Studio 2005 written by Michael Schwarz, and created the project template based on that.

To ease the task of creating Silverlight projects, the template includes a wizard which asks for the path to your Silverlight installation, and remembers it for the future if it is correct. No further input is needed.

Note that debugging Silverlight assemblies is not possible under Visual Studio 2005, to my knowledge. If I am wrong, let me know, and I will try to add support for out-of-the-box debugging when launching the project from Visual Studio 2005. For now, you will have to point your browser to the Default.html file included in each project.

LINQ vs Loop – A performance test

I just installed Visual Studio 2008 beta 2 to see what the future holds for C#. The addition of LINQ has brought a variety of query keywords to the language. “Anything” can be queried; SQL databases (naturally), XML documents, and regular collections. Custom queryable objects can also be created by implementing IQueryable. Sadly, like every abstraction, these goodies all come at a cost. The question is how much?

I decided to create a simple test to see how much of a performance hit LINQ is. The simple test I deviced finds the numbers in an array that are less than 10. The code is quoted below.

public void LinqTest()
{
    const int SIZE = 10000, RUNS = 1000;
    int[] ints = new int[SIZE];
    for (int i = 0; i < SIZE; i++)
        ints[i] = i;</p>

<pre><code>DateTime start = DateTime.Now;
for (int t = 0; t &lt; RUNS; ++t)
{
    int[] less = (from int i in ints
                     where i &lt; 10
                     select i).ToArray();
}
TimeSpan spent = DateTime.Now - start;
Trace.WriteLine(string.Format("LINQ: {0}, avg. {1}", 
    spent, new TimeSpan(spent.Ticks / RUNS)));

DateTime start2 = DateTime.Now;
for (int t = 0; t &lt; RUNS; ++t)
{
    var l = new List&lt;int&gt;();
    foreach (var i in ints)
        if (i &lt; 10)
            l.Add(i);
    int[] less2 = l.ToArray();
}

TimeSpan spent2 = DateTime.Now - start2;
Trace.WriteLine(string.Format("Loop: {0}, avg. {1}", 
    spent2, new TimeSpan(spent2.Ticks / RUNS)));
</code></pre>

<p>}

Initially, I assumed the performance impact would not be too large, since its equivalent is the straightforward imperative loop, which should not be too hard for a compiler to deduce given static typing and a single collection to iterate across. Or?


LINQ: 00:00:04.1052060, avg. 00:00:00.0041052
Loop: 00:00:00.0790965, avg. 00:00:00.0000790

As you can see, the performance impact is huge. LINQ performs 50 times worse than the traditional loop! This seems rather wild at first glance, but the explanation is this: The keywords introduced by LINQ are syntactic sugar for method invocations to a set of generic routines for iterating across collections and filtering through lambda expressions. Naturally, this will not perform as good as a traditional imperative loop, and less optimization is possible.

Having seen the performance impact, I am still of the view that LINQ is a great step towards a more declarative world for developers. Instead of saying “take these numbers, iterate over all of them, and insert them into this list if they are less then ten”, which is an informal description of a classical imperative loop, you can now say “from these numbers, give me those that are less than ten”. The difference may be subtle, but the latter is in my opinion far more declarative and easy to read.

This may very well be the next big thing, but it comes at a cost. So far, my advice is to create simple performance tests for the cases where you consider adopting LINQ, to spot possible pitfalls as early as possible.

How to install Linksys WMP54G on Windows Vista RC2 x64

Having trouble getting your Linksys WMP54G card running on the Windows Vista x64 release candidates? Sadly, Linksys have not provided a driver for their WMP54G cards on Windows Vista x64 yet. Do not despair though, a solution exists.

For those of you who have found nothing on this URL for the last months: This post was lost in the last transfer of the site to a new server, but luckily I found a more recent backup of the old site the other day, which included this post. Enjoy!

The manufacturer of the chips used on the WMP54G is called Ralink, and they create their own drivers as well. They have even been kind enough to create a Windows Vista x64 driver for the chip, and it works! Here is how I installed the driver for the card:

  1. Go to the Ralink Technology website, find the Windows Driver section, and download the RT61 PCI/mPCI/CB driver for Vista X86/X64.
  2. Extract and run the setup program.
  3. Click Finish to complete the RT6x Wireless LAN Card Setup.
  4. Open the Windows Device Manager.
  5. Right-Click on the Network Controller under ‘Other devices’, and select Properties.
  6. Select the Driver tab and click on ‘Update Driver’ button.
  7. On the upcoming screen, select ‘Browse my computer for driver software’.
  8. Browse to the VistaX64 folder (in my case it was installed at
    C:\Program Files (x86)\RALINK\RT6x Wireless LAN Card\Installer\VISTAX64
    ), and then select ‘Let me pick from a list of device drivers on my computer’.
  9. On the upcoming screen, select ‘Network Adapters’ and click Next.
    1. Select ‘Ralink Technology, Inc.’ under the Manufacturer listbox, and select ‘Ralink RT2500 Wireless LAN Card’.

Good luck!

“Hiding” WordPress installation files

By default, all the WordPress installation files are readable from a browser. What happens if example.com‘s WordPress installation is at /wordpress/, and you go to http://example.com/wordpress/wp-content/plugins/ with your browser? Yes, you’re browsing the plugin directory. Obviously, changing permissions is not going to work, but it is possible to obscure the access to the files (hence “hiding”). Read on for details.

The WordPress default

Let us start by looking at a “standard” WordPress .htaccess file, to understand how requests are handled in a typical WordPress installation:


RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
This file contains a few directives for Apache. The <ifmodule> ... </ifmodule> tags tell Apache to care about their contents only if the specified module is installed. The remaining lines do the following:

  1. Start the mod_rewrite engine.
  2. Set the base for rewrite paths (the root of the web directory in this case). All paths will be interpreted as being below the path in this directive.
  3. If the file name the request maps to is not a file…
  4. …and it is not a directory…
  5. Then let it through to WordPress’ index.php for further handling.

This effectively means that as long as the request is not for a file or a directory below your web directory root, then WordPress handles it. If it is for a file or a directory, then Apache handles it (it falls through all the rewriting rules). This means that Apache will serve any file or directory as long as it can be read, which of course includes the WordPress installation files.

The solution

The desired situation is that people should only be able to read this files through “indirect” requests from your website, and not by accessing them directly. This can be achieved through a simple check of the HTTP Referer header :


RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_REFERER} !^https?://(www.)?example.com/.* [NC]
RewriteRule ^/?wordpress/?.* http://example.com/ [NC,L,R=301]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [NC,L]
As you can see, two directives have been added to the default .htaccess file. They state the following:

  1. If the request did not come from a reference on the website, then…
  2. If the request was for a WordPress installation file, then redirect the request to the root of my website with a 301 response (moved permanently).

This rather simple and elegant solution denies direct access to the WordPress installation files from browsers.

Why does it say “hiding”?

Because people are still able to spoof the referer header to access your installation, meaning that it’s not an unbreakable solution.

Caveats

The drawback of this setup is mainly that denying direct access to the installation files means that you cannot access any of the files directly. This includes direct access to any images or other files you have uploaded, your administrator pages, etc.

To allow access to specific files and/or folders below your directory, add the following lines to your .htaccess file for each file or folder below the first RewriteCond line:

RewriteCond %{REQUEST_URI} !^/some/directory/or/file

Note that this last example is case-sensitive, so be accurate. Also note that if the rule is for a folder, you should include /? at the end, to make sure the rule matches requests for both /some/folder and /some/folder/.

Another caveat is that this makes your blog inaccessible to people who don’t send referrer headers. If you think that people should be allowed not to do so, then don’t implement the solution in this post.