Develop Reference

where is DbContextTransaction in .Net Core

I need to use DbContextTransaction in a class on a .Net Standard library, I haven't been able to find the corresponding nuget package, I am porting this https://github.com/mehdime/DbContextScope/tree/master/Mehdime.Entity to .Net Core, but I only have 2 compilation errores due to missing packages/dependencies which I am not sure how to find:
Error CS0246: The type or namespace name 'MarshalByRefObject' could
not be found (are you missing a using directive or an assembly
reference?) (CS0246) (Mehdime.Entity)
Error CS0246: The type or namespace name 'DbContextTransaction' could
not be found (are you missing a using directive or an assembly
reference?) (CS0246) (Mehdime.Entity)
Code is:
/*
* Copyright (C) 2014 Mehdi El Gueddari
* http://mehdi.me
*
* This software may be modified and distributed under the terms
* of the MIT license. See the LICENSE file for details.
*/
using System;
using System.Collections.Generic;
using System.Data;
using System.Runtime.ExceptionServices;
using System.Threading;
using System.Threading.Tasks;
using Microsoft.EntityFrameworkCore;
namespace Mehdime.Entity
{
/// <summary>
/// As its name suggests, DbContextCollection maintains a collection of DbContext instances.
///
/// What it does in a nutshell:
/// - Lazily instantiates DbContext instances when its Get Of TDbContext () method is called
/// (and optionally starts an explicit database transaction).
/// - Keeps track of the DbContext instances it created so that it can return the existing
/// instance when asked for a DbContext of a specific type.
/// - Takes care of committing / rolling back changes and transactions on all the DbContext
/// instances it created when its Commit() or Rollback() method is called.
///
/// </summary>
public class DbContextCollection : IDbContextCollection
{
private Dictionary<Type, DbContext> _initializedDbContexts;
private Dictionary<DbContext, DbContextTransaction> _transactions;
private IsolationLevel? _isolationLevel;
private readonly IDbContextFactory _dbContextFactory;
private bool _disposed;
private bool _completed;
private bool _readOnly;
internal Dictionary<Type, DbContext> InitializedDbContexts { get { return _initializedDbContexts; } }
public DbContextCollection(bool readOnly = false, IsolationLevel? isolationLevel = null, IDbContextFactory dbContextFactory = null)
{
_disposed = false;
_completed = false;
_initializedDbContexts = new Dictionary<Type, DbContext>();
_transactions = new Dictionary<DbContext, DbContextTransaction>();
_readOnly = readOnly;
_isolationLevel = isolationLevel;
_dbContextFactory = dbContextFactory;
}
public TDbContext Get<TDbContext>() where TDbContext : DbContext
{
if (_disposed)
throw new ObjectDisposedException("DbContextCollection");
var requestedType = typeof(TDbContext);
if (!_initializedDbContexts.ContainsKey(requestedType))
{
// First time we've been asked for this particular DbContext type.
// Create one, cache it and start its database transaction if needed.
var dbContext = _dbContextFactory != null
? _dbContextFactory.CreateDbContext<TDbContext>()
: Activator.CreateInstance<TDbContext>();
_initializedDbContexts.Add(requestedType, dbContext);
if (_readOnly)
{
dbContext.Configuration.AutoDetectChangesEnabled = false;
}
if (_isolationLevel.HasValue)
{
var tran = dbContext.Database.BeginTransaction(_isolationLevel.Value);
_transactions.Add(dbContext, tran);
}
}
return _initializedDbContexts[requestedType] as TDbContext;
}
public int Commit()
{
if (_disposed)
throw new ObjectDisposedException("DbContextCollection");
if (_completed)
throw new InvalidOperationException("You can't call Commit() or Rollback() more than once on a DbContextCollection. All the changes in the DbContext instances managed by this collection have already been saved or rollback and all database transactions have been completed and closed. If you wish to make more data changes, create a new DbContextCollection and make your changes there.");
// Best effort. You'll note that we're not actually implementing an atomic commit
// here. It entirely possible that one DbContext instance will be committed successfully
// and another will fail. Implementing an atomic commit would require us to wrap
// all of this in a TransactionScope. The problem with TransactionScope is that
// the database transaction it creates may be automatically promoted to a
// distributed transaction if our DbContext instances happen to be using different
// databases. And that would require the DTC service (Distributed Transaction Coordinator)
// to be enabled on all of our live and dev servers as well as on all of our dev workstations.
// Otherwise the whole thing would blow up at runtime.
// In practice, if our services are implemented following a reasonably DDD approach,
// a business transaction (i.e. a service method) should only modify entities in a single
// DbContext. So we should never find ourselves in a situation where two DbContext instances
// contain uncommitted changes here. We should therefore never be in a situation where the below
// would result in a partial commit.
ExceptionDispatchInfo lastError = null;
var c = 0;
foreach (var dbContext in _initializedDbContexts.Values)
{
try
{
if (!_readOnly)
{
c += dbContext.SaveChanges();
}
// If we've started an explicit database transaction, time to commit it now.
var tran = GetValueOrDefault(_transactions, dbContext);
if (tran != null)
{
tran.Commit();
tran.Dispose();
}
}
catch (Exception e)
{
lastError = ExceptionDispatchInfo.Capture(e);
}
}
_transactions.Clear();
_completed = true;
if (lastError != null)
lastError.Throw(); // Re-throw while maintaining the exception's original stack track
return c;
}
public Task<int> CommitAsync()
{
return CommitAsync(CancellationToken.None);
}
public async Task<int> CommitAsync(CancellationToken cancelToken)
{
if (cancelToken == null)
throw new ArgumentNullException("cancelToken");
if (_disposed)
throw new ObjectDisposedException("DbContextCollection");
if (_completed)
throw new InvalidOperationException("You can't call Commit() or Rollback() more than once on a DbContextCollection. All the changes in the DbContext instances managed by this collection have already been saved or rollback and all database transactions have been completed and closed. If you wish to make more data changes, create a new DbContextCollection and make your changes there.");
// See comments in the sync version of this method for more details.
ExceptionDispatchInfo lastError = null;
var c = 0;
foreach (var dbContext in _initializedDbContexts.Values)
{
try
{
if (!_readOnly)
{
c += await dbContext.SaveChangesAsync(cancelToken).ConfigureAwait(false);
}
// If we've started an explicit database transaction, time to commit it now.
var tran = GetValueOrDefault(_transactions, dbContext);
if (tran != null)
{
tran.Commit();
tran.Dispose();
}
}
catch (Exception e)
{
lastError = ExceptionDispatchInfo.Capture(e);
}
}
_transactions.Clear();
_completed = true;
if (lastError != null)
lastError.Throw(); // Re-throw while maintaining the exception's original stack track
return c;
}
public void Rollback()
{
if (_disposed)
throw new ObjectDisposedException("DbContextCollection");
if (_completed)
throw new InvalidOperationException("You can't call Commit() or Rollback() more than once on a DbContextCollection. All the changes in the DbContext instances managed by this collection have already been saved or rollback and all database transactions have been completed and closed. If you wish to make more data changes, create a new DbContextCollection and make your changes there.");
ExceptionDispatchInfo lastError = null;
foreach (var dbContext in _initializedDbContexts.Values)
{
// There's no need to explicitly rollback changes in a DbContext as
// DbContext doesn't save any changes until its SaveChanges() method is called.
// So "rolling back" for a DbContext simply means not calling its SaveChanges()
// method.
// But if we've started an explicit database transaction, then we must roll it back.
var tran = GetValueOrDefault(_transactions, dbContext);
if (tran != null)
{
try
{
tran.Rollback();
tran.Dispose();
}
catch (Exception e)
{
lastError = ExceptionDispatchInfo.Capture(e);
}
}
}
_transactions.Clear();
_completed = true;
if (lastError != null)
lastError.Throw(); // Re-throw while maintaining the exception's original stack track
}
public void Dispose()
{
if (_disposed)
return;
// Do our best here to dispose as much as we can even if we get errors along the way.
// Now is not the time to throw. Correctly implemented applications will have called
// either Commit() or Rollback() first and would have got the error there.
if (!_completed)
{
try
{
if (_readOnly) Commit();
else Rollback();
}
catch (Exception e)
{
System.Diagnostics.Debug.WriteLine(e);
}
}
foreach (var dbContext in _initializedDbContexts.Values)
{
try
{
dbContext.Dispose();
}
catch (Exception e)
{
System.Diagnostics.Debug.WriteLine(e);
}
}
_initializedDbContexts.Clear();
_disposed = true;
}
/// <summary>
/// Returns the value associated with the specified key or the default
/// value for the TValue type.
/// </summary>
private static TValue GetValueOrDefault<TKey, TValue>(IDictionary<TKey, TValue> dictionary, TKey key)
{
TValue value;
return dictionary.TryGetValue(key, out value) ? value : default(TValue);
}
}
}

