Develop Reference

Generic and non-generic method with similar body

I have a method called ExecuteAsyncServiceRequest with an overload, you'll notice that the body of the both methods are similar. I find myself wondering is there a more concise way of writing these methods? Specifically, to not have to repeat myself in the method body.
Thanks in advance!
/// <summary>
/// Executes an async service request which returns a response of type TResponse
/// </summary>
/// <param name="execute">The service request to execute</param>
/// <param name="success">Callback when the service request is successful</param>
/// <param name="failure">Callback when the service request fails</param>
/// <typeparam name="TResponse">Type of the expected ServiceResult returned from the async request</typeparam>
protected async void ExecuteAsyncServiceRequest<TResponse>(Func<Task<ServiceResult<TResponse>>> execute,
Action<TResponse> success,
Action<string> failure)
{
ServiceResult<TResponse> result = await execute();
if (result.ResultCode == ServiceResult.ServiceResultCode.Failed)
failure(result.FailureDetails);
success(result.Response);
}
/// <summary>
/// Executes an async service request
/// </summary>
/// <param name="execute">The service request to execute</param>
/// <param name="success">Callback when the service request is successful</param>
/// <param name="failure">Callback when the service request fails</param>
protected async void ExecuteAsyncServiceRequest(Func<Task<ServiceResult>> execute,
Action success,
Action <string> failure)
{
ServiceResult result = await execute();
if (result.ResultCode == ServiceResult.ServiceResultCode.Failed)
failure(result.FailureDetails);
success();
}

No. Unfortunately, this is due to a limitation in the type system of .NET itself - specifically, that void is not a type.
Languages with more of a functional influence (as opposed to classical OOP) tend not to have the concept of void; instead, a special type (commonly called unit) exists that has a single value. Something like this:
public sealed class Unit {
private Unit() { }
public static Unit Instance { get; } = new Unit();
}
You can do something similar with your code, but it's up to you whether it's worth it or not:
protected async void ExecuteAsyncServiceRequest(Func<Task<ServiceResult>> execute,
Action success,
Action <string> failure) =>
ExecuteAsyncServiceRequest(
async () => new ServiceResult<Unit>(await execute(), Unit.Instance),
_ => success(),
failure);
This is assuming ServiceResult<T> can have a (possibly internal) constructor that takes ServiceResult as an argument and copies over all its properties except the actual "result" which is copied from the second constructor parameter.

Scheduling engine that supports more then just date/time triggers

I have found a number of great .NET scheduling engines, specifically Quartz.Net looks very promising. However, I need a scheduling engine that will allow me to trigger off of not only dates and times but also off of anything I can come up with. For example I might want to trigger when I see a process has started, when the computer is locked, off of a WMI event, etc... in addition to date/time based triggers.
What I am looking for is a solution that will allow me to implement the appropriate interface and fire the trigger whenever my conditions are met. Does something like this already exist or am I on my own?
Here are a couple I looked at:
What is the best way to represent "Recurring Events" in database?
c# recurring event (like for a calendar)
Recommend a C# Task Scheduling Library
How to write C# Scheduler
http://www.codeproject.com/Articles/2478/C-Scheduler
http://www.codeproject.com/Articles/2407/A-New-Task-Scheduler-Class-Library-for-NET
http://www.codeproject.com/Articles/8424/A-component-for-event-scheduling-inside-an-applica
http://blog.bobcravens.com/2009/10/an-event-based-cron-scheduled-job-in-c/
http://www.codeproject.com/Articles/6507/NET-Scheduled-Timer
This needs to run within my .NET application. I looked into modifying Quartz.Net to support this type of triggering but the concept of date/time triggers is just to ingrained; it would probably be easier to write my own scheduler since I don't need to save jobs and triggers to a database.
I'd prefer to work off of an existing scheduling system just so I don't have to worry about implementing the gritty details like queues, priorities, thread pools, etc... but of course I'll do what I have to do.

