Quickduck

Does this look familiar?

for (int i = 0; i < 100000; i++)
{
  // Do whatever.
  if ((i % 100) == 99)
    // every 100 cycles, do something special (eg display a progress update)
}

The problem with this is that (i % 100) is a very slow calculation for a computer that doesn’t think in base 10 (interestingly, (i % 128) is much faster). An obvious improvement would be to use another loop variable that we reset at the end of each period:

for (int i = 0, j = 1; i < 100000; i++, j++)
{
  if (j == 100)
  {
    // This will fire on i == 99, 199, 299, ...
    j = 0;
  }
}

But if you are willing to be a little flexible on the period length then there is another way that is faster than both of these approaches and which does not require an extra variable: bitwise AND.

The trick is that if the period length is a power of two (ie period length = 2ⁿ) then each and every combination of n bits appears exactly once in each period. Simply checking that the last n bits are all 0 will alert you to the end of each period – and bitwise comparison is just about the most elementary (and therefore fastest) thing a computer can do.

for (int i = 0; i < 100000; i++)
{
  // Do whatever.
  if ((i & 127) == 0)
    // This will fire on i == 0, 128, 256, 384, ...
}

In this example, ((i & 127) == 0) is functionally equivalent to (but still faster than) ((i % 128) == 0). Obviously you can test for ((i & 127) == 127) if you want to fire on 127, 255, …

So, to summarize:

1. First, see if you can use a period length that is a power of two so that you can use the bitwise test. It is particularly handy for periods of length two (ie firing on every other iteration) – use ((i & 1) == 0) rather than ((i % 2) == 0).
2. If your period length is not a power of two, use an extra variable to count the periods.
3. Don’t use (i % nn) on a big loop – it’s hideously slow.

The Stopwatch class

If you want to measure the performance of these techniques, or anything else for that matter, the System.Diagnostics.Stopwatch class is very handy. One of its great features is that it will use the hardware-based performance counter if one is available (in my experience, it almost always is). The hardware performance counter will give you precision of a few microseconds, whereas the DateTime.Tick property (based on the system timer) is accurate only to about 15ms, which isn’t precise enough for short events. Measuring an event is easy:

Stopwatch timer = Stopwatch.StartNew();
DoTheThingThatYouAreMeasuring();
timer.Stop();
Console.WriteLine(String.Format("It took {0:0.00} milliseconds.", timer.Elapsed.TotalMilliseconds));

Note the call to timer.Stop(). Without this, the clock is still ticking between the end of function call and the evaluation of the Elapsed property, which would add a microsecond or two to the reported time. I’d say that TotalMilliseconds should be accurate to two decimal places if you are using a high-res timer (check the Stopwatch.IsHighResolution property)

I might be a bit slow to the game here, but just in case you didn’t know, you can create a macro in VS2005 to collapse all the projects in the Solution View window. Freakin handy!

Download code: Partial Trust Code Access Security – Explained

Let’s start with an over-simplified, imprecise explanation of CAS. (NOTE: this discussion assumes that all your assemblies are strong-named.) The first thing to do is explain the levels of trust. “Fully trusted” code can do whatever the user can do (which might be limited if the user is not using a Windows admin account). “No trust” code can’t do squat. Anything in between is called “partial trust.” Obviously, there are many degrees of partial trust – the code might have almost no privileges at all, or it might be able to do everything except reading the registry or something. My own, simplified, understanding is that there are three main ways of causing code to run with partial trust:

1. If the assembly is loaded from a network share then it will run with the “LocalIntranet” permission set (by default this enforces a number of restrictions such as no registry, no file IO, limited reflection and so on).
2. If your assembly refuses one or more permissions (eg you declare that you don’t want to be able to perform reflection) then your assembly is by definition partially trusted.
3. You can configure your ASP.NET application to run with a particular trust level. In fact, Microsoft recommend running ASP.NET with “medium trust” if possible! This is defined in config files; “medium trust” means no registry, no reflection, no file IO outside your app’s virtual directory and a few other things).

Notice that an assembly might be fully trusted or partially trusted depending on the runtime circumstances. The assembly might be fully trusted if loaded from the C: drive, but will be partially trusted if loaded from a network share.

Next, a couple of handy definitions:

• Caller – Code that calls other code
• Callee – Code that is called by other code

So if method ClientMethod() calls method ServerMethod() then ClientMethod is the caller and ServerMethod is the callee.

If the calling method (the caller) is in an assembly that is running with partial trust then it is a “partially trusted caller.” In this case, if the callee’s assembly does not have the AllowPartiallyTrustedCallers (APTC) attribute then the called code will not run – regardless of the trust level of the callee’s assembly. You will get an exception.

And now for the demo. Obviously, there are many aspects to CAS; my idea is to show you a few basic ones to get you started. The demo has two strongly named assemblies: PartialTrustTest.exe and PartialTrustTestLib.dll. There is also a config file called PartialTrustTest.exe.config that is needed for one of the scenarios.

Scenario 1