There is no unified DbContextTransaction class in Entity Framework Core. IDbContextTransaction interface is declared instead.
IDbContextTransaction transaction = context.Database.BeginTransaction();
One of its implementations is RelationalTransaction (I guess this is what you are looking for).

You can use DbContext.Database API.
var context = new DbContext();
var transaction = context.Database.BeginTransaction();
try
{
context.Table1.Add(data1);
context.SaveChanges();
context.Table2.Add(data2);
context.SaveChanges();
// Commit transaction if all commands succeed
transaction.Commit();
}
catch
{
}

Pass null test then throws NullPointerException

I am checking for Null in the code below, even when passed a bogus path the null test is passed. However when I return the workbook a NullPointerException is thrown. How can I check for a NullPointerReference in this case? When I inspect the workBook variable while debugging it is set to something, I believe this must be why it is passing the Null check.
public static ExcelWorkbook OpenExcelWorkSheet(string file_path)
{
string EXCEL_FILE_EXTENSION = ".xlsx",
full_path = file_path + EXCEL_FILE_EXTENSION;
var excelFile = new FileInfo(full_path);
using (var package = new ExcelPackage(excelFile))
{
ExcelWorkbook workBook = package.Workbook;
if (workBook.Equals(null))
{
throw new Exception("ERROR!!!");
}
else { Console.Write("not null"); }
return workBook;
}
}

