After updating the TFS 2010 client from Beta2 to RC on my SharePoint development machine I found that I couldn’t control IIS using IISRESET, with a message usually of the following format…

Attempting stop…

Stop attempt failed.

The system cannot find the file specified. (214794202, 80070002)

As anyone who does SharePoint development knows, not being able to restart IIS periodically is a bit of a annoyance and I didn’t want to keep going into IIS Manager to do this.

Turns out this is a problem with uninstalling Microsoft .NET 4.0 Beta 2 and the solution is to repair the Microsoft .NET Framework 4 Client Profile.

Sometimes Excel doesn't behave as you expect and you learn something. Excel is complex as Joel Spolsky pointed out last week.

Quite often clients will send data updates in Excel spreadsheets as this is the format they are used to working with; even if you as a programmer are not. One such workbook I have worked with this week had a worksheet with formulas to increment id's. The problem was the id's were not incrementing, even though the formula was correct.

After some investigation it turned out that the Calculation was set to manual (Tools -> Options -> Calculation Tab in Excel 2003), as shown below -

"Automatic calculation" mode means that Excel will automatically recalculate all open workbooks at each and every change, and whenever you open a workbook - which is what I was expecting and wanted (if you are in "manual calculate" mode pressing F9 will update the formulas).

This "manual calculate" behaviour is by design and Excel tries to help you realise this by updating the status bar with the word "Calculate". In fact, as this behaviour is set by the first workbook opened, it may seem to randomly change depending on the sequence the workbooks are opened, and their settings.

As Joel Spolsky said in his article...

"Every checkbox, every formatting option, and every feature in Microsoft Office has to be represented in file formats somewhere."

Normally you don't encounter permission errors when installing to the global assembly cache (GAC). Today I did, even though I was logged on as a member of the administrators group (not that being an administrator is a guarantee of much).

If you navigate using Windows Explorer to %windir%\assembly, what you see is the view displayed by the assembly cache viewer. If you go up a folder and right click the assembly folder and click properties you won't see the security tab you normally see. The assembly cache viewer (Shfusion.dll) is a Windows shell extension that affects how Windows Explorer lets you view the folder.

You have two options at this point -

1. Alter the behaviour of Windows Explorer with regard to the GAC. Hannes Pavelka gives a nice post on how to do this. 

2. Open a command window and use Cacls. Cacls allows you to both view and alter the permissions on any folder, and subfolders, for any account, including the GAC, as long as you are running it as an account that has permission to do so. Sounds like a russian doll of permissions, doesn't it?

I chose option 2 as I don't like altering the expected behaviour. This can cause confusion further down the line.

In order to get round the installation issue I ran the following at a command window -

CACLS %WINDIR%\assembly /e /t /p administrators:W

this gave members of the administrators builtin group write permissions on the GAC, and the subfolders, and sorted out the installation issues.