You could declare a base Task class, or interface, whichever you prefer that implements a bool property NeedsToRun and a method Run().
You could then inherit the Task class for each of your individual tasks (or using delegate funcs, task types) and define all the custom requirements you would need in order to check whether or not that task needs to run, and if it does, call the Run() method of that specific task.
Add all your tasks to a List<Task> and iterate over them periodically to see which task actually need running, and voila; you have a very simple, but effective scheduler.
Personally, I was after a priority-based scheduler rather than an event-driven one as you describe, so I implemented a Func<bool> to determine whether a task needs to run and an Action to actually run it. My code is as follows:
public class Task : IComparable<Task>
{
public Task(int priority, Action action, Func<bool> needsToRun, string name = "Basic Task")
{
Priority = priority;
Name = name;
Action = action;
_needsToRun = needsToRun;
}
public string Name { get; set; }
public int Priority { get; set; }
private readonly Func<bool> _needsToRun;
public bool NeedsToRun { get { return _needsToRun.Invoke(); } }
/// <summary>
/// Gets or sets the action this task performs.
/// </summary>
/// <value>
/// The action.
/// </value>
public Action Action { get; set; }
public void Run()
{
if (Action != null)
Action.Invoke();
}
#region Implementation of IComparable<in State>
/// <summary>
/// Compares the current object with another object of the same type.
/// </summary>
/// <returns>
/// A value that indicates the relative order of the objects being compared. The return value has the following meanings: Value Meaning Less than zero This object is less than the <paramref name="other"/> parameter.Zero This object is equal to <paramref name="other"/>. Greater than zero This object is greater than <paramref name="other"/>.
/// </returns>
/// <param name="other">An object to compare with this object.</param>
public int CompareTo(Task other)
{
return Priority == other.Priority && Name == other.Name ? 1 : 0;
}
#endregion
}
But I reckon this could be adapted to subscribe to events and setting a flag to make sure NeedsToRun returns true whenever that event is fired fairly easily.

Using BlockingCollection<T>: OperationCanceledException, is there a better way?

I'm making use of the (frankly great) BlockingCollection<T> type for a heavily multithreaded, high-performance app.
There's a lot of throughput through the collection and on the micro-level it's highly performant. However, for each 'batch' it will always be ended by flagging the cancellation token. This results in an exception being thrown on any waiting Take call. That's fine, but I would have settled for a return value or output parameter to signal it, because a) exceptions have an obvious overhead and b) when debugging, I don't want to manually turn off break-on-exception for that specific exception.
The implementation seems intense, and in theory I suppose I could disassemble and recreate my own version that didn't use exceptions, but perhaps there's a less complex way?
I could add a null (or if not, a placeholder) object to the collection to signify the process should end, however there also needs to be a means to abort nicely, i.e. wake up waiting threads and tell them somehow that something's gone on.
So - alternative collection types? Recreate my own? Some way to abuse this one?
(Some context: I went with BlockingCollection<T> because it has an advantage over manual locking around a Queue. As best I can tell the use of threading primitives is superb and in my case, a few milliseconds here-and-there and optimal core is use crucial.)
Edit: I've just opened a bounty for this one. I don't believe Anastasiosyal's answer covers the query I raise in my comment of it. I know this is a tough problem. Is anyone able to assist?

As I guess you have already done yourself, looking into the reflected source of BlockingCollection it looks unfortunately that when a CancellationToken is passed into the BlockingCollection and it cancels then you will get the OperationCancelledException as can be seen in the image below (with a couple of workarounds after the image)
GetConsumingEnumerable invokes TryTakeWithNoTimeValidation on the BlockingCollection which in turn raises this exception.
Workaround #1
One potential strategy would be, assuming you have more control over your producers and your consumers, rather than pass the cancellation token into the BlockingCollection, (which will raise this exception) you pass the cancellation token into your producers and into your consumers.
If your producers aren't producing and your consumers aren't consuming, then you have effectively cancelled the operation without raising this exception and by passing CancellationToken.None in your BlockingCollection.
Special cases Cancelling when the BlockingCollection is at BoundedCapacity or Empty
Producers blocked: The producer threads will be blocked when BoundedCapacity on the BlockingCollection is reached. Hence, when attempting to cancel and the BlockingCollection is at BoundedCapacity (which means that your consumers are not blocked but producers are blocked because they cannot add any additional items to the queue) then you will need to allow for additional items to be consumed (one for each producer thread) that will unblock the producers (because they are blocked on adding to the blockingCollection) and in turn allow for your cancellation logic to kick in on the producer side.
Consumers blocked: When your consumers are blocked because the queue is empty, then you could insert an empty unit of work (one for each consumer thread) in the Blocking collection so as to unblock the consumer threads and allow for your cancellation logic to kick in the consumer side.
When there are items in the queue and no limit such as BoundedCapacity or Empty has been reached then the producers and consumer threads should not be blocked.
Workaround #2
Using a cancellation unit of work.
When your application needs to cancel, then your producers (maybe just 1 producer will suffice while the others just cancel producing) will produce a cancellation unit of work (could be null as you also mention or some class that implements a marker interface). When the consumers consume this unit of work and detect that it is in fact a cancellation unit of work, their cancellation logic kicks in. The number of cancellation units of work to be produced needs to equal the number of consumer threads.
Again, caution is needed when we are close to BoundedCapacity, as it could be a sign that some of the producers are blocked. Depending on the number of producers/consumers you could have a consumer consuming until all producers (but 1) have shut down. This ensures that there are no lingering producers around. When there is only 1 producer left, your last consumer can shut down and the producer can stop producing cancellation units of work.

How about the BlockingQueue I did a while ago?
http://apichange.codeplex.com/SourceControl/changeset/view/76c98b8c7311#ApiChange.Api%2fsrc%2fInfrastructure%2fBlockingQueue.cs
It should do fine without any exceptions. The current queue does simply close the event on dispose which might not be what you want. You might want do enque a null and wait until all items were processed. Apart from this it should suit your needs.
using System.Collections.Generic;
using System.Collections;
using System.Threading;
using System;
namespace ApiChange.Infrastructure
{
/// <summary>
/// A blocking queue which supports end markers to signal that no more work is left by inserting
/// a null reference. This constrains the queue to reference types only.
/// </summary>
/// <typeparam name="T"></typeparam>
public class BlockingQueue<T> : IEnumerable<T>, IEnumerable, IDisposable where T : class
{
/// <summary>
/// The queue used to store the elements
/// </summary>
private Queue<T> myQueue = new Queue<T>();
bool myAllItemsProcessed = false;
ManualResetEvent myEmptyEvent = new ManualResetEvent(false);
/// <summary>
/// Deques an element from the queue and returns it.
/// If the queue is empty the thread will block. If the queue is stopped it will immedieately
/// return with null.
/// </summary>
/// <returns>An object of type T</returns>
public T Dequeue()
{
if (myAllItemsProcessed)
return null;
lock (myQueue)
{
while (myQueue.Count == 0)
{
if(!Monitor.Wait(myQueue, 45))
{
// dispatch any work which is not done yet
if( myQueue.Count > 0 )
continue;
}
// finito
if (myAllItemsProcessed)
{
return null;
}
}
T result = myQueue.Dequeue();
if (result == null)
{
myAllItemsProcessed = true;
myEmptyEvent.Set();
}
return result;
}
}
/// <summary>
/// Releases the waiters by enqueuing a null reference which causes all waiters to be released.
/// The will then get a null reference as queued element to signal that they should terminate.
/// </summary>
public void ReleaseWaiters()
{
Enqueue(null);
}
/// <summary>
/// Waits the until empty. This does not mean that all items are already process. Only that
/// the queue contains no more pending work.
/// </summary>
public void WaitUntilEmpty()
{
myEmptyEvent.WaitOne();
}
/// <summary>
/// Adds an element of type T to the queue.
/// The consumer thread is notified (if waiting)
/// </summary>
/// <param name="data_in">An object of type T</param>
public void Enqueue(T data_in)
{
lock (myQueue)
{
myQueue.Enqueue(data_in);
Monitor.PulseAll(myQueue);
}
}
/// <summary>
/// Returns an IEnumerator of Type T for this queue
/// </summary>
/// <returns></returns>
IEnumerator<T> IEnumerable<T>.GetEnumerator()
{
while (true)
{
T item = Dequeue();
if (item == null)
break;
else
yield return item;
}
}
/// <summary>
/// Returns a untyped IEnumerator for this queue
/// </summary>
/// <returns></returns>
IEnumerator IEnumerable.GetEnumerator()
{
return ((IEnumerable<T>)this).GetEnumerator();
}
#region IDisposable Members
/// <summary>
/// Closes the EmptyEvent WaitHandle.
/// </summary>
public void Dispose()
{
myEmptyEvent.Close();
}
#endregion
}
}

You cound signal the end of a batch by setting a flag on the last item (add a IsLastItem bool property to it or wrap it). Or you might send a null as last item (not sure if a null goes through the blockingcollection correctly though).
If you can remove the need for the 'batch' concept you can create an extra thread to continously Take() and Process new Data from your blockingcollection and do nothing else.