Start by placing all the files together in a directory on your C: drive and running the exe. You will see a form with three buttons. They all do the same thing: they try to read the registry. The only difference is in the methods that they use to call the RegistryKey.OpenSubKey method:

1. Read the registry (local assembly) – calls a method in the EXE
2. Read the registry (from PartialTrustTestLib) – calls a method in the DLL (see code at bottom of email)
3. Read the registry after asserting permission (from PartialTrustTestLib) – calls a method in the DLL that asserts the right to read the registry (I’ll explain this below, but note that it has nothing to do with the Asserts used in testing)

Click each of the buttons in turn; you should find that they all work fine. This is because both assemblies are fully trusted.

Scenario 2

To set up this scenario, follow these steps:

1. Move the DLL to a network drive – let’s call that the U: drive and ensure you delete it from the C: drive so that we can be sure which one is being loaded!).
2. Open PartialTrustTest.exe.config in Notepad and uncomment the line.
3. Replace my username with yours in the href attribute.
4. Now run the EXE.

Button 1 is still OK, but the other two buttons throw a SecurityException. This is because the DLL is now running with the LocalIntranet permission set and as such it can’t read the registry.

The APTC attribute is not relevant here because the caller is fully trusted (it is the callee that is partially trusted).

Scenario 3

This is the most interesting one. To set up this scenario, follow these steps:

1. Delete PartialTrustTest.exe.config
2. Move the EXE to your network drive (U: drive)
3. Move the DLL back to your C: drive
4. Open the .NET Framework 2.0 Configuration utility (under Administrative Tools) and add the DLL to your GAC.
5. Now run the EXE

Note that the DLL has the APTC attribute, which it needs here because the exe is no longer running with full trust.

Button 1 fails, because the EXE is now running with the LocalIntranet permission set.

Button 2 fails. Why? The DLL is now fully trusted (it is in the GAC and it doesn’t refuse any permissions). But the EXE does not have RegistryPermission. This is an example of luring (the unprivileged EXE asks the privileged DLL to ask the .NET Framework, like a kid asking his older brother to buy beer on his behalf). To prevent this, the RegistryKey.OpenSubKey method demands that all its callers have RegistryPermission. This demand causes the CLR to do a ‘stack walk’, checking that each caller in the stack has the required permission.

Button 3 succeeds. This is because it calls a method in the DLL that ‘asserts’ RegistryPermission. Asserting a permission is like saying ‘trust me; I know what I’m doing: don’t worry if my caller(s) don’t have RegistryPermission because I have it and I promise not to do anything bad with it’.

Notice that the assertion didn’t help in scenario 2, because the DLL didn’t have RegistryPermission. Asserting a permission that you don’t have won’t get you anywhere.

To summarise:

Scenario	EXE	DLL	Btn 1	Btn 2	Btn 3
1	C: drive	C: drive	OK	OK	OK
2	C: drive	U: drive	OK	Fails – callee doesn’t have RegistryPermission	Fails – cal doesn’t have Registry Permission
3	U: drive	GAC	Fails – callee doesn’t have RegistryPermission	Fails – stack walk discovers that EXE doesn’t have RegistryPermission	OK – DLL asserts RegistryPermission
4	U: drive	C: drive (not GAC)	C: drive (not GAC)	No dice – you get an exception trying invoke the DLL; I think it’s not allowed in .NET

Using CAS correctly involves ensuring that your code can’t be used maliciously. Our DLL allows partially trusted callers and one of its methods asserts RegistryPermission. Once that DLL is installed in the GAC these two settings lower the security bar considerably. Any assembly that can run on our CLR can load our DLL and use our method to read the registry. Before adding the assertion we should (a) check our method carefully to make sure it can’t be used maliciously, and/or (b) apply extra restrictions to our method. The easiest way to restrict the method is to add a Demand to the method. This is where we demand that the callers meet a certain requirement (not the same one that we’re asserting, obviously – if they have that then there’s no point in asserting it!)

Here are the main actions associated with permissions:

• Assert – as explained above
• Demand – callee demands that all callers in the call stack meet a certain requirement
• Link Demand – callee demands that the immediate previous caller in the stack meet a certain requirement (faster than Demand, but less secure)
• Permission Request – this is where an assembly announces up-front the permissions that it needs in order to run (or those that would be nice to have). The alternative is to wait for runtime failure (as in my demo).
• Permission Refusal – assembly asks not be given a particular permission (because it does not need it – principle of least privilege). Refusing a permission will also make your assembly a partially trusted caller.

This article is already too long, but here’s one final point: don’t overuse Demand. For example in the demo there’s no need for our methods to demand RegistryPermission. We are calling the RegistryKey.OpenSubKey framework method, which already demands this permission. If we demand it ourselves then we are just forcing an extra stack walk that will hurt performance.

Links

The best articles I’ve found online are An Introduction to Code Access Security and Code Access Security in Practice.

Remember to remove the DLL from the GAC when you’re done.

Hope this helps. And have I got it right? Please let me know.

