I'm working on a No-Touch Deployment program for use in our offices, and I ran accross an interesting problem. I made a setup file to give the assembly FullTrust based first on URL, then later on StrongName. (I know, not quite no-touch, but it does allow easy updating and synching with the server(s) ) When running under URL-based Evidence, everything worked fine. However, when I switched to StrongName-based Evidence, I started getting SecurityExceptions. And they weren't consistent... I could do execute a command (like writing a dataset to disk to check for issues) and it would go off fine, but a few steps (Steps, not lines, this is important) later, the exact same command would throw a security exception. Hey, how can I be getting a security exception when I've got FullTrust, huh? Huh?
Turns out, I was calling a web service asynchronously, and when I was in the callback function, somehow the thread I was in lost all it's permissions, and reverted back to Internet Zone permissions (which means no FileIO) A little more digging shows that other methods of threading don't have this problem, meaning I can kick off a new Thread, or do a QueueUserWorkItem, and everything's fine (calling the WebService Synchronously from the new thread), but I can't do anything in the Async Callback.
Just to add insult to injury, I revert the code back to URL-Based evidence, and everything works fine, no problems in all three threading mechanisms that I tried, including Async Callbacks from the Web Service, but StrongName based, and it fails.
After pulling my hair out for a few hours, I built a small test app with a dummy web service, and put it through the paces. Turns out that when using any locaiton based evidence (URL, Site, and Zone) everything is fine, but used FileBased-Evidence (StrongName and Hash) and it loses it's permissions under that one particular case.
Now how's that for an esoteric glitch?