Kieren,
From my inspection, I personally don't know any thread safe type for ProducerConsumer pattern which does exactly what you wanted. I don't claim this as competitive solution but propose you decorate BlockingCollection<T> with few extension method which will give you the freedom to supply any built-in or custom types instead of default CancellationToken.
Stage 1:
Following are the list of default method which use underling TryAddWithNoTimeValidation method to add to queue.
public void Add(T item){
this.TryAddWithNoTimeValidation(item, -1, new CancellationToken());
}
public void Add(T item, CancellationToken cancellationToken){
this.TryAddWithNoTimeValidation(item, -1, cancellationToken);
}
public bool TryAdd(T item){
return this.TryAddWithNoTimeValidation(item, 0, new CancellationToken());
}
public bool TryAdd(T item, TimeSpan timeout){
BlockingCollection<T>.ValidateTimeout(timeout);
return this.TryAddWithNoTimeValidation(item, (int) timeout.TotalMilliseconds, new CancellationToken());
}
public bool TryAdd(T item, int millisecondsTimeout){
BlockingCollection<T>.ValidateMillisecondsTimeout(millisecondsTimeout);
return this.TryAddWithNoTimeValidation(item, millisecondsTimeout, new CancellationToken());
}
public bool TryAdd(T item, int millisecondsTimeout, CancellationToken cancellationToken){
BlockingCollection<T>.ValidateMillisecondsTimeout(millisecondsTimeout);
return this.TryAddWithNoTimeValidation(item, millisecondsTimeout, cancellationToken);
}
Now you can provide extension for any/all of method which you are interested.
Stage 2:
You now refer your implementation of TryAddWithNoTimeValidation instead of default.
I can give you an alternate version of TryAddWithNoTimeValidation which safely continue without throwing OperationCancellation exception.

My suggestion is to implement this functionality by encapsulating an asynchronous queue, like the BufferBlock<T> class from the TPL Dataflow library. This class is a thread-safe container intended for producer-consumer scenarios, and supports backpressure (BoundedCapacity) just like the BlockingCollection<T> class. Being asynchronous means that the corresponding Add/Take methods (SendAsync/ReceiveAsync) return tasks. These tasks store the event of a cancellation as an internal state, that can be queried with the IsCanceled property, so throwing exceptions internally can be avoided. Propagating this state with exceptions can also be avoided, by waiting the tasks using a exception-suppressing continuation (ContinueWith). Here is an implementation:
/// <summary>
/// A thread-safe collection that provides blocking and bounding capabilities.
/// The cancellation is propagated as a false result, and not as an exception.
/// </summary>
public class CancellationFriendlyBlockingCollection<T>
{
private readonly BufferBlock<T> _bufferBlock;
public CancellationFriendlyBlockingCollection()
{
_bufferBlock = new BufferBlock<T>();
}
public CancellationFriendlyBlockingCollection(int boundedCapacity)
{
_bufferBlock = new BufferBlock<T>(new() { BoundedCapacity = boundedCapacity });
}
public bool TryAdd(T item, CancellationToken cancellationToken = default)
{
if (cancellationToken.IsCancellationRequested) return false;
if (_bufferBlock.Post(item)) return true;
Task<bool> task = _bufferBlock.SendAsync(item, cancellationToken);
WaitNoThrow(task);
if (!task.IsCompletedSuccessfully) return false;
return task.Result;
}
public bool TryTake(out T item, CancellationToken cancellationToken = default)
{
if (cancellationToken.IsCancellationRequested) { item = default; return false; }
if (_bufferBlock.TryReceive(out item)) return true;
Task<T> task = _bufferBlock.ReceiveAsync(cancellationToken);
WaitNoThrow(task);
if (!task.IsCompletedSuccessfully) return false;
item = task.Result; return true;
}
public IEnumerable<T> GetConsumingEnumerable(
CancellationToken cancellationToken = default)
{
while (TryTake(out var item, cancellationToken)) yield return item;
}
public void CompleteAdding() => _bufferBlock.Complete();
public bool IsCompleted => _bufferBlock.Completion.IsCompleted;
public int Count => _bufferBlock.Count;
// Wait the task to complete without throwing exceptions
private static void WaitNoThrow(Task task)
{
if (task.IsCompleted) return;
task.ContinueWith(_ => { }, default,
TaskContinuationOptions.ExecuteSynchronously |
TaskContinuationOptions.DenyChildAttach, TaskScheduler.Default).Wait();
Debug.Assert(task.IsCompleted);
}
}
Performance: The CancellationFriendlyBlockingCollection.TryTake method can be invoked with a canceled CancellationToken in a loop with a frequency of about 15,000,000 times per second in my PC (on a single thread). For comparison the frequency of the BlockingCollection<T>.Take under the same conditions is about 20,000 times per second.
You might be tempted to replace the BufferBlock<T> with a more modern asynchronous queue like the Channel<T>. In that case please make sure to read this question first, in order to be aware about a leaky behavior of this class, under specific conditions.

