Monthly Archives: February 2014

Cache Length in for{} Loop or Not

Sometimes things just aren’t the way they are meant to be.

I’ve been reading up on ways to improve the efficiency of my JavaScript. But then, when I do some benchmark testing, the results that come in are a little unexpected.

An example. According to JavaScript luminaries, when you are iterating in a for loop, you can improve performance by using a variable to store the length of whatever collection you are iterating.

for (var i = 0, l = collection.length; i < l; i++) {
    a.num += collection[i];

/************* INSTEAD OF *************/

for (var i = 0; i < collection.length; i++) {
    a.num += collection[i];

The idea being, that if you don’t have to look up the length variable of the collection in every iteration, then it should run much faster.

Consider this benchmark test that I have created at

The interesting results for Chrome and Firefox were that the difference is negligible (in fact, in some tests the non-cached variable test was quicker). In IE 11, the expected result was reached.

It seems that Chrome and Firefox have built into their AJAX engines some kind of optimisation which is invoked when it sees the for loop structure and does not do the look-up on every iteration.

Of course, there may be something in my test which is not correct and causing the anomaly. I’d be interested in feedback if people think my test could have been written in a better manner. I saw some other tests which called Console.Log() in each iteration of the loop. I thought that was a bad idea as calling that method is probably pretty expensive and would result in bad result data, insofar as the differences would not be discernible owing to the large amount of time taken in each iteration for both types of test.

So I guess the question is, if the browsers compensate for sloppy Javascript, do we need to burn the calories to learn all those optimization tricks? I think so. Just because.

Creating a Self-Signed Certificate for Development

Update: this post is out of date and the info here will not be effective with modern browsers.

My last post went through the basics of creating a self-signed certificate using IIS Manager. But it can be done better.

Last year, I had to create a self-signed certificate for the development project I was working on, and found the IIS way of creating certificates to be somewhat lacking. It gave you no options as to who the certificate is issued. It just issued it to the PC name for the PC upon which IIS was running. So if the url which I need to type in the browser’s address bar differs from the PC-name to whom the certificate is issued, the browser will complain*.
Chrome Certificate Warning

Enter SelfSSL7. It enabled me to give the self-signed certificate a proper canonical name. In addition, it has the following features:

  • The site name upon which the SSL is to be configured on
  • The IP address
  • The port
  • Ability to add the certificate as a trusted root certificate
  • Export to a pfx file or cer file
  • One or more configurable common name
  • Configurable expiration date
  • Configurable key size

So, lets get into an example. I am going to host an enterprise app on a server called devserver-std. However, I am doing my development on my devmachine, which has a computer name PLAGUIS. I need to create a certificate which is issued to the server devserver-std. I need to do this in such a way that the machine to which the certificate is issued is the same as the name which I will be typing into the address bar of my browser i.e. devserver-std.

I fire up a command prompt (run as administrator) and run the following command:

SelfSSL7.exe /N cn=devserver-std /K 2048 /I /S=1 /V 500 /T /Q /X /F E:\MyNewDevCert.pfx /W opensesame


Lets go through that command, step by step:

/N specifies the common name. devserver-std is the name of the server upon which I want to install the certificate; the server which it is issued to.
/K specifies the key size.
/I adds the certificate to an IIS binding (but which one? See next item).
/S specifies the IIS site to which we want to add the binding. We need to know the site id for this. See this post for steps.
/V is the validity date for the certificate, with 500 (in our example) being the number of days.
/T adds the certificate to the user’s certificate store. This will make the SSL certificate trusted by the browser (except Firefox).
/Q overwrites the existing IIS SSL bindings. This is really handy. I don’t even have to open the IIS GUI and associate it with a binding for the site.
/X tells SelfSSL7 to export the certificate to a pfx file.
/F is the file location for the pfx file.
/W is the password for the pfx file.

With our better self-signed certificate in hand, we can now load the url for devserver-std in our browser and we will not experience the warning shown at the top of this post. Note, this does not work with Firefox. It does work with IE and Chrome.

* When a web browser receives an SSL certificate it usually checks the certificate for the following 3 things:

  1. Is the certificate still valid or is it already expired?
  2. Is the common name of the certificate the same as that which the user entered in the browser’s address bar?
  3. Does the browser trust the certificate or the issuer of the certificate?

Certificate-Related Stuff

This post is going to contain some basic information about the creation and management of Self-Signed Certificates and IIS. It is actually in anticipation of another post which I plan to publish next about the creation of such a certificate for development purposes.

I will presume you have IIS Manager 7 installed on your machine.
If you don’t, go ahead and install it.

Server-side Certificate Installation

To create a Self-Signed Certificate using IIS, execute the following steps:

  1. With IIS Manager open, click on the top-most node in the treeview which represents the root server
  2. In the IIS section of the right-hand pane, double-click on the Server Certificates icon
  3. In the far-right column, which has a heading Actions, click the link which says Create Self-Signed Certificate…
  4. Give your certificate a name as depicted below and follow the the rest of the wizard.Create Certificate

You will see that your new certificate has been added on your IIS instance. Note how it has a Certificate Hash. We will use that below.

Exporting the Certificate

Now that we have done the server-side stuff for our certificate, it is time to install it on a machine (the client-side stuff). The first thing we need to do is export a new certificate to a pfx file, which we will then import into our local certificate store.

  1. Right-click on the new certificate in the list and select Export from the context menu
  2. Give the exported certificate a name with a pfx file extension
  3. Enter and confirm a password for the certificateExport Certificate
  4. Click OK and the export will be complete.
Client-side Certificate Installation

The best way to manage certificates on your machine is by way of the Certificate Manager. You can open this by clicking the Start Menu and typing certmgr.msc. When the start menu has filtered itself down to 1 item (the Certificate Manager), push the enter button.
Certificate Manager
Next up, we will add the certificate to the Trusted Root Certification Authorities store. To do that, follow these steps:

  1. Expand the tree node labelled Trusted Root Certification Authorities in the left-hand pane
  2. Right click on the Certificates node which is exposed by virtue of step 1
  3. Select All Tasks > Import from the context menu
  4. Follow the wizard, selecting the pfx file which you created above.

You should be able to find your certificate easily enough after the import. There is a find dialogue in the Certificate Manager. Or another way of finding it quickly is ordering the items in the Trusted Root Certification Authorities > Certificate window by the Friendly Name column, which is the one that contains the name we gave it earlier.Trusted Root Certification Authority

We can now take a look at that certificate – double click on it in Certificate Manager. Navigate to the Details tab, scroll down to the Thumbprint property and there you will see that same hash that we observed in IIS when we first created it.Certificate Hash
IIS Hash View

Use the Certificate

To implement SSL in your website, you need to add an SSL binding for that site. To do that, follow these steps:

  1. Click on the website in IIS (mine is called CertTester)
  2. Stop the website
  3. In the Actions column on the far right, click the Bindings link
  4. Click the Add button
  5. Choose https from the top combobox
  6. Choose your certificate in the bottom combobox and click OK
  7. Start your website

You can now browse to that website by clicking the Browse *:443 (https) link in the Actions column.
You will see something wildly unsatisfying like the following IE screenshot:Certificate Warning IE
And here is the Chrome equivalent:Certificate Warning
You can then click:

  • Continue to this website (not recommended) (IE)
  • Proceed anyway (Chrome)

to continue through to the page content.

My next post will show you how to create a better Self-Signed Certificate for development purposes which results in no browser warning when you load the https address (for IE and Chrome only).

Determine the ID for a Site in IIS

IIS sites have an ID. There are a couple of ways for determining the ID of a site.

Using the IIS Manager

Open the IIS Manager and click on the site that you are interested in.
In the Actions column on the far right, click the Advanced Settings link (at the bottom in the screen shot):

Advanced Settings

Then, in the dialog which opens, the ID will be visible:

Site ID

From the ApplicationHost.config File

The sites element in the ApplicationHost.config files contain site elements, each of which has an id attribute. That is what you need to look for.

The ApplicationHost.config can be located in either of these places (depending on which web server the site is on, Express or normal):

  1. C:\Documents\[UserName]\Documents\IISExpress\config (for IIS Express)
  2. C:\Windows\System32\inetsrv\config (for IIS)

The Breakpoint will not Currently Be Hit

There are few things more frustrating than your breakpoints not being hit. In such cases, I’m sure you’ve all seen the following message when hovering over the breakpoint being missed:

The breakpoint will not currently be hit. No symbols have been loaded for this document.

The way that I like to resolve that (which has worked from me more often than not) is to find the pdb file which is actually loading the symbols and deleting it. Usually, that file is stale and by deleting it, you’re forcing the Build to create a new pdb file which will contain your fresh code.

Here are the steps involved.

  1. start debugging a project (press F5)
  2. go to the Debug menu, click the Windows submenu and select Modules (only visible when debugging, hence step 1)
  3. identify the DLL you are interested in and copy the path to the folder containing the symbol file (pdb) into the address bar of Windows Explorer

Then it’s up to you whether you just delete the single file, the folder containing it, or more. As it is a shadow copy, there is no harm in deleting the whole folder. In fact, I usually go several directories above that directory and delete that directory tree: