07 Mar 2007
Originally posted on my old MSDN blog
Recently had some issues setting up some custom perf counters to install and run from an ASP.Net page that I thought I'd share.
We began by using the information in http://support.microsoft.com/kb/555129 which states:
"It turns out that the permission set required to update performance counters is much smaller than running as an Administrator or Power User. In the registry key HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib, set the Access Control List so that the necessary user has Full Control. In our original example, the ASPNET user would be granted Full Control, but access can be granted to anyone who needs to update a performance counter."
However I mistakenly assumed that as that setting those permissions would also enable the counters to be created, which is wrong. From the comments in http://objectsharp.com/cs/blogs/bruce/archive/2003/12/05/222.aspx we found out it's more complicated than that:
"For 2003 I did the following changes:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib\009 - Added permissions for Network Service
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services - Added permissions for Network Service
C:\WINNT\system32\perf*009.dat - Added full permissions for Network Service on all matching files.
After that it worked like a charm."
We didn't try the above solution, as after a little more thinking we gave up trying to install the counters on the fly and wrote some code that runs as part of the site installation (and hence runs as an Administrator which means it will definitely have permission to create the counters).
It's a lot cleaner doing it that way, and changes less permissions on the server which is always a good thing from a security point of view.
If you're interested. the code uses the System.Diagnostics.CounterCreationData class to create the counters on the web server if they're not already installed - see the documentation if required as it's pretty easy to use.
18 Dec 2006
Originally posted on my old MSDN blog
Is this a well known trick and I'm just completely out of touch? Probably, but I was very excited when I found out that holding down CTRL when clicking a link in IE7 will open the link in a new tab.
To think all this time I was using right click and then "Open In New Tab". I guess my productivity has just gone up by 0.1% :-)
14 Nov 2006
Originally posted on my old MSDN blog
I was struggling to install some new software (the superb new Live Local 3D view - I had an early internal beta already installed) and then remembered a handy tip.
To find all currently installed MSIs, use the (hidden) folder c:\windows\Installer. It gives you a nice browseable view of the current state of the system, and can be invaluable in tracking down what the system currently thinks is installed.
01 Nov 2006
Originally posted on my old MSDN blog
Reasonably often I find myself writing a mini-test harness when I want to run a console application and time how long it takes.
I always end up looking back through old code to remember how to do it, so this makes it very suitable for posting here. It's not particularly revealing or complicated code, but hopefully it may save you a few minutes if you want to do the same thing.
Here's the code:
Stopwatch timer = new Stopwatch();
Process process = new Process();
// Set up the process information
ProcessStartInfo info = new ProcessStartInfo();
info.UseShellExecute = true;
info.CreateNoWindow = false;
info.WindowStyle = ProcessWindowStyle.Minimized;
info.FileName = "YourConsoleApp.exe";
info.RedirectStandardOutput = false;
process.StartInfo = info;
// Start the timer, and then the process
timer.Start();
process.Start();
process.WaitForExit();
timer.Stop();
Console.WriteLine("Running application took {0} seconds", timer.ElapsedMilliseconds / 1000);
01 Nov 2006
Originally posted on my old MSDN blog
As I've posted before, I really don't like the Visual Studio interface for running unit tests. This is mainly because it's not as clean (no hierarchy tree or big green line!), makes a copy of the files every time a test is run and is pretty slow (probably because of the file copies).
However I was very happy to find out the latest version of NUnit (http://www.nunit.org) supports Visual Studio Unit tests, so you can just point the Nunit GUI at VS Unit Test DLLs and run the tests there.
Both interfaces have their pros and cons, and I tend to go back and forth between VS (especially when debugging through the tests) and NUnit (when I want to run tests quickly) but it's definitely a big productivity gain being able to choose the most productive UI.
