We Keep Coding

C# Initialize Disposable in inherited constructor

Hey so I have a base class coming from a 3rd party dll, which is dependent on a disposable. Context: IDisposable
public class BaseValidator
{
public BaseValidator(Context context) {}
}
We're trying to move away from tying our classes to these dependencies. So we started relying on providers instead
public interface IContextProvider
{
Context Create();
}
I have a new validator that I'm writing which inherits from the BaseValidator, but I would like it to be dependent on the IContextProvider instead. So I'd like to create the context in the inherited constructor, but I would like to dispose of it in the destructor to prevent memory leaks, However I'm not sure if this is possible.
public class EntityValidator: BaseValidator
{
public EntityValidator(IContextProvider provider) : base(provider.Create())
{
}
~EntityValidator()
{
//I'm not how I can dispose the entity I've passed into it.
}
}
My question is, is there a trick I can use to Capture the variable passed into the base?
Note: I know I can make a work around with an external helper class, but I'm interested if anyone knows how to do this in a more savvy way.

If the BaseValidator class does not expose Context in a public manner, your current design would require you use reflection and knowledge of the internal implementation of BaseValidator to dispose of it, which is of course fragile.
I would instead capture the context using an intermediate constructor:
Context _context;
private EntityValidator(Context context) : base(context)
{
_context = context;
}
public EntityValidator(IContextProvider provider) : this(provider.Create())
{
}
Note, disposing via a finalizer (a.k.a. destructor) is not ideal due to constraints it places on the garbage collector. I'd instead have EntityValidator implement IDisposable

Before, in other language like C++, developpers used to rely on destructors to do a lot of cleaning. It was guaranteed by compiler so it was a strong behavior.
Smart pointer was a good pattern that used this behavior (to implement something like very basic but automatic garbage collection system).
Code was elegant but people used it for a lot of other need. With time a lot of code used to happen in destructor making the debug and readability hard.
IDisposable has been made to force developpers to write explicitely the call to Dispose... This is also useful when you want to Dispose internal resource without your object being destructed. For example in some "Close" method of Stream, where the stream is definitively closed but you can still have reference on steam... and use IsOpen property...
So for me you should not try to hide it. If you depends on code that needs to be Disposed, embrace this dependency... or chose another third party library.
You can simply make the class that need to manipulate Disposable object (BaseValidator) IDisposable too and delegate the need to call to the user.
Usually people that write class implementing IDisposable, in open source project, also write destructor (just in case someone forgot to call Dispose) This is true for a lot of class of .Net framework too (for example Pen() { where nobody thinks to call Dispose on it in some Control drawing events...)
So I would recommend :
Go get the information about if they did it with their classes, if yes they are strong probability they will keep this behavior/code forever. So you can just make your class to inherit IDisposable too, call context.Dispose in your own Dispose implement and that's enough... no need to worry because if your user forgot to call Dispose, the third party do the cleaning. Add a destructor/finalizer on your class only if you have other unmanaged resource to clean too...
Now if they did not, you can just wrap third party "Context" class in your own Context class. Your Context class will have to implement destructor that call Dispose on the instance of third party Context class. And that's it. You can even make your Context class sealed. Your Context class is here to make the behavior of your app as close as if 1) was true and implemented by third party. So this class will be easy to remove later because third party will probably implement finalizer one day (if they are serious). Doing just a sealed wrapper around just one class will avoid some complexity/issue related to how destructors (finallizers) works in .Net : They are all called in any order. Because of this underterministic behavior it makes your code hard to maintain later. For example if third party Context class's finalizer is called before your wrapping class => exception can occured and at a bad time (when gc is doing its stuff) which can make your app crash. Because of all these problems, you better go back to 1)

Inherit or wrap a class that deals with concurrency

In trying to provide a unit-testable (using Moq) abstraction of ConcurrentQueue<T> I am debating whether I lose the benefits of using the framework's ConcurrentQueue<T> implementation depending on how I author the abstraction.
What are the implications of doing one or the other in the following code listing:
public abstract class MyMessageQueue1<T> : ConcurrentQueue<T>
{
public new virtual void Enqueue(T item)
{
base.Enqueue(item);
}
}
public class MyMessageQueue2<T>
{
private readonly ConcurrentQueue<T> _concurrentQueue =
new ConcurrentQueue<T>();
public virtual void Enqueue(T item)
{
_concurrentQueue.Enqueue(item);
}
}
In the first implementation (MyMessageQueue1), I hide any of the base class methods as to provide my implementation before passing the call to the base class.
In the second implementation, I wrap the ConcurrentQueue<T>inside and pass calls to it when I need to.
Does MyMessageQueue2 have to manually handle concurrency or does it not matter as all calls are passed to the wrapped ConcurrentQueue<T>.