Looking at the source code for ExcelPackage, the Workbook property can never return null. Its getter will create a new Workbook if it finds that its internal field is null:
public ExcelWorkbook Workbook
{
get
{
if (_workbook == null)
{
var nsm = CreateDefaultNSM();
_workbook = new ExcelWorkbook(this, nsm);
_workbook.GetExternalReferences();
_workbook.GetDefinedNames();
}
return (_workbook);
}
}
Knowing this, I think you could safely remove the check altogether.
Additionally, as others have noted, you do need to be careful about how you use your using statements. When a ExcelPackage is disposed, its Workbook is in turn disposed (you can see this happening in the source code I linked). This is probably why you're seeing a null workbook returned from your method, but not while you are in the using statement. Very shortly after that closing } of your using it becomes null.
If you have a class that you're using to wrap the functionality of EPPlus, then you should make sure that it:
Only instantiates the ExcelPackage once and holds onto a reference to it; do not use a using statement when you do this
Have your other methods access this ExcelPackage reference when they need to; don't pass it around or re-open the package
Implement IDisposable, then properly dispose your ExcelPackage object when your wrapper is disposing.
Here's an example*:
public class YourWrapper : IDisposable
{
private bool disposed;
public YourWrapper()
{
}
public YourWrapper(string path)
{
OpenExcelPackage(path);
}
public void OpenExcelPackage(string path)
{
Package = new ExcelPackage(path);
}
public ExcelPackage Package { get; private set; }
protected virtual void Dispose(bool disposing)
{
if (!this.disposed)
{
if (disposing)
{
if (Package != null)
{
Package.Dispose();
Package = null;
}
}
}
this.disposed = true;
}
~YourWrapper()
{
Dispose(false);
}
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
}
Now instead, use a using whenever you instantiate your wrapper:
using (var wrapper = new YourWrapper())
{
// Do everything related to manipulating the Excel file here
}
And everything will get cleaned up nicely.
* Please change the names of the classes/methods to something more appropriate; this was just for illustration.

Question on using Monitor.TryEnter and locking object

Consider the following function that implements non-blocking access to only the one thread.
public bool TryCancelGroup()
{
if (Monitor.TryEnter(_locked))
{
if (_locked == false)
{
_locked = true;
try
{
// do something
}
catch (Exception ex)
{
_locked = false;
}
finally
{
Monitor.Exit(_locked);
}
}
return _locked;
}
else
{
return false;
}
}
And here is how _locked variable is defined.
bool _locked = false;
Now when program reaches Monitor.Exit(_locked); it throws an System.Threading.SynchronizationLockException saying that _locked variable was not synchronized before.
It all was working before when _locked variable was defined as object
object _locked = new object();
When I changed it to bool in order to use it as boolean flag I started getting this exception.

The reason why is that the Monitor methods all take a System.Object parameter. When you pass in a bool a box is required to convert to Object. The box operation produces a new System.Object value for each call. So the TryEnter and Exit methods see different objects and results in the exception.
When _locked was typed to Object there was no need for a box. Hence the TryEnter and Exit methods see the same object and can function correctly.
A few other comments about the code
TryEnter must be paired with Exit in all cases and for sanity sake the Exit call should be in a finally block. Otherwise you're inviting a deadlock scenario
The _locked variable is only set to false in the face of an exception. If execution does not produce an exception it will remain true and no thread will ever again enter the if block.

Setting the timeout on a monitor to 0 can help implement the behaviour you want. Use a globally declared object to lock against.
static object mylock = new object();
....
if (Monitor.TryEnter(mylock, 0))
{
try
{
// Do work
}
finally
{
Monitor.Exit(mylock);
}
}

To add to the success above - to be sure the lock is released - the TryEnter() and Exit() can be wrapped in a custom class as an extension to object taking a Delegate and Timeout as a parameter.
public static class MyMonitor
{
public static bool TryEnter(this object obj, Action action, int millisecondsTimeout)
{
if (Monitor.TryEnter(obj, millisecondsTimeout))
{
try
{
action();
}
finally
{
Monitor.Exit(obj);
}
return true;
}
else
{
return false;
}
}
}
And called like this waiting 1000 ms to obtain the lock or throw an error if timeout:
if (!_locked.TryEnter(() =>
{
//Exclusive access code placed here..
}, 1000)) {
throw new TimeoutException("Timeout waiting for exclusive access");
}
This way the forgetting the Monitor.Exit() is not an option.

C#: Can you detect whether or not the current execution context is within `lock (this)`?

If I have an object that I would like to force to be accessed from within a lock, like so:
var obj = new MyObject();
lock (obj)
{
obj.Date = DateTime.Now;
obj.Name = "My Name";
}
Is it possible, from within the AddOne and RemoveOne functions to detect whether the current execution context is within a lock?
Something like:
Monitor.AreWeCurrentlyEnteredInto(this)
Edit: (for clarification of intent)
The intent here is to be able to reject any modification made outside of the lock, so that all changes to the object itself will be transactional and thread-safe. Locking on a mutex within the object itself does not ensure a transactional nature to the edits.
I know that it is possible to do this:
var obj = new MyObject();
obj.MonitorEnterThis();
try
{
obj.Date = DateTime.Now;
obj.Name = "My Name";
}
finally
{
obj.MonitorExitThis();
}
But this would allow any other thread to call the Add/Remove functions without first calling the Enter, thereby circumventing the protection.
Edit 2:
Here is what I'm currently doing:
var obj = new MyObject();
using (var mylock = obj.Lock())
{
obj.SetDate(DateTime.Now, mylock);
obj.SetName("New Name", mylock);
}
Which is simple enough, but it has two problems:
I'm implementing IDisposable on the
mylock object, which is a little bit
of an abuse of the IDisposable
interface.
I would like to change the SetDate and SetName functions to
Properties, for clarity.

I don't think that's possible without tracking the state yourself (e.g. by using some kind of semaphore). But even if it were, that'd be a gross violation of encapsulation. Your methods usually shouldn't care whether or not they're executing in a particular locking context.

There's no documented method of checking for this kind of condition at runtime, and if there were, I'd be suspicious of any code that used it, because any code that alters its behaviour based on the call stack would be very difficult to debug.
True ACID semantics are not trivial to implement, and I personally wouldn't try; that's what we have databases for, and you can use an in-memory database if you need the code to be fast/portable. If you just want forced-single-threaded semantics, that is a somewhat easier beast to tame, although as a disclaimer I should mention that in the long run you'd be better off simply providing atomic operations as opposed to trying to prevent multi-threaded access.
Let's suppose that you have a very good reason for wanting to do this. Here is a proof-of-concept class you could use:
public interface ILock : IDisposable
{
}
public class ThreadGuard
{
private static readonly object SlotMarker = new Object();
[ThreadStatic]
private static Dictionary<Guid, object> locks;
private Guid lockID;
private object sync = new Object();
public void BeginGuardedOperation()
{
lock (sync)
{
if (lockID == Guid.Empty)
throw new InvalidOperationException("Guarded operation " +
"was blocked because no lock has been obtained.");
object currentLock;
Locks.TryGetValue(lockID, out currentLock);
if (currentLock != SlotMarker)
{
throw new InvalidOperationException("Guarded operation " +
"was blocked because the lock was obtained on a " +
"different thread from the calling thread.");
}
}
}
public ILock GetLock()
{
lock (sync)
{
if (lockID != Guid.Empty)
throw new InvalidOperationException("This instance is " +
"already locked.");
lockID = Guid.NewGuid();
Locks.Add(lockID, SlotMarker);
return new ThreadGuardLock(this);
}
}
private void ReleaseLock()
{
lock (sync)
{
if (lockID == Guid.Empty)
throw new InvalidOperationException("This instance cannot " +
"be unlocked because no lock currently exists.");
object currentLock;
Locks.TryGetValue(lockID, out currentLock);
if (currentLock == SlotMarker)
{
Locks.Remove(lockID);
lockID = Guid.Empty;
}
else
throw new InvalidOperationException("Unlock must be invoked " +
"from same thread that invoked Lock.");
}
}
public bool IsLocked
{
get
{
lock (sync)
{
return (lockID != Guid.Empty);
}
}
}
protected static Dictionary<Guid, object> Locks
{
get
{
if (locks == null)
locks = new Dictionary<Guid, object>();
return locks;
}
}
#region Lock Implementation
class ThreadGuardLock : ILock
{
private ThreadGuard guard;
public ThreadGuardLock(ThreadGuard guard)
{
this.guard = guard;
}
public void Dispose()
{
guard.ReleaseLock();
}
}
#endregion
}
There's a lot going on here but I'll break it down for you:
Current locks (per thread) are held in a [ThreadStatic] field which provides type-safe, thread-local storage. The field is shared across instances of the ThreadGuard, but each instance uses its own key (Guid).
The two main operations are GetLock, which verifies that no lock has already been taken and then adds its own lock, and ReleaseLock, which verifies that the lock exists for the current thread (because remember, locks is ThreadStatic) and removes it if that condition is met, otherwise throws an exception.
The last operation, BeginGuardedOperation, is intended to be used by classes that own ThreadGuard instances. It's basically an assertion of sorts, it verifies that the currently-executed thread owns whichever lock is assigned to this ThreadGuard, and throws if the condition isn't met.
There's also an ILock interface (which doesn't do anything except derive from IDisposable), and a disposable inner ThreadGuardLock to implement it, which holds a reference to the ThreadGuard that created it and calls its ReleaseLock method when disposed. Note that ReleaseLock is private, so the ThreadGuardLock.Dispose is the only public access to the release function, which is good - we only want a single point of entry for acquisition and release.
To use the ThreadGuard, you would include it in another class:
public class MyGuardedClass
{
private int id;
private string name;
private ThreadGuard guard = new ThreadGuard();
public MyGuardedClass()
{
}
public ILock Lock()
{
return guard.GetLock();
}
public override string ToString()
{
return string.Format("[ID: {0}, Name: {1}]", id, name);
}
public int ID
{
get { return id; }
set
{
guard.BeginGuardedOperation();
id = value;
}
}
public string Name
{
get { return name; }
set
{
guard.BeginGuardedOperation();
name = value;
}
}
}
All this does is use the BeginGuardedOperation method as an assertion, as described earlier. Note that I'm not attempting to protect read-write conflicts, only multiple-write conflicts. If you want reader-writer synchronization then you'd need to either require the same lock for reading (probably not so good), use an additional lock in MyGuardedClass (the most straightforward solution) or alter the ThreadGuard to expose and acquire a true "lock" using the Monitor class (be careful).
And here's a test program to play with:
class Program
{
static void Main(string[] args)
{
MyGuardedClass c = new MyGuardedClass();
RunTest(c, TestNoLock);
RunTest(c, TestWithLock);
RunTest(c, TestWithDisposedLock);
RunTest(c, TestWithCrossThreading);
Console.ReadLine();
}
static void RunTest(MyGuardedClass c, Action<MyGuardedClass> testAction)
{
try
{
testAction(c);
Console.WriteLine("SUCCESS: Result = {0}", c);
}
catch (Exception ex)
{
Console.WriteLine("FAIL: {0}", ex.Message);
}
}
static void TestNoLock(MyGuardedClass c)
{
c.ID = 1;
c.Name = "Test1";
}
static void TestWithLock(MyGuardedClass c)
{
using (c.Lock())
{
c.ID = 2;
c.Name = "Test2";
}
}
static void TestWithDisposedLock(MyGuardedClass c)
{
using (c.Lock())
{
c.ID = 3;
}
c.Name = "Test3";
}
static void TestWithCrossThreading(MyGuardedClass c)
{
using (c.Lock())
{
c.ID = 4;
c.Name = "Test4";
ThreadPool.QueueUserWorkItem(s => RunTest(c, cc => cc.ID = 5));
Thread.Sleep(2000);
}
}
}
As the code (hopefully) implies, only the TestWithLock method completely succeeds. The TestWithCrossThreading method partially succeeds - the worker thread fails, but the main thread has no trouble (which, again, is the desired behaviour here).
This isn't intended to be production-ready code, but it should give you the basic idea of what has to be done in order to both (a) prevent cross-thread calls and (b) allow any thread to take ownership of the object as long as nothing else is using it.

