Allright folks (I'm sleeping after this one).
So .NET 2.0 Remoting has this new fancy channel called IPC Channel, basically this addresses the biggest criticism of .NET 1.1 remoting that for communication on the same box, you still need to go over the TCP stack (unless of course you made it even worse and used the HttpChannel instead).
I have blogged before about IPC Channel about how awesome the performance implications were. But here's the deal, put the client in an ASP.NET app talking to a windows service, and bingo - Access Denied. Well this happens because your windows service is running as a different user, and ASPNET as another user. In fact, if instead you were to use a console application running as administrator (and if that is you in development, then shame on you), and try and connect to the Windows Service - you would still get that error (assuming the service is running as a different user).
So whats it mean Well, you simply need to say/express to the framework "This group of users has access to this IPC Channel" when you declare the server channel. This can be done in 2 ways.
1. Config file - <channel ref=ipc portName=testPipe authorizedGroup=authorizedUserGroupName />
2. The constructor of IPCServerChannel that accepts properties as IDictionary - pass in a authorizedGroup property in the hashtable with value set to the windows group (authorizedUserGroupName as per the above) that has access to the IPC Channel. Now make sure your ConsoleApp or ASPNET Application pool is running as a user that is a part of that windows group and bingo -
NO MORE ACCESS DENIED :-) . Heh !! cool huh
Allrighty, I'm off to snoresville!!!