You don't have to handle concurrency in either case because all you do is just delegating calls to the ConcurrentQueue as has been stated by #nanda. However, it would help us to know your reason to wrap this class. It is fairly unit-testing friendly in the sense that it doesn't use any external resources like files or a database. When being used in your classes you can just leave it doing its job and rather testing your own functionality that uses the ConcurrentQueue.
If you are trying to wrap it because you would like to verify whether your methods use it in desired way, you are probably focusing on testing of implementation of your method rather than the method's behaviour. Which might be useful in certain scenarios but you have to be aware of that fact and it is not a common practise.
There is one thing that you are losing when writing wrappers like these. Because wrappers have virtual methods so that they can be mocked, methods can't be inlined and a bit of performance is lost. ConcurrentQueue is slim and fast class and this might actually be an issue.

If all the wrapper does is delegation to ConcurrentQueue, and the wrapper does not have it's own members to protect for concurrent access then there is nothing to be done for concurrency for your wrapper.
But what would you be unit testing on this thin wrapper?

How to avoid a "DisposableFieldsShouldBeDisposedRule" defect on fields I don't want to dispose?

There is a IDisposable which contains a field for the Logger:
class DoesNotDisposeMember : IDisposable {
public IDisposable Logger { get; set; }
public void Dispose ()
{
logger = null;
}
}
Gendarme reports that there is a DisposableFieldsShouldBeDisposedRule-Defect, but I don't want to dispose the logger.
Can anyone help me?

Setting side why you wouldn't want to dispose of it; if you don't want to dispose of it, you probably should not be storing it in an IDisposable member, then. The only real purpose of that interface is to signify/enable that item being disposed.
If it's a logging object, is there not another common base interface/class you can use, such as one derived from Stream or StreamWriter?
Now that I've written that, it of course strikes me that this still includes IDisposable in the hierarchy... which I suppose brings us back to what I said I would set aside:
Why are you setting a variable here that you do not intend to dispose of? If you are disposing of it elsewhere, you should probably also use it there. The code that is wrapping the logger object should handle all the functionality of it, including exposing the separate interface to your model/business objects that enables logging.
Basically, if you are encapsulating the logging in another object, then you should not be referencing the internal logging stream object outside of that object. If you aren't encapsulating logging elsewhere, then this class should dispose of it appropriately.

Improving a connection class with methods: Open and Close

I am using .NET 3.5 C#. I have a simple connection class with only two methods: OpenConnection() and CloseConnection(). I defined this class as Static so that I don't have to create an instance while calling methods. I want to know whether:
(1) I should create an interface with method definitions for OpenConnection and CloseConnection and thereby use this Interface with Connection class. There is no reason to use an interface but I was thinking whether the Connection can be made more professional.
(2) Is it fine to declare this class as Static?

There are two entirely different approaches
Singleton: Single object across the application.
In this case, you will have to take care of the locking mechanism as well.
class Connection
{
public static Connection Instance() {
if (_instance == null) {
lock (typeof(Connection)) {
if (_instance == null) {
_instance = new Connection();
}
}
}
return _instance;
}
protected Connection() {}
private static volatile Connection _instance = null;
}
Implement IDisposable:
Alternatively, you can implement IDisposable in your Connection class, and let it disposed automatically using the using keyword. For instance:
using(Connection c = new Connection(SomeConfiguration)) //Opens the connection.
{
Something(c);
}// Closes the connection. Dispose is implicitly called in the scope of the using statement.
Or if you want Generic Connection class, then Marc has responded with an excellent database connection class example here.
Regarding point 1; you can use interface; iff:
You want loose coupling, componentization, and maintainability in your code.
You want to provide guarantee that the classes shall behave exactly as methods/contracts defined in interface. For instance, in this case, if you extend your class from IDisposable, the interface imposes that not only objects can be disposed without getting compiler errors, but that they should be disposed. So, similar guarantees can be provided in your code by simply adhering to an interface.
You have a team that is going to working on a large module; and you want to keep code consistent; so you can define an interface and add some restrictions, that would help integrate the it easily. For instance:
You know you have a module that is going to handle alot of connections, different types of connections - some of which may be identified later during the development. But what you know for sure is that all types of connection shall be able to Open and Close; and you also want all of the developers to stick to this rule. So you can come up with an interface like:
interface IMyConnection
{
Open();//Opens the connection
Close();//Closes the connection
}
You expect have certain classes that does a lot of complex work and won't be finished before the rest of the project; then rest of the project can use the interface and avoid being dependent on that class.
You plan to deploy your product commercially; and want it to be extendable by 3rd party developers.

If you use interface, you cannot define Static method. (or in other word, static method is always pointing to the class defined, so the interface cannot provide abstraction at this point).
A class can be static, as long as you want everything shared, and extension to it is not necessary. But I would strongly recommend you to look at Singleton Pattern and Abstract Factory as alternative to your design problem.
interface IConnection {
void Connect();
void DisConnect();
}
class TCPCustomConnection : IConnection{
// implement other stuff
// Singleton Pattern
static IConnection Instance {
privateInstance = privateInstance ?? new TCPCustomConnection();
return privateInstance;
}
}

