0

I have a threadpool work item task that's kicked off when an ASP.net user invokes a particular service in my web app. The deployment environment access an older version of Oracle.DataAccess DLL through a binding redirect in the web.config file which works fine for synchronous http traffic. The threadpool task is, however, asynchronous and the threadpool code ignores the DLL redirect and is search for the newer Oracle DLL against which it was built.

I have tried dropping app.config, [ProjectDLLName].config and [ProjectDLLName].exe.config in the bin folder where it's deployed, but they seem to be ignored. Is there a way to specify a DLL dependency in code? or is there a different naming convention I should use for the thread pool code to automatically pick up the runtime tag in a separate file?

Edit: here's how the http request kicks off the thread work item

    public class AsynchBuildMugHandler : IHttpAsyncHandler, IReadOnlySessionState
    {
    public bool IsReusable { get { return false; } }

...
    public AsynchBuildMugHandler()
    {
    }
    public IAsyncResult BeginProcessRequest(HttpContext context, AsyncCallback cb, Object extraData)
    {
...
        AsynchBuildMugOperation asynch = new AsynchBuildMugOperation(cb, context, extraData);

        asynch.StartAsyncWork();
        return asynch;
    }

    public void EndProcessRequest(IAsyncResult result)
    {

        ScenarioCRUD scenDao = new ScenarioCRUD(null);

        if (buildScen != null)
        {
        scenDao.SetJobStatus(buildScen,"IDLE"); // whether cancel/crash/success always set back to idle
        }
    }

    public void ProcessRequest(HttpContext context)
    {
        throw new InvalidOperationException();
    }
    }

    class AsynchBuildMugOperation : IAsyncResult
    {
    private bool _completed;
    private Object _state;
    private AsyncCallback _callback;
    private HttpContext _context;

    bool IAsyncResult.IsCompleted { get { return _completed; } }
    WaitHandle IAsyncResult.AsyncWaitHandle { get { return null; } }
    Object IAsyncResult.AsyncState { get { return _state; } }
    bool IAsyncResult.CompletedSynchronously { get { return false; } }

    public AsynchBuildMugOperation(AsyncCallback callback, HttpContext context, Object state)
    {
        _callback = callback;
        _context = context;
        _state = state;
        _completed = false;
    }

    public void StartAsyncWork()
    {
        ...
        if (validSession)
        {
        if (validScen)
        {
            ThreadPool.QueueUserWorkItem(new WaitCallback(StartAsyncTask), null);
            _context.Response.Redirect(...ScenarioJobMonitor.aspx"); 
        }
        else
        {
            _context.Response.Redirect(...BuildStartFail.aspx"); // Shortcut to having to pass info around
        }
        }
        else
        {
        _context.Response.Redirect(...login.aspx");
        }
    }

    private void StartAsyncTask(Object workItemState)
    {

        // do a bunch of stuff that invokes Oracle DLL (works synchronously in other parts of the WebApp. 
        // doesn't work here
        _completed = true;
        _callback(this);
    }
    }
}
D to the P
  • 11
  • 4
  • Show how you are kicking off the thread pool item. I am curious if you are doing it the correct way, if you don't do it correctly you may have your AppDomain shut down before your background work gets to complete. Also we need to see how you are invoking the code, preferably both synchronously and asynchronously. – Scott Chamberlain Jan 14 '16 at 20:19
  • @ScottChamberlain Edited body of question to show thread kickoff. Non-threadpool code elsewhere in the Webapp works fine (obeys redirect in web.config). Also works fine on development server where DLL versions are the same as IDE. – D to the P Jan 14 '16 at 20:38
  • You might want to look in to [`HostingEnvironment.QueueBackgroundWorkItem`](https://msdn.microsoft.com/en-us/library/dn636893(v=vs.110).aspx), it is [more reliable](http://blogs.msdn.com/b/webdev/archive/2014/06/04/queuebackgroundworkitem-to-reliably-schedule-and-run-long-background-process-in-asp-net.aspx) than `ThreadPool.QueueUserWorkItem` when working in ASP.NET. However it is a .NET 4.5.2 and newer feature only. (BTW, this does nothing to help your actual problem, but I thought you might want to know) – Scott Chamberlain Jan 14 '16 at 20:52
  • I'm wondering if this is what I'm looking for in order to force the work item to kick off in the same thread pool as the rest of the web app code (and be beholden to the same web.config properties). [link](http://stackoverflow.com/questions/10495168/threads-being-taken-from-the-asp-net-thread-pool?rq=1) – D to the P Jan 14 '16 at 20:59
  • @ScottChamberlain I think this is the original article off which I based my prototype (or a reposting somewhere else) [MSDN Blog walkthrough for Asynch](https://msdn.microsoft.com/en-us/library/ms227433.aspx). There's no mention in there of behavior when compared to the rest of your synchronous code base. Might this be a bug or such an outdated framework that there's a better way to do it? I have tried additional app.manifest and project configuration changes, but the delegate.BeginInvoke linked in the earlier comment is the only one I haven't tried in depth. – D to the P Jan 14 '16 at 22:04

0 Answers0