Why is the ErrorCode property of type int?

Once in a while you need to handle an framework exception that has an ErrorCode property. The HttpException and COMException classes for example have such a property. The problem here is that the Message property contains the ErrorCode in hex but the ErrorCode property is of type int which is signed. It is probably int to be CLS complaint or something but it always gives me a headache!

Everytime I do something like:

const int DISP_E_BADINDEX = 0x8002000B;  // Cannot assign uint to int

But that fails because 0x8002000B is an unsigned value but that value is just copied from the Message property text. So now you first need to convert it to a signed int like the following:

const int DISP_E_BADINDEX = (int)0x8002000B;  // Cannot cast uint to int use unchecked keyword.

*Sigh* doesn’t this give you a headache? So the final code is:

unchecked
{
    const int DISP_E_BADINDEX = (int)0x8002000B;
    ….
}

But that is also not very neath as the constant int value can now only be used in one method while in most scenarios this value is declared as a constant data member. So now I just start Snippet compiler and dump the signed integer result of the cast and copy paste that in my code like the following line:

const int DISP_E_BADINDEX = -2147352565; // HRESULT 0x8002000B

No bloated code but this.. It would have been nice if it was possible to directly assign such a hex value to a int.

OT: Yamaha KX8 – My new DAW addition

In my free time I often play some notes on my E-MU X-Board 61. It has 16 controllers, direct patch select and 4 zones that can be layered. But yesterday I bought a new board. The Yamaha KX8 with has 88 weighted keys, just 4 controllers but they are digital and can be set with midi in which cannot be done with the X-Board.

The feel is really excellent especially for its price. I was comparing it with the Fatar/Studiologic SL990 XP/PRO, the CME UF80 and the M-Audio keystation 88 pro. If you are searching for a nice weighted board with loads of controllers then the keystation is the winner but it makes quite some noise and the feel doesn’t even come close to a real piano. The CME UF8 is also a very nice board but makes even more noise but has a much better piano feel.

The Yamaha KX8 won because:

  • Has a very good piano feel for its price
  • Its an Yamaha and they create quality digital piano’s so they know how a keybed should feel.
  • Has a black finish instead of the silver/aluminum
  • It is silent

I nice picture of the board in my computer room:

Yamaha KX8 past net

As you see there isn’t a lot of room left.

Long delay at service startup caused by WebRequest.DefaultWebProxy

Today I was resolving an issue where some of our services had a very long startup time which only occurs during booting and not at a service start/restart from the service snap-in. In other words, when I restart the service when the system is finished booting than we experience no delay.

After debugging through logging I found out that the System.Net.WebRequest.DefaultWebProxy was causing our delay of almost two minutes! The problem is that this is a property! Property access should be fast so this should have been System.Net.WebRequest.GetDefaultWebProxy().

After searching (aka. googling) it seems to be something related to WPAD which does automatic proxy server detection. I tried overriding the proxy configuration by adding the following to the app.config but without any success.

<system.net>
   <defaultProxy useDefaultCredentials=”True”>
      <proxy useSystemDefault=”False” autoDetect=”False”/>
   </defaultProxy>
</system.net>

Without retrieving the default configured .net proxy server the service starts very fast.

I guess I’m dependant on one or more services but didn’t find any except “Tcpip” and “Dnscache” and making our service dependant on these services didn’t help at all.

The conclusion is not to use “WebRequest.DefaultWebProxy” in a service as it will delay your service startup time. WebRequest.DefaultWebProxy is probably meant to be used in desktop applications.

I now created our own version of an IWebProxy locator that can be configured to use the WebRequest.DefaultWebProxy or any other implementation. For example, we have a couple or services where the settings should be saved between uninstalls, upgrades, etc. In our custom implementation we use a we use isolated storage for platform wide settings.

Abusing IsInRole(..) is not done

Rockford Lhotka has writen about permission-based authorization versus role-based authorization. He describes how he is abusing the principal IsInRole(..) method. This is definitely wrong and should never be implemented that way! Besides that it could result in serious performance issues! Image a system with a million objects then storing all permissions allowed to those objects as a role would become disastrous.

