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".

Serwery proxy

Dla użytkowników TPSA
217.98.20.195:8080 (w3cache.tpnet.pl)
217.98.20.20:8080 (w3cache2.tpnet.pl)

Dla użytkowników Dialogu
62.87.244.34:8080 (proxy.dialog.net.pl)

Dla użytkowników TkTelekom
82.160.0.10:8080 (w3cache.tktelekom.pl)
213.199.225.43:8080 (w3cache2.tktelekom.pl)

Dostępne dla wszystkich Polaków
193.219.28.144:8080 (w3cache.icm.edu.pl)
193.219.28.146:8080 (w3cache2.icm.edu.pl)

How to use makecert.exe

How to use makecert.exe to create a self-signed test certificate that can be used with IIS for SSL

Problem: Special options must be specified with makecert.exe, to create a self-signed certificate that can be used with IIS (Microsoft Internet Information Server).

Note: Microsoft recommends to install and use the "Certificate Server" to generate an SSL test certificate (Q216907), instead of using makecert.exe. But using makecert is simpler.

Solution:

The following command can be used to create and import a self-signed SSL test certificate:

makecert -r -pe -n "CN=www.yourserver.com" -b 01/01/2000
-e 01/01/2036 -eku 1.3.6.1.5.5.7.3.1 -ss my -sr localMachine
-sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12

To install this certificate in IIS 5.0, open the IIS "Web Site Properties", "Directory Security", "Server Certificate...", "Assign an existing certificate" and select the new certificate from the list.

Note: Older versions of makecert.exe do not support the "-pe" option, which makes the private key exportable. If you have an old version of makecert.exe, you can omit the "-pe" option, but then the certificate cannot be exported including the private key.

(The October 2002 version of the Platform SDK (build 3718.1) contains a new version of makecert.exe (5.131) that supports the "-pe" option. The .NET Framework SDK 1.0 of 2002-03-19 contains an old version of makecert.exe that does not support the "-pe" option).

If the private key is exportable, you can export the certificate together with the private key into a PFX (PKCS #12) file as described in Q232136.

Note: SSL server certificates for IIS are stored in the "Personal" ("My") certificate store of the "computer account" ("localMachine"). The "Certificates" snap-in of the Microsoft Management Console (mmc.exe) must be used to manage these certificates. The normal certificate management window (accessible via "Internet Properties" / "Content" / "Certificates" or via "Control Panel" / "Users and Passwords" / "Advanced" / "Certificates") cannot be used.

Note: To create a key with more than 512 bits, use the "-len" parameter of makecert.exe.

http://joe.truemesh.com/blog/000390.html

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