Accessing custom Performance counters & .NET security.  
Author Message
Pure Krome





PostPosted: Common Language Runtime, Accessing custom Performance counters & .NET security. Top

Hi folks,
i have a quick question about custom performance counters and .NET security.

On my local machine XP i can create and use custom performance counters in my c# application without a problem. all is perfect :)

When i deploy my application to another server i get securityExceptions with the performance counters.

So my question is this:-

1) Is it possible to use IN-LINE code to allow your program to get the 'proper' access to performance counters on the machine the application is running

2) If #1 == No, then is the only way to do this via manually allowing the user the application runs under special privaliges (eg. part of the admin account ).

3) if #1 == Yes, then could someone please provide some clues/hints/tutes about how to test this out

 

Hopefully someone has some answers out there :)

Cheers!




.NET Development19  
 
 
Greg Beech





PostPosted: Common Language Runtime, Accessing custom Performance counters & .NET security. Top

If you are creating performance counters from your application it must run as a local administrator, because it modifies the registry. Requiring administrator privileges is not great... Ideally you should create the counters at install time (check out PerformanceCounterInstaller class, and InstallUtil tool).

 
 
Pure Krome





PostPosted: Common Language Runtime, Accessing custom Performance counters & .NET security. Top

Heya greg - thanks for the reply.

At install time hmm. that would suck, especially considering there is not install time - it's a web app (currently). We'll at least for the UI layer currently. This means that when i create the website in IIS (which would be the equiv to an 'install time') then i would need to manually create counters. Besides this sucking if i need to have many machines for the webhosting (load balancing) it would also have some additional probs with how i use custom counters (which could be completly wrong). I delete the counter and re-create it 'refresh' the data. i suppose i could always just reset the values.

So what you're suggesting is that .NET has some intrinsic security in place -> eg. access to registry / performance counters, file IO, etc. and no matter what, you cannot type anything in the code to override this - you HAVE TO explicity do some tweaking outside of the app to setup access (Eg. CAS / code access security)..

yes



 
 
Greg Beech





PostPosted: Common Language Runtime, Accessing custom Performance counters & .NET security. Top

The barrier to creating the performance isn't .NET security, it's Windows security (.NET security is in addition to any intrinsic Windows ones, and cannot bypass it as it is subject to the same rules as any normal application). To create performance counters you need to modify a section of the registry (HKEY_LOCAL_MACHINE\System\...) which requires local administrator permissions to change, as it contains some of the most important settings to keep your computer running.

I agree this is irritating if you currently just use xcopy deployment, but unfortunately it is the route you will have to go down (or take the hugely insecure option of running the website as a user with local administrator privileges!). The good thing is that if your performance counters don't change, you will only need to create them once, and then on subsequent deployments they will still be there.

To reset the values on the counters, rather than recreating them you should just be able to set the RawValue property to zero.



 
 
Pure Krome





PostPosted: Common Language Runtime, Accessing custom Performance counters & .NET security. Top

Thanks heaps greg. I was worried u were going to say that (about the perf reg setting thing). I've already changed my code to using RawValue cause it's quicker than delete and creating IMO. (read: no real testing of that :P .. just a poor assumption).

I'll just have to unfortunatley doc this in the deployment guide, etc.

cheers Greg :) Nice to get some good and quick answers for a change.