Directshow filter access threading

I made a TV-Player in c# using directshowlib-2005.
now I made a method to search for available channels.
I want this method to run in a different thread so my GUI won't freeze, but I get an error when I try to set the channel in the method. It can't find the IAMTVTuner interface in my graph, altough I know it's there.
If I don't use a different thread, the method works just fine (but my GUI freezes for a while)
I know it has to do something with apartments, but is there a way I can acces that interface in a different thread then the thread where created my graph in?

This problem is because some com classes or interfaces like in the DirectShowLib should be just accessed from the same thread that it was created on.
So the solution to this problem is to implement ISynchronizeInvoke "System.ComponentModel.ISynchronizeInvoke".
For example if you need to access methods in the class named Media that uses internally some classes or methods from the DirectshowLib in multithreading mode, you have to check if invoke required by using InvokeRequired and if true you have to access it via Invoke method.
To demonstrate how to implement ISynchronizeInvoke interface here is a snippet from a code that I develop some time ago in C# 2.0
public abstract class Media : ISynchronizeInvoke
{
//....
private readonly System.Threading.SynchronizationContext _currentContext = System.Threading.SynchronizationContext.Current;
private readonly System.Threading.Thread _mainThread = System.Threading.Thread.CurrentThread;
private readonly object _invokeLocker = new object();
//....
#region ISynchronizeInvoke Members
public bool InvokeRequired
{
get
{
return System.Threading.Thread.CurrentThread.ManagedThreadId != this._mainThread.ManagedThreadId;
}
}
/// <summary>
/// This method is not supported!
/// </summary>
/// <param name="method"></param>
/// <param name="args"></param>
/// <returns></returns>
[Obsolete("This method is not supported!", true)]
public IAsyncResult BeginInvoke(Delegate method, object[] args)
{
throw new NotSupportedException("The method or operation is not implemented.");
}
/// <summary>
/// This method is not supported!
/// </summary>
/// <param name="method"></param>
/// <param name="args"></param>
/// <returns></returns>
[Obsolete("This method is not supported!", true)]
public object EndInvoke(IAsyncResult result)
{
throw new NotSupportedException("The method or operation is not implemented.");
}
public object Invoke(Delegate method, object[] args)
{
if (method == null)
{
throw new ArgumentNullException("method");
}
lock (_invokeLocker)
{
object objectToGet = null;
SendOrPostCallback invoker = new SendOrPostCallback(
delegate(object data)
{
objectToGet = method.DynamicInvoke(args);
});
_currentContext.Send(new SendOrPostCallback(invoker), method.Target);
return objectToGet;
}
}
public object Invoke(Delegate method)
{
return Invoke(method, null);
}
#endregion//ISynchronizeInvoke Members
}

WatiN Parallelization within a test

I have a test where I want to ensure separate operations within one page result in distinct results. Specifically, I have a few ways to sort on a page and I want a test to make sure that each sort is different. I have other tests to ensure the correctness of each sort.
I would like the focus of this conversation to be on a good way to run test operations in parallel and compare the results at the end, rather than on what to test or testing methods. I figure parallel operations in testing is an interesting and broad enough topic that it could be useful to others.
Let "generateHashFromSearchResults()" be a function that returns a string representing the order of the search results shown on current IE instance. Here is what the working code looks like in a serialized fashion using one browser instance:
var set = new HashSet<string>();
var sortOptions = new List<String>() { "sort1", "sort2", "sort3" };
// Default sort
set.Add(generateHashFromSearchResults());
sortOptions.ForEach(s => {
ie.Link(Find.ByText(s)).Click();
set.Add(generateHashFromSearchResults());
});
Assert.That(set.Count() == 4);
I had read about PLINQ a few months ago and figured this might be a decent use case. Now let "generateHashFromSearchResults(IE ie)" be the same function, but that operates on an explicitly defined IE instance. I tried something like this:
List<string> resultList = sortOptions.AsParallel().Select(s => {
var ie = new IE(true);
ie.Link(Find.ByText(s)).Click();
return generateHashFromSearchResults(ie);
}).ToList();
// Forget about default sort for now. There should be 3 distinct results
Assert.That(new HashSet<string>(resultList).Count() == 3);
The biggest issue I face right now is not understanding how PLINQ does thread management. WatiN needs to run with the apartment state set to single threaded (STAThread). I get that each IE instance should be in its own thread, but no amount of setting each thread in the PLINQ query to the proper apartment state fixes the issue.
I'm starting to suspect that I either need to learn more about PLINQ to continue, or that I need to learn more about thread management by hand to get this to work.
Any thoughts?

