One of the projects I work on has some dynamic culture-aware currency formatting stuff and we, of course, have tests around that.

I’m in the process of moving our build from Windows Server 2008R2 to Windows Server 2012 and I found that a lot of our tests are failing. I didn’t change any of the code, just updated a couple of lines of build script. What gives?

It appears Windows Server 2012 has different culture settings installed than the previous platforms. Per the documentation, “Windows versions or service packs can change the available cultures” and it appears I’m getting hit by that.

I cobbled together a quick program to do some testing using LINQPad.

var nfi = CultureInfo.CreateSpecificCulture("as-IN").NumberFormat;
Console.WriteLine("{0}:{1}:{2}",
  nfi.CurrencyNegativePattern,
  nfi.CurrencyPositivePattern,
  nfi.CurrencySymbol);

The results were the same on Windows 7 and Windows Server 2008R2 but different on Windows Server 2012:

Notice the positive pattern is different? Yeah. That’s not the only culture or item that differs across the installed cultures.

So… now I have to figure out a way to craft our tests to be a little more… dynamic(?)… about the expected value vs. the actual value.

It was raining this year and I think that put a damper on the trick-or-treat count. We also didn’t put out our “Halloween projector” that puts a festive image on our garage, so I think the rain, combined with lack of decor, resulted in quite a bit fewer kids showing up. When it was busy, it was really busy; but when it wasn’t… it was dead.

The graph is starting to look like a big mess so I will probably start keeping more like “the last five years” on there. I’ll also keep an overall average graph to keep the bigger picture.

The table’s also starting to get pretty wide; might have to switch it so time block goes across the top and year goes down.

Cumulative data:

NDepend is awesome and I use it to analyze all sorts of different projects.

One of the nice things in NDepend is you can define queries that help qualify what is your code (JustMyCode) and what isn’t (notmycode).

I’ve seen two challenges lately that make rule analysis a bit tricky.

• async and await: These generate state machines on the back end and NDepend always flags the generated code as complex (because it is). However, you can’t just exclude the code because basically the generated state machine moves your code in there, so excluding the state machine will exclude some of your code.
• Anonymous types: I see these a lot in MVC code, for example, where the anonymous type is being used as a dictionary of values to truck around.

I haven’t figured out the async and await thing yet… but here’s how to exclude anonymous types from the JustMyCode set of code:

First, in the “Queries and Rules Explorer” window in your project, go to the “Defining JustMyCode” group.

In there, create a query like this:

// <Name>Discard anonymous types from JustMyCode</Name>
notmycode
from t in Application.Types where
t.Name.Contains("<>f__AnonymousType")
select new { t, t.NbLinesOfCode }

Save that query.

Now when you run your code analysis, you won’t see anonymous types causing any violations in queries.

I develop using an account that is not an administrator because I want to make sure the stuff I’m working on will work without extra privileges. I have a separate local machine administrator account I can use when I need to install something or change settings.

To make my experience a little easier, I add my user account to a few items in Local Security Policy to allow me to do things like restart the machine, debug things, and use the performance monitoring tools.

In setting up a new Windows 2012 dev machine, I found that the domain Group Policy had the “Shut down the machine” policy locked down so there was no way to allow my developer account to shut down or restart. Painful.

To work around this, I created a shortcut on my Start menu that prompts me for the local machine administrator password and restarts using elevated credentials.

Here’s how:

Create a small batch file in your Documents folder or some other accessible location. I called mine restart-elevated.bat. Inside it, use the runas and shutdown commands to prompt for credentials and restart the machine:

runas /user:YOURMACHINE\administrator "shutdown -r -f -d up:0:0 -t 5"

The shutdown command I’ve specified there will…

• Restart the computer.
• Force running applications to close.
• Alert the currently logged-in user and wait five seconds before doing the restart.
• Set the shutdown reason code as “user code, planned shutdown, major reason ‘other,’ minor reason ‘other.’”

Now that you have the batch file, throw it on your Start menu. Open up C:\Users\yourusername\AppData\Roaming\Microsoft\Windows\Start Menu and make a shortcut to the batch file. It’s easy if you just right-drag the script in there and select “Create shortcut.”

Give the shortcut a nice name. I called mine “Restart Computer (Elevated)” so it’s easy to know what’s going to happen.

I also changed the icon so it’s not the default batch file icon:

• Right-click the shortcut and select “Properties.”
• On the “Shortcut” tab, select “Change Icon…”
• Browse to %SystemRoot%\System32\imageres.dll and select an icon. I selected the multi-colored shield icon that indicates an administrative action.

Finally, hit the Start button and go to the list of applications installed. Right-click on the new shortcut and select “Pin to Start.”

That’s it - now when you need to restart as a non-admin, click that and enter the password for the local administrator account.

I was setting up a new dev machine the other day and whilst attempting to install TestDriven I got a popup complaining about a BEX event.

Looking in the event log, I saw this:

Faulting application name: TestDriven.NET-3.8.2860_Enterprise_Beta.exe, version: 0.0.0.0, time stamp: 0x53e4d386
Faulting module name: TestDriven.NET-3.8.2860_Enterprise_Beta.exe, version: 0.0.0.0, time stamp: 0x53e4d386
Exception code: 0xc0000005
Fault offset: 0x003f78ae
Faulting process id: 0xe84
Faulting application start time: 0x01cfe410a15884fe
Faulting application path: E:\Installers\TestDriven.NET-3.8.2860_Enterprise_Beta.exe
Faulting module path: E:\Installers\TestDriven.NET-3.8.2860_Enterprise_Beta.exe
Report Id: df1b87dd-5003-11e4-80cd-3417ebb288e7

Nothing about a BEX error, but… odd.

Doing a little searching yielded this forum post which led me to disable the Data Execution Prevention settings for the installer.

• Open Control Panel.
• Go to the “System and Security” section.
• Open the “System” option.
• Open “Advanced System Settings.”
• On the “Advanced” tab, click the “Settings…” button under “Performance.”
• On the “Data Execution Prevention” tab you can either turn DEP off entirely or specifically exclude the installer using the whitelist box provided. (DEP is there to help protect you so it’s probably better to just exclude the installer unless you’re having other issues.)