A user identity and its role(s) is a pretty lightweight set of a user in a certain domain. This is called authentication. The identity can even be an identity from an external source trusted within this domain.

The other set of data is which users or roles/groups are allowed to do what and is called authorization. An application can support one or more types of authentication for a single user to now who he or she is or what role it has. Often identify management is now managed within an application like for example usage of Windows users, OpenID, Microsoft Passport, etc. and which roles such an identity has depends on the provider. For example Windows roles are the Windows groups.

The .net ‘role’ should be seen as ‘group’ when the ‘role’ is an external managed entity or be seen as ‘role’ if its definition is defined within the application. With this in mind you get the following relation chain:

Identity <-> Group(s) <-> Roles <-> Tasks/Permissions

When the ‘group’ is managed within the application you often see that group and role are merged in one thus resulting in the .net role definition.

Most frameworks allow relations to be defined between all four entities.

  • Identity can be linked to a groups, roles and/or tasks
  • Groups can be linked to identities, roles and/or permissions
  • Roles can be linked to identities, groups and/or tasks
  • Tasks can be linked to identities, groups and/or roles

But this would be a very bad security design. Normally an application has a lot of defined tasks. On top of that roles can be defined

lets take entity manager that has four CRUD operations:

  • Administrator is allowed to do create, read, update and delete
  • Moderator is allowed to do read and update
  • Normal user is only allowed to do read.

Here we have four tasks that resulted in three application roles. These application roles can then be assigned to a user and/or a group.

So what to do in situations where you need a more fine graded solution like a file system having loads of entries and defining permissions that can differ between all those entries? Implement it like is also done in the file-system! Store that authorization information as part of your data.

Key to success here is to think about what features you need like:

  • permission inheritance
  • deny permissions
  • loops in your hierarchy.

Try not to add this meta data in the same data structure as the data that you store as this will make your security model not flexible for possible future requirements (and trust me, these WILL come!) but if performance is crucial then this is probably the only solution. But still always try to use something like the following pseudo code!

class BlogPost
{
    …
}

[Flags]
enum BlogPostPermissions
{
    Create = 1,
    Delete = 2,
    Update = 4,
    Read = 8
}

interface BlogPostSecurityManager
{
    SetPostSecurity(
          IIdentity identity,
          BlogPostDTO post,
          BlogPostPermissionspermissions);
}

 

Now we have clearly seperation of responsibilies. The blog post doesn’t contain any security related data.

COM Exceptions and the ErrorCode property

Today I fixed a nasty bug in one of our applications. The first version had something like the following code construction:

 

   Type t = Type.GetTypeFromProgID(“My.ComComponent”, serverName);
   var component = (ComThingie)Activator.CreateInstance(t);
   SubItem item = component.Indexer[itemName]

The application was throwing an COMException here that was catched in a general COMException like:

   SubItem item;
   try{ item = component.Indexer[itemName]; } catch(COMException cex) { item = null; }

But this would catch *all* COM exceptions so I altered it to the following code:

   SubItem item = null;
   try{
      item = component.Indexer[itemName];
   }catch(COMException cex) {
      if(cex.ErrorCode != 0x8002000B) throw; //DISP_E_BADINDEX
   }

Code compiles fine but at runtime this fails and the question was why on earth is this failing? Turns out that the ErrorCode property is of type int and not uint that I expected. What happens now is that the negative value of ErrorCode is now compared with the positive value 0x8002000B. I needed to convert the value 0x8002000B to the int value -2147352565.

   const int DISP_E_BADINDEX = -2147352565;
   SubItem item = null;
   try{
      item = component.Indexer[itemName];
   }catch(COMException cex) {
      if(cex.ErrorCode != DISP_E_BADINDEX ) throw; //DISP_E_BADINDEX
   }

Now the exception handling is working as expected.

Hope this helps a couple of souls 😉

  • Recent Posts
  • Recent Comments
  • Archives
  • Categories
  • Meta