StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
4881946
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
2
CommunityOwnedDate
CreationDate
2011-02-03T01:49:24.803
FavoriteCount
0
LastActivityDate
2011-02-03T01:49:24.803
LastEditDate
LastEditorUserId
0
OwnerUserId
365416
ParentId
4858285
PostTypeId
2
Score
9
ViewCount
0
LastEditorDisplayName
text
Body
So my co-worker and I worked this out, finally, with a bunch of help from Reflector. The main problem is that HttpContext.Current is null when accessed via a remoting call. The HttpContext.Current property is stored in an interesting manor. A few nested setters down, you reach <code>CallContext.HostContext</code>. This is a static object property on a <code>CallContext</code>. When the CallContext is set, it first checks if the value is an <a href="http://msdn.microsoft.com/en-us/library/system.runtime.remoting.messaging.ilogicalthreadaffinative.aspx" rel="noreferrer"><code>ILogicalThreadAffinitive</code></a>. <ul> <li>If it is, it stores the value in the current thread's <code>LogicalCallContext</code>.</li> <li>If it's not, it stores the value in the current thread's <code>IllogicalCallContext</code>.</li> </ul> <code>HttpContext</code> is not an <code>ILogicalThreadAffinitive</code>, so it is stored in the <code>IllogicalCallContext</code>. <hr> Then, there's remoting. We didn't dig too far in to its source, but what it does was inferred from some other functions. When a call is made to a remote object from a different AppDomain, the call is not directly proxied to the original thread, running in the exact same execution context. First, the <code>ExecutionContext</code> of the original thread (the one containing <code>HttpContext.Current</code>) is captured, via <code>ExecutionContext.Capture</code> (more in this in a bit). Then, the <code>ExecutionContext</code> returned from <code>Capture</code> is passed as the first argument to <code>ExecutionContext.Run</code>, esentially forming the code: <pre><code>Delegate myRemoteCall; //Assigned somewhere else in remoting ExecutionContext.Run(ExecutionContext.Capture(), x => { myRemoteCall() }, null); </code></pre> Then, completely transparently, your code in the remote object is accessed. Unfortunately, <code>HttpContext.Current</code> is not captured in <code>ExecutionContext.Capture()</code>. Here lies the essential difference between an <code>IllogicalCallContext</code> and a <code>LogicalCallContext</code>. <code>Capture</code> creates a brand-new <code>ExecutionContext</code>, essentially copying all of the members (such as the <code>LogicalCallContext</code>) in to the new object. But, it does not copy the <code>IllogicalCallContext</code>. So, since <code>HttpContext</code> is not an <code>ILogicalThreadAffinative</code>, it cannot be captured by <code>ExecutionContext.Capture</code>. <hr> The solution? HttpContext is not a MarshalByRefObject or [Serializable] (probably for good reason), so it cannot be passed in to the new AppDomain. But, it can cross <code>ExecutionContext</code>s without problem. So, in the main AppDomain's MarshalByRefObject which is given as a proxy to the other AppDomain, in the constructor give it the instance of <code>HttpContext.Current</code>. Then, in each method call of the new object (unfortunately), run: <pre><code>private HttpContext _context; private void SyncContext() { if(HttpContext.Current == null) HttpContext.Current = _context; } </code></pre> And it will be set without problem. Since HttpContext.Current is tied to the <code>IllogicalCallContext</code> of the <code>ExecutionContext</code>, it will not bleed in to any other threads that ASP.NET might create, and will be cleaned up when the copy <code>ExecutionContext</code> is disposed. (I could be wrong about much of this, though. It's all speculation and reflection)
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. PO.NET Remoting and HttpContext.Current
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USSnea
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. PO.NET Remoting and HttpContext.Current
 singulars
 PostTypePostTypeId
 PTQuestion
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTAcceptedByOriginator
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
1. COI thought your problem was with MyClass, not HttpContect.Current. Perhaps you should modify your question. Or are you saying in this answer that MyClass is still not accessible?
 singulars
 PostPostId
 PO
 UserUserId
 USJohnOpincar
2. COMyClass was stored in the HttpContext, I found out. I'll change the title.
 singulars
 PostPostId
 PO
 UserUserId
 USSnea

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.