From what you said so far, I don't see how the interface adds value. If it does not add value, it should be eliminated from the design. The interface introduces two new problem: You need to get a pointer to the interface implementation, and usually you want to avoid asking for it repeatedly. So don't do it unless adds value (in a tangible, not metaphysical way) to your design.
An interface might add value if it simplifies unit testing of your code, or if it is important to remove the runtime dependency on the assembly that implements the connection. This is very fashionable these days.

simple a static class is requird, if it just used for demarcating operations like open and close connection, favor simplicity rather, dont code for future scenario until it is absolutely necessary and don't change existing working code till you reach a point where it is absolutely requirea

My advice:
(1) Why you need to write your own Connection class since it's "a simple connection"? None of the built-in classes meets your requirement?
(2) According to MS examples, it's really weird to make Open and Close methods static. We are used to this:
conn.Open();
conn.Close();
instead of:
MyConnection.Open(conn);
MyConnection.Close(conn);
(3) Using interfaces is a good idea, especially IDisposable:
class MyConnection : IDisposable
{
public void Dispose()
{
//close the connection and release resources
}
}
using (MyConnection conn = new MyConnection(connStr))
{
} //automatically Dispose()

If you have different connection type, like UDP, TCP, COM Port, ... using interface is good for manageability, but in the case which you have just one connection there is no need to use interface, also i think using static and singleton is not useful here, you should have a service for your tcp connection to always keep it up, and when you got disconnected you should be able to repair connection. for a good tcp server sample see http://fadd.codeplex.com/SourceControl/changeset/view/58859#1054893.

Even if you think that you'll only ever need one connection, I'd still use an instance class that implements an interface to handle it.
Why?
I can easily swap implementations if I need to (or refactor an existing one).
I can unit test things that depend on the class by mocking the connection.
I can more easily control the lifecycle of the connection (eg by using IDisposable).
Consumers of any API I write can see what my dependencies are.
If the single instance requirement does change, I don't have to unpick all the references to the static/singleton methods.
The testing point here is important: if you use a static reference to a fixed external resource, your code will be virtually impossible to unit test independently of that resource.
See this answer for a similar discussion about static versus instance classes and methods.

How to make an IDisposable object a class variable?

I am working with Active Directory using C#. Instantiating the PrincipalContext object seems to be expensive, so I'd like to store one in a class variable.
When using PrincipalContext as a local variable, I can use the convenient using syntax. When storing an IDisposable object in a static variable, how do I ensure the object is properly disposed of?

The general pattern for this is to implement the IDisposable interface on your class. Take this example:
public class YourClass : IDisposable
{
private OtherDisposableType yourResource;
public YourClass()
{
yourResource = new OtherDisposableType();
}
public void Dispose()
{
yourResource.Dispose();
}
}
This is, at a minimum, what you need to do.
EDIT
My previous version advocated following the finalizer pattern in all cases, which was (correctly) pointed out to be against the framework design guidelines. However, in the event that you're actually dealing with unmanaged resources (for example, you're making direct P/Invoke calls and obtaining a handle that needs to be explicitly freed) it's advisable that you create a finalizer and call Dispose within it to protect against people who consume your code and don't call Dispose:
public class YourClass : IDisposable
{
private OtherDisposableType yourResource;
public YourClass()
{
yourResource = new OtherDisposableType();
}
public void Dispose()
{
yourResource.Dispose();
GC.SuppressFinalize(this);
}
~YourClass()
{
Dispose();
}
}

Look at what the System.ComponentModel namespace does. Basically, the pattern I typically use is to have a collection of subcomponents, which includes everything I own that's not a 'value' - whether or not it implements IDisposable.
Then, when I Dispose() myself, I iterate over this collection and Dispose anything that implements IDisposable.
One advantage of this technique is that if an object I own starts out not being Disposable, but later adds the IDisposable interface, my class will do the right thing without ever having to change.
Also, use of a DI/IoC container can handle much of this for you.

So basically you want to cache an expensive resource. That's a good thing.
Global data (static variables in this case) is not such a good thing, IMHO. Instead, why not make it an instance variable and control the lifetime?
Write your class that handles the AD responsibilities, have it create and use the PrincipalContext, and make it IDisposable as well (using the Dispose Pattern). Extract an interface from it to decouple it and make classes that use it easier to test.
Classes that want to use AD services will take a constructor parameter of your new interface (Dependency Injection or DI). You can either create your class manually in a using block and pass it to the classes or use a DI Container Framework. You can have the framework set the lifetime of the AD object to the lifetime of the container (which may also be IDisposable). See How do you reconcile IDisposable and IoC? and your DI Container documentation for more on this.