locked
Unable to find assembly in Task RRS feed

  • Question

  • I have used Task in asp.net 4.0.

    In that I have handled Task timeout like below:

    var tokenSource = new CancellationTokenSource();

    var token = tokenSource.Token;

    List<Task> lstTask = new List<Task>(); lstTask.Add(Task<CustomClass>.Factory.StartNew(() => Method1(token))); lstTask.Add(Task<CustomClass>.Factory.StartNew(() => Method2(token))); lstTask.Add(Task<CustomClass>.Factory.StartNew(() => Method3(token))); try { Task.WaitAll(lstTask.ToArray(), 2000, token); tokenSource.Cancel(); } catch(AggregateException) { //just catch not to do anything } catch(Exception) { //just catch not to do anything } public CustomClass Method1/2/3() { try { // Do Web request // Do process return CustomClass; } catch(exception ex) { if (!token.IsCancellationRequested) { throw; } } return new CustomClass(); }


    In this, If any error occurs after WaitAll time has elapsed, than it will not throw error.

    I have used Try Catch in all the method.

    I have used third party dll in Method1/2/3.

    This dll causes issue some time. It gives me error like "Unable to find assembly of mentioned dll".

    In my system it does not show or throw error but i found this error in windows log.

    whereas that dll is referenced already.

    I am not getting this error each time.

    Friday, June 28, 2013 12:37 PM

Answers

  • I still don't see the actual error you're encountering.  When you call WaitAll the thread will block until all tasks complete or the timeout occurs.  If an exception occurs in one of the tasks then it will get bubbled back to you via AggregrateException which you're handling.  Your catch block will be able to user InnerException to identify the actual error.  Because you're using a cancellation token this would also trigger the same exception but the cancel exception would be there.

    For the assembly that is being logged, are you logging that message as part of this specific catch block?  Is the assembly in the correct directory?  Are you sure it hasn't already been loaded?  Have you tried using the binding log to track down why it isn't being loaded?  Can you narrow down the task that is causing it? 

    Michael Taylor
    http://msmvps.com/blogs/p3net

    • Marked as answer by Bob Shen Wednesday, July 10, 2013 8:01 AM
    Monday, July 1, 2013 2:27 PM

All replies

  • Your try-catch is hiding all the exceptions from you.  You should almost never blindly catch and ignore exceptions.  Remove the EH block and verify your code works.  If you need to ensure that the code doesn't crash then catch the specific exceptions you expect but you should probably log them somewhere.

    Your tasks should probably not have a try-catch at all.  If the task throws an exception then it will be properly handled by the infrastructure and when Wait is called it will be rethrown.

    The event log entry is probably not relevant if your app is working properly.

    Michael Taylor
    http://msmvps.com/blogs/p3net

    • Proposed as answer by Christopher84 Friday, June 28, 2013 3:46 PM
    Friday, June 28, 2013 3:07 PM
  • I have to agree. Except for the almost.

    Never swallow Exceptions!

    Code that never throws exceptions is not good code. It is the most terrible code.
    Exceptions are to be used for "Problems that should not be ignored" and "Problems that are outside my codes ability to deal with".

    Granted, handling an exception could be as little as "MessageBox.Show(ex.ToString()); and logging it" At least it tells the user something went wrong and gives you the debug information you need.

    Almost as important as never swallong them, is to not catch Exception itself. Only ever catch those exceptions you expect (Every functions documentation has a list of the Exceptions it is expected to throw). Catching an exception you are not equiped to deal with will really bug up ecdeption handling.

    For those and more good rules of exception handling, read here:

    http://www.codeproject.com/Articles/9538/Exception-Handling-Best-Practices-in-NET


    Let's talk about MVVM: http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/b1a8bf14-4acd-4d77-9df8-bdb95b02dbe2

    Friday, June 28, 2013 3:54 PM
  • I disagree that there is never a case where you should swallow exceptions.  There are 3 cases I can think of where it is good and potentially required.

    1) Try/Safe... functionality should generally not throw exceptions.  TryParse is a good example.  These methods might log something but bad parsing is generally not worth logging just like we would probably not log bad user input.

    2) Equals/GetHashCode implementations should never throw exceptions.  This is documented in the design guidelines and in most books on how to implement them properly.  You could do logging here but I don't think it adds any value.

    3) Static ctors should not allow exceptions out as this will cause the type load to fail.  The most you could do here is log the exception.

    Hence my rule is that you should usually not swallow exceptions.

    Friday, June 28, 2013 4:06 PM
  • 1. TryParse does not swallow Exceptions. It returns false and set's the out parameter to 0 in case of any expected exceptions. It will still let OOM Exceptions bubble up, as any other exceptions it not expects. I once wrote a TryParse implementation for someone still in .NET 1.1, no remotely difficulty.
    It's freaking job is to catch the expected exceptions and expose them as false/0. That is not swallowing. That is "help the programmer by providing him an easy to use try...catch block around a parse".

    2. == should return true or false. The only problem you ever can run into there is NULL References. And the answer is that NULL is only equal to NULL. How anyone could ever manage to throw an exception from == is beyond me. Because it is just a chaining of the built in and other == operators.

    3. Must still be able to somehow communicate that it could not run properly. Again, not swallowing.


    Let's talk about MVVM: http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/b1a8bf14-4acd-4d77-9df8-bdb95b02dbe2

    Saturday, June 29, 2013 1:13 PM
  • 1. OOM and SO exceptions don't really count because even with a EH block the exception is still going to bring down the thread.  They are one of a handful of exceptions that cannot truly be swallowed.  Swallowing an exception, in my opinion, is when you eat an exception and the caller is not aware of it (or another exception).  Logging an exception is still swallowing it as is returning some value in its place.  You've swallowed the error and are returning something else that does not indicate that the error occurred.  With TryParse a return value of false indicates the parse failed it doesn't indicate that an exception occurred. 

    2.  It is very easy to throw an exception in an equals implementation.  Take for example this incredibly simple implementation:

    public struct Name
    {
       public string First { get; set; }
       public string Middle { get; set; }
       public string Last { get; set; }

       public bool Equals ( Name other )
       {
          return First.Equals(other.First) && Middle.Equals(other.Middle) && Last.Equals(other.Last);
       }
    }

    3.  If the exception isn't thrown then it is swallowed.  Logging isn't relevant to the caller.

    Thus there are occasions where swallowing an exception is reasonable.  We can agree to disagree but I stand by my opinion that almost always is the correct approach and that saying never is incorrect.  Here's an interesting read by Haack on this very concept. I agree with his assessment.

    Saturday, June 29, 2013 3:44 PM
  • Hello All,

    Thank you all for reply.

    Actually I am already logging the exception.

    I have used Try catch in Task because I will check Task's Status after WaitAll time has elapsed.

    Below is my reference Code :

    try { Task.WaitAll(lstTask.ToArray(), 2000, token); tokenSource.Cancel();

                    foreach (var tsk in lstTask)
                    {
                        if (tsk.IsCompleted)
                        {
                            if (!tsk.IsFaulted)
                            {


    }

    }

    } } catch(AggregateException) { //just catch not to do anything } catch(Exception) { //just catch not to do anything }

    In this , What I am doing is, I will use foreach loop on List<Task> and will check if Task.IsCompleted or IsFaulted and will do further process according to it.

    And I will log all those task which are not completed in WaitAll time and also log all those task which are faulted.

    So my actual problem is,

    I have found two scenario for this.

    1. It gives error after waitAll time has elapsed , So why it is not able to find dll ?

    2. Even I am not throwing any exception after token has cancelled , why it shows me error in windows log?

    Note:: I am not logging to windows log explicitly from application.

    Monday, July 1, 2013 7:20 AM
  • I still don't see the actual error you're encountering.  When you call WaitAll the thread will block until all tasks complete or the timeout occurs.  If an exception occurs in one of the tasks then it will get bubbled back to you via AggregrateException which you're handling.  Your catch block will be able to user InnerException to identify the actual error.  Because you're using a cancellation token this would also trigger the same exception but the cancel exception would be there.

    For the assembly that is being logged, are you logging that message as part of this specific catch block?  Is the assembly in the correct directory?  Are you sure it hasn't already been loaded?  Have you tried using the binding log to track down why it isn't being loaded?  Can you narrow down the task that is causing it? 

    Michael Taylor
    http://msmvps.com/blogs/p3net

    • Marked as answer by Bob Shen Wednesday, July 10, 2013 8:01 AM
    Monday, July 1, 2013 2:27 PM