If you’ve ever used enumerations in .NET with bitwise operations, using the Flags attribute, you should be familiar with the following piece of code:

[Flags]
enum Permission
{
  None = 0,
  Read = 1,
  Edit = 2,
  Delete = 4,
  ChangePermission = 8,
  FullControl = Read | Edit | Delete | ChangePermission
}

Permission permission = Permission.Read | Permission.Edit;

if ((permission & Permission.Delete) == Permission.Delete)
  Console.WriteLine("Has permissions");

if (permission.HasFlag(Permission.Delete))
  Console.WriteLine("Has permissions");

It is finally over ! no more changes, no more bug fixes, no more uploads, the final version of the WCF 4 official Microsoft course is finally here. I can’t even fix a small typo I found in one of the chapters.

It is not my intention to complain about what I’ve gone through in the last eight months, but rather reminisce the last year of my life, like you reminisce going to boot camp (“Tironut”).

We started preparing for this course during November of last year, around the time of the PDC. Little did I know about what was going to happen to me in the months to come:

• One course - Developing Windows Communication Foundation Solutions with Microsoft Visual Studio 2010 (10263A).
• Two supported languages – The course was written for both Visual Basic and C#.
• Three different time zone I had to deal with – China (the testing team), India (the Microsoft’s course team), and the US (MS technical writer and MSL headquarters).
• Four versions of Visual Studio 2010 – beta 1, beta 2, RC, and RTM. It wasn’t so troublesome, until we found changes in the WCF API between the versions, which made us go over all the written material to fix everything.
• Five deliverables – Student handbook, Student CD, Hands-on labs, Lecturer slides, and Virtual Machines.
• Six major contributors to the course – Manu who wrote the lecturer slides and the Hands-on labs, myself who wrote the student handbook and several of the labs,  Sasha who was our mentor and technical writer, Ishai (the VP Training of Sela) who was in charge of the whole operation, and Amir and Alon who helped me with the handbook when I began to collapse under the weight of all the writing (see last bullet) .
• Seven Israeli lab testers – Sarit, Dolev, Nerya, Eli (x2), Ya’akov, and Avi.
• Eight modules – beginning with the principles of SOA, and ending with advanced topics in WCF such as workflow services and how to extend the WCF infrastructure.
• Nine nights without sleep – that’s what you get when you have a deadline that ends on 8am in US (Seattle’s) time zone.
• 10 weekends that my wife had to remind me that I was married to her and not to my laptop.
• And a student handbook with over 1300 pages (if you plan on doing this course, take in mind that you’ll have to carry a very heavy book back home).

We’ve had the pleasure of performing the first three session of this course here in Israel, and the fourth session will start at October, after the holidays, so you still got time if you want to register.

I think that out of the 3 years I’ve been working at Sela, this was one of the most interesting, difficult, enjoyable, satisfying work I ever did, and I would gladly do it again. So as our next project with MSL is just around the corner, I can only hope that it would be as enjoyable as the last one, and hopefully with less nights without sleep.

One last thanks – in the last post I wrote about the course I thanked all the people who helped in preparing this course and I forgot two important people – Avi Drucker our IT chief, and Roman Podobryanski from our IT crew.

Recently, I had the pleasure of passing the first Microsoft’s official WCF 4 course in Israel in its beta version (the course hasn’t been officially released yet). The course, developed by several of Sela’s experts in the past seven months, is part of the new set of courses Microsoft offers for .NET 4 and Visual Studio 2010.

It was a bit strange to give a course I’ve spend the last couple of months writing, but I enjoyed it very much, and the crowd (21 people) was great and asked a lot of interesting questions.

We (the Sela team) invested a lot of time and effort in writing this course, but it was a great experience and it taught me a lot about WCF 4 internals and how to work with the Microsoft Learning group (dealing with people from China, India, the United States, and Canada is quite difficult, taking into account the many time zones involved).

There were a lot of people from Sela involved in developing this course, some of them mentioned in the official documents, and some not, so this is a good time to mention them (sorry in advance if I missed someone) – Ishai Ram, Manu Cohen-Yashar, Sasha Goldshtein, Amir Zuker, Alon Fliess, Eli Dagan, Sarit Taib, and Baruch Toledano.

If you are interested in this course, it will be officially released on August 31, 2010, and will be given in Sela from September (exact dates and schedule will be set according to demand).

A few years ago I’ve stumbled on a very annoying scenario on my machine: I had used ASP.NET’s development server (the web server that pops up when debugging web applications in Visual Studio) while developing a web application and when I moved my web application to my local IIS, suddenly the culture of the thread changed from my local culture (he-IL) to a Greek culture (el-GR).

This was a few years ago, and took some time to solve, and I though I had the unfortunate luck of being the owner of a weird installation of Windows 2003 server, but in the last 24 hours I’ve encountered three different computers that had a similar problem, where some of them decided that IIS should run on an English culture (en-US) and some on a French culture (fr-CH).

First of all, the reason IIS runs on a different culture than the ASP.NET’s development server is that the ASP.NET’s development server runs under the account of the user that is currently logged in, while IIS’s application pools runs under a different account:

• For Windows XP with IIS 5.1, the user is ASPNET (a local account created by the .NET Framework)
• For Windows 2003 and on (Vista, 7, 2008 server) with IIS 6 or 7.X, the user is Network Service (unless specified otherwise in the application pool configuration).

The reason why the Network Service account uses a different culture can usually be traced back to the installation of the operating system. The culture of newly created accounts is decided according to the regional settings of the default user, and the Network Service account is set when the operating system is installed. So if you install your windows with the English - United States settings which is usually the default culture, the account will use the en-US culture. In my case, someone probably missed the Hebrew option and selected Greek by mistake.

To fix this problem, you’ll need to change the regional settings of these special accounts (network service, local service, aspnet etc…). Fixing this depends on your operating system:

1. For Windows Vista and on (7, 2008 server) this is quite easy, just follow the steps specified in the following link.
2. For Windows 2003 and XP, you’ll need to edit the registry manually:
   1. Open the registry, and export the “CURRENT_USER\Control Panel\International” branch. This branch contains the regional settings of the current user.
   2. Under the HKEY_USERS hive, for each SID (security identifier) and for the .DEFAULT user perform the following steps:
      1. Edit the exported registry file and set the path of the two sections to the account you want to fix. For example, to fix the network service account, change the “HKEY_CURRENT_USER\Control Panel\International” branch to “HKEY_USERS\S-1-5-20\Control Panel\International”.
      2. Double-click the reg file to import it to the registry.
      3. Return to the registry editor and check that the International branch was updated successfully for the account.

If you want to see which SID belongs to which builtin account, you can look at the following list.

After updating the settings you might want to restart your machine, or at the least recycle your application pool (or for IIS 5.1, kill the aspnet_wp process).

Hope this helps someone.

Additional: The scenario I wrote about describes a system that depends on the culture of the account that runs the application pool process. If you build a web application and you want it to use a specific culture, don’t become dependant on the culture of a specific account, instead use the <system.web>\<globalization> section and set the culture attribute to define the specific culture you want to use in the application. This way you can deploy your application to any server, without having to worry about mismatching server configuration.