Lets redisgn your class to make it actually work like transaction.
using (var transaction = account.BeginTransaction())
{
transaction.Name = "blah";
transaction.Date = DateTime.Now;
transaction.Comit();
}
Changes will not be propagated until commit is called.
In commit you can take a lock and set the properties on the target object.

You can override AddOne and RemoveOne to take a boolean flag that is set to true if it's being called from a lock. I don't see any other way.
You can also play with the ExecutionContext class if you want to know something about the current execution context. You can get the current context by calling ExecutionContext.Capture().

using thread local storage you can store the entering and exiting of a lock.

If your requirement is that the lock must be acquired for the duration of either method AddOne() or RemoveOne(), then why not simply acquire the lock inside each method? It shouldn't be a problem if the caller has already acquired the lock for you.
However, if your requirement is that the lock must be acquired before calling AddOne() and RemoveOne() together (because other concurrent operations performed on the instance are potentially unsafe), then maybe you should consider changing the public interface so that locking can be handled internally without concerning client code with the details.
One possible way to accomplish the later would be to provide methods for Begin- and End-Changes that have to be called before and after AddOne and RemoveOne. An exception should be raised if AddOne or RemoveOne is called outside of the Begin-End scope.

I ran into this same problem and created a helper class that looks like this:
public class BusyLock : IDisposable
{
private readonly Object _lockObject = new Object();
private int _lockCount;
public bool IsBusy
{
get { return _lockCount > 0; }
}
public IDisposable Enter()
{
if (!Monitor.TryEnter(_lockObject, TimeSpan.FromSeconds(1.0)))
throw new InvalidOperationException("Cannot begin operation as system is already busy");
Interlocked.Increment(ref _lockCount);
return this;
}
public bool TryEnter(out IDisposable busyLock)
{
if (Monitor.TryEnter(_lockObject))
{
busyLock = this;
Interlocked.Increment(ref _lockCount);
return true;
}
busyLock = null;
return false;
}
#region IDisposable Members
public void Dispose()
{
if (_lockCount > 0)
{
Monitor.Exit(_lockObject);
Interlocked.Decrement(ref _lockCount);
}
}
#endregion
}
You can then create an instance wrapped like this:
public sealed class AutomationManager
{
private readonly BusyLock _automationLock = new BusyLock();
public IDisposable AutomationLock
{
get { return _automationLock.Enter(); }
}
public bool IsBusy
{
get { return _automationLock.IsBusy; }
}
}
And use it like this:
public void DoSomething()
{
using (AutomationLock)
{
//Do important busy stuff here
}
}
For my particular case, I only wanted an enforcing lock (two threads shouldn't ever try to acquire the lock at the same time if they're well-behaved), so I throw an exception. You can easily modify it to perform more typical locking and still take advantage of the IsBusy.

