<p>I use MS SQL Server 2005 application roles in an application. I execute the <code>sp_setapprole</code> to start the SPs role and to finish  <code>sp_unsetapprole.</code></p>
<p>&quot;<strong>connection pooling doesn't work</strong>&quot; with application pooling, and there is no way to react on connection &quot;<strong>disconnect event</strong>&quot; (execute <code>sp_unsetapprole</code> just before disconnection).</p>
<p>I decide to call <code>sp_setapprole</code> at the start of all my SPs and call <code>sp_unsetapprole</code> at the end of all SPs.</p>
<p>Have you used SQL application roles? What are your XPs? What about performance hits?</p>

I have not used app roles before, but from what I know about the perf hit is that after setting the application role there is no way to revert to the prev. security context. Thus the connection cannot be reused in pooling. This alone is a huge perf. hit that forces you to think twice about using app roles.
However, the docs say that starting from SQL Server 2005 there is a way to remember the original security context in a kind of cookie returned from sp_setapprole and after that use sp_unsetapprole to revert back to it. So the pooling should work again. If I were you, I would compare the perf. with a couple of simple statements/sprocs.
Any reason you don't use the standard ASP.NET membership API on the application level instead of app roles?