You can't specify a custom scheduler with AsParallel(). But you can create a Task for each sort option and pass an instance of a custom scheduler into the Start() method. This implementation of an STA Thread scheduler was borrowed from Stephen Toub (http://blogs.msdn.com/b/pfxteam/archive/2010/04/07/9990421.aspx):
using System;
using System.Collections.Concurrent;
using System.Collections.Generic;
using System.Linq;
using System.Threading;
using System.Threading.Tasks;
/// <summary>
/// Provides a scheduler that uses STA threads.
/// Borrowed from Stephen Toub's implementation http://blogs.msdn.com/b/pfxteam/archive/2010/04/07/9990421.aspx
/// </summary>
public sealed class StaTaskScheduler : TaskScheduler, IDisposable
{
/// <summary>
/// The STA threads used by the scheduler.
/// </summary>
private readonly List<Thread> threads;
/// <summary>
/// Stores the queued tasks to be executed by our pool of STA threads.
/// </summary>
private BlockingCollection<Task> tasks;
/// <summary>
/// Initializes a new instance of the StaTaskScheduler class with the specified concurrency level.
/// </summary>
/// <param name = "numberOfThreads">The number of threads that should be created and used by this scheduler.</param>
public StaTaskScheduler(int numberOfThreads)
{
if (numberOfThreads < 1)
{
throw new ArgumentOutOfRangeException(
"numberOfThreads", "The scheduler must create at least one thread");
}
// Initialize the tasks collection
this.tasks = new BlockingCollection<Task>();
// Create the threads to be used by this scheduler
this.threads = Enumerable.Range(0, numberOfThreads).Select(
i =>
{
var thread = new Thread(
() =>
{
// Continually get the next task and try to execute it.
// This will continue until the scheduler is disposed and no more tasks remain.
foreach (Task t in this.tasks.GetConsumingEnumerable())
{
this.TryExecuteTask(t);
}
}) {
Name = "Sta Thread", IsBackground = true
};
thread.SetApartmentState(ApartmentState.STA);
return thread;
}).ToList();
// Start all of the threads
this.threads.ForEach(t => t.Start());
}
/// <summary>
/// Gets the maximum concurrency level supported by this scheduler.
/// </summary>
public override int MaximumConcurrencyLevel
{
get
{
return this.threads.Count;
}
}
/// <summary>
/// Cleans up the scheduler by indicating that no more tasks will be queued.
/// This method blocks until all threads successfully shutdown.
/// </summary>
public void Dispose()
{
if (this.tasks != null)
{
// Indicate that no new tasks will be coming in
this.tasks.CompleteAdding();
// Wait for all threads to finish processing tasks
foreach (Thread thread in this.threads)
{
thread.Join();
}
// Cleanup
this.tasks.Dispose();
this.tasks = null;
}
}
/// <summary>
/// Provides a list of the scheduled tasks for the debugger to consume.
/// </summary>
/// <returns>An enumerable of all tasks currently scheduled.</returns>
protected override IEnumerable<Task> GetScheduledTasks()
{
// Serialize the contents of the blocking collection of tasks for the debugger
return this.tasks.ToArray();
}
/// <summary>
/// Queues a Task to be executed by this scheduler.
/// </summary>
/// <param name = "task">The task to be executed.</param>
protected override void QueueTask(Task task)
{
// Push it into the blocking collection of tasks
this.tasks.Add(task);
}
/// <summary>
/// Determines whether a Task may be inlined.
/// </summary>
/// <param name = "task">The task to be executed.</param>
/// <param name = "taskWasPreviouslyQueued">Whether the task was previously queued.</param>
/// <returns>true if the task was successfully inlined; otherwise, false.</returns>
protected override bool TryExecuteTaskInline(Task task, bool taskWasPreviouslyQueued)
{
// Try to inline if the current thread is STA
return Thread.CurrentThread.GetApartmentState() == ApartmentState.STA && this.TryExecuteTask(task);
}
}

Maybe You should use Task Parallel Library?
I'm a beginner in TPL, but there are Schedulers that maybe have some options for setting STAThread on scheduled Tasks.