Pattern for closing the state of a ServiceClient

I want to ensure that a WCF-ServiceClient State will be closed after using the service.
I implemented the following Code to ensure that:
public static class ServiceClientFactory
{
public static ServiceClientHost<T> CreateInstance<T>() where T : class, ICommunicationObject, new()
{
return new ServiceClientHost<T>();
}
}
public class ServiceClientHost<T> : IDisposable where T : class, ICommunicationObject, new()
{
private bool disposed;
public ServiceClientHost()
{
Client = new T();
}
~ServiceClientHost()
{
Dispose(false);
}
public T Client { get; private set; }
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
protected virtual void Dispose(bool disposeManagedResources)
{
if(!disposed)
{
if(disposeManagedResources)
{
Client.Close();
Client = null;
}
disposed = true;
}
}
}
usage:
using (var host = ServiceClientFactory.CreateInstance<MySericeClient>())
{
host.Client.DoSomething();
}
I was wondering if there is a better/elegant solution than mine?
Thanks for any hints!

The use of the using block is generally a good idea with disposable objects - but not in the case of a WCF proxy. The trouble is that when closing the proxy (at the end of the using block), there's a good chance of an exception - which then goes unhandled (potentially) and the proxy isn't really closed.
Recommended best practice would be:
try
{
var host = ServiceClientFactory.CreateInstance<MySericeClient>();
...... (use it).......
host.Close();
}
catch(FaultException)
{
host.Abort();
}
catch(CommunicationException)
{
host.Abort();
}
The trouble is - if anything does wrong during communication, your channel will be in a "faulted" state and calling ".Close()" on that channel will cause an exception.
Therefore, catch both the fault exceptions (signal from server something went wrong) and the CommunicationException (base class for Fault and other WCF client-side exceptions) and in that case, use proxy.Abort() to force an abort/close of the proxy (not waiting gracefully for the operation to complete, but just throwing in the sledgehammer).
Marc