Code for button #2:

  public static void TestRegistryAccess()
  {
      RegistryKey test = Registry.LocalMachine;
      test.OpenSubKey("Software", true);
  }

Code for button #3:

  [RegistryPermission(SecurityAction.Assert,
                             Unrestricted=true)]
  public static void AssertRegistryPermissionAndTestAccess()
  {
      RegistryKey test = Registry.LocalMachine;
      test.OpenSubKey("Software", true);
  }

Download code: Partial Trust Code Access Security – Explained

Ever wanted to write code that you want executed while testing/debugging but didn’t want built into you production/release mode code?

Just pop the [Conditional("Debug")] attribute to your class or method and it won’t get compiled into your release version.

Nice and simple!

Also, do you get sick of debugging through superflous methods (eg. dumb constructors, etc) when stepping through your code just to get to the meaty stuff that you’re really interested in?

Stick the [DebuggerStepThrough] attribute on the class, property or method you want to skip over. It’s like automatically telling the debugger to step over and not step into.

In my current project, I’m doing some fancy-pants stuff to lookup UK addresses via a web service, then send them to the client using JSON. On the client end, I’m displaying the results in an ibox and then sending the results back to the main form. Woah!

The first challenge was getting the ibox to open and display the form correctly. I chose to use a hidden div as my “form”, and let the ibox display it on the screen when appropriate. It all seemed to work correctly, however when I tried to read the values out of the fields on the ibox form, it kept telling me they were empty!

After a lot of mucking around, cursing, and rude gestures directed at the computer – you know, the standard debugging drill – I worked out that when you use a hidden div as your ibox, it actually *clones* the entire InnerHTML of the hidden div! So in effect, you get *two* of every field with duplicate IDs. And, since the HTML generated by ibox goes at the *end* of your document, when you call document.getElementById, you get back the *first matching element*, which will always be the one that’s still safely hidden away in your form. Handy – not!!

But never fear, the solution is actually quite simple. You just have to create an external file containing your ibox form, and then use that as the HREF in your link:

<a href="FindAddress.aspx" rel="ibox&height=400" title="Find an address">Find address</a>

Ahh, finally things started working properly! So now that I could read the postcode that the user entered, I wanted to hit a handler to…. err… “handle” the web service request. To do that, I used prototype.js – a javascript library with a whole bunch of wicked cool functionality (all of which is way beyond the scope of this article). Check it out -to execute a cross browser friendly AJAX request, you simply do this:

  var url = "Handlers/FindAddressHandler.ashx?Id=" + id;
  new Ajax.Request(url, {
    onSuccess: OnAddressFound,
    onFailure: OnError
  });

Of course, you can inline the callback functions, but I wanted to separate them for readability. Anyway, the next part was setting up the FindAddressHandler. I won’t go into too much detail here as it’s just a standard implementation of IHttpHandler which then hits a web service. The part I want to talk about though is writing back the address object using JSON. A dude named Jason Newton King has written a brilliant library called Json.NET which makes life a hell of a lot easier!

Basically, you just have to create a JsonWriter, then serialise the properties of your object that you want to send back to the client. So in my case with an Address object (stored in local variable “address”):

StringBuilder builder = new StringBuilder();
using (JsonWriter writer = new JsonWriter(new StringWriter(builder))) {
  writer.WriteStartObject();
  writer.WritePropertyName("PostCode");
  writer.WriteValue(address.Postcode);
  writer.WritePropertyName("Address1");
  writer.WriteValue(address.Line1);
  writer.WritePropertyName("Address2");
  writer.WriteValue(address.Line2);
  writer.WritePropertyName("Address3");
  writer.WriteValue(address.Line3);
  writer.WritePropertyName("PostalTown");
  writer.WriteValue(address.PostTown);
  writer.WriteEndObject();

  writer.Flush();
}

_context.Response.AddHeader("X-JSON", builder.ToString());

Easy, right? So the thing to note here, besides how simple it is to persist your object in JSON, is that I’m sending back the JSON string in a response header called “X-JSON”. Now back on the client side again – one of the bonus features of Prototype is that it automatically interprets whatever is in the “X-JSON” header, and builds your objects for you! So, here’s the code I wrote for my client-side callback:

function OnAddressFound(transport, address) {
    $("txtAddress1").value = address.Address1;
    $("txtAddress2").value = address.Address2;
    $("txtAddress3").value = address.Address3;
    $("txtPostCode").value = address.PostCode;
    $("txtPostalTown").value = address.PostalTown;

    hideIbox();
}

The first argument – transport – is the XmlHttpRequest object which was used. (You can find a great document which outlines the properties of the XmlHttpRequest object on the Apple Developer Connection website). The second argument is the object which Prototype interpreted from the X-JSON response header. You can see also that prototype implements a function – $ – which is effectively a suped-up version of document.getElementById.

Using all of these technologies together was surprisingly easy! I’m super impressed with how you can grab so many rich frameworks to enhance your websites, all for free!