Failed To Create AppDomain

Failed To Create AppDomain

I was playing around with Visual Studio Whidbey last night and had been altering my CAS security policy. I tested what I wanted and forgot all about it.

This morning, I came to play with some of my ASP.NET demo projects and found that when I ran up the local web server I couldn't get any page to display whatsoever (everything was coming back with a "page not found").

I couldn't understand this at all and (having the memory of a goldfish) it took me ages to get back to the point where I worked out when things had last been working and when they'd stopped. I could see in the VS debugger that when the little Visual Web Developer Web Server was coming up it was throwing a "Failed to create AppDomain" exception but I couldn't for the life of me think why that might be given that it'd been working fine up until about half a day ago.

After staring at it for a while I thought a bit about what might go wrong with creating an AppDomain and security suddenly hit me and I remembered that I'd tweaked with my settings last night.

A quick;

caspol -s off

showed me that I could now run up pages in the Web Developer Web Server and a quick

caspol -reset

fixed the problem.

One to bear in mind should you find this page whilst searching for "Failed to create AppDomain".

error during asynchronous processing

There was an error during asynchronous processing. Unique state object is required for multiple asynchronous simultaneous operations to be outstanding.

Solution: Guid.NewGuid()
cimMesgProc.exchangeMessageAsync(cimExMesg, Guid.NewGuid());

IPCChannel : Access Denied - Solution

From http://codebetter.com/blogs/sahil.malik/archive/2005/07/20/129505.aspx

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 -

or

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!!!