.NET Configuration security Policies – Locked out!

Totally off topic from the usual drivel I write here, but I’ve just spent 3 hours with an aching head trying to find a solution to a problem on the internet, and although I found lots of people in the same situation, none of them seemed to have the answers.

So I post this up to help anyone who finds themself in the same position in the future. Apologies in advance to most of you; I think this is a pretty specialist subject…

While trying to get a .NET application to run with full Trusted permissions over a network, I stumbled upon a simple exchange between programmers, which concluded that I could fix the problem by changing the Security Policies area of the Microsoft .NET Framework Configuration Snap-in.

I proceeded to happily tinker with the settings, with the intention of setting Full Trust to all computers on my network.

Dimwit.

After I’d finished, I got a warning popup, outlining the fact that the changes I had just made might block me from accessing the very snap-in that I’d just used to make the changes; Stupidly, I thought “That won’t happen to me” and clicked ‘OK”

The computer equivalent, I guess, of locking yourself out of the car.

I went back into Visual Studio, only to find that I couldn’t run my .NET app anymore.

I couldn’t go to the .NET configuration snap-in either, I just got this message:

Failed to initialize snap-in

Panic set in, and I started to search the net.

I found one geezer with the same problem, but no answers.

Then another merry soul with the same problem and terrible English, who discovered that CASPOL was the answer; Switch security off with the CASPOL -s off command.

I looked into how to use CASPOL, and found a small article on how to disable security, but my particular security problems stopped me from accessing it. Head started to hurt…

Found an article on Microsoft that detailed how to reset security settings to default, but it didn’t feel right; so I carried on surfing. (Yeah programmers have intuition too)

Finally, as the guys left the office for the day, and my plans for spending the evening mastering my demos looked in tatters, I posted a desparate message on ole faithfull, the experts exchange, offerring a staggering 500 points to anyone who could come up with an answer.

And relax, and breathe….

And then it happened, as usual, just as I let go; There in front of me was a search result from Google, linking to another Microsoft article that I had previously missed. Oh wonderful 815163 – HOW TO: Troubleshoot Problems That Are Caused by the .NET Framework Security Configuration.

There in simple descriptions, were the paths for all the config files, usually controlled by the now-paralysed snap-in. All I had to do, according to the article, was get a copy of the config files from a machine with permissions that were OK, and copy them over, one by one, until I find the one with the problem.

5 minutes later, thanks to a copy of the security.config file on Al’s machine, I was up and running.

Bloody relief. I hope this post helps others that fall foul of the evils of the Microsoft .NET Framework Configuration snap-in. Let me know if it does; it’d be nice to know I’m not the only buffoon in the .NETdom.

Normal service resumes, thanks for bearing with me.

Advertisement

Adrock rockin’ the Bluze

Just heard some cool feedback from a random demo handout; Adrock from Hospital Records has been playing out the latest Bluze tunes at his events around Bristol; he’s lovin’ the tunes, and has asked for more. Along with the positive feedback from LTJ Bukem recently, all bodes well for the latest tracks.

I’ve a couple finished that I’m really pleased with now; I’ll post them up tonight, then send them out to a few DJ’s and check the response; Heads up Marcus Intalex, A-Sides, Bukem, TeeBee et al.