We Keep Coding

Is it safe to call CancellationTokenSource.Cancel multiple times?

For example, if I want to cancel some operation in a Dispose() call (which can be called multiple times), then do I need to write
public void Dispose()
{
if (!cancellationTokenSource.IsCancellationRequested)
{
cancellationTokenSource.Cancel();
}
}
or is it enough with the simpler
public void Dispose()
{
cancellationTokenSource.Cancel();
}
(You are welcome to comment on whether it is wise or not to cancel things in a Dispose method, but that is not the point of this question.)

Yes.
But only if the CancellationTokenSource has not been disposed yet.
From the reference source:
ThrowIfDisposed();
// ...
// fast-path test to check if Notify has been called previously
if (IsCancellationRequested)
return;

This seems more a question about the Dispose pattern, then about CancellationToken or anything else. And I am uncertain if you implemented said pattern properly. Here is the official MS Document on the mater:
https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/dispose-pattern
And here my interpretation:
There is two levels of Disposing: Dispose and Finalizsation. As the code for both is very similar, often they are combiend into one function (in C# usually it is Dispose one). The main difference is if you relay it to contained classes. You always relay a Dispose call(the relay is usually what Dispose is about). You never relay a Finalization call (Finalisation is between that instance and the GC only).
There are also two cases: One in wich you handle Unmanaged resources directly. And one in wich you handle just another Disposeable class.
Unamanged resource directly
In this case the first thing you do is implement a Finalizer, so at least the GC can reliably clean this up. Then you implement IDisposeable as an additional feature so programmers can use stuff like the using pattern to have it cleaned up deterministic at runtime.
Handling something that implements IDisposeable
You have a resource that implements IDisposeable (say like a Filestream Reference). You implement IDisposeable in your class for the sole purpose of relaying the Dispose() call to said FileStream. This is the way more common case. It would guess it makes about 95-99% of all Dispose Implementations.
One thing to keep in mind here is that "Dispose" and "Finalize" often implies lower level cleanup. A SQLConenction you call dispose on will be closed first (if nessesary). A Filehandle you Dispose off will also first be closed. Even if calling cancellationTokenSource.Cancel was not repeatable, cancellationTokenSource.Dispose should call Cancel as part of it's operation and should be Repeatable. The class itself does implement IDisposeable. And if any class does, it is usually saver to just call Dispose rather then manually doing the cleanup manually via Cancel: https://learn.microsoft.com/en-us/dotnet/api/system.threading.cancellationtokensource?view=netframework-4.7.2

Should I add a destructor/finalizer to my class that contains a Dataset?

I've read through this post about disposing of datasets and I still have a question about the destructor. I know that post basically says that you don't need to dispose of Datasets, Datatables, and Dataviews, but my dataset is MASSIVE, so I want to release that memory ASAP. So, my question, should I include a destructor even though the dataset will be disposed when my objects' dispose method is called? Also, explain to me again why the "bool disposing" is needed.
public DEditUtil(DataSet dsTxData)
{
this.dsTxData = dsTxData;
}
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
protected virtual void Dispose(bool disposing)
{
if (!disposed)
{
if (disposing)
dsTxData.Dispose();
disposed = true;
}
}
~DEditUtil()
{
Dispose(false);
}

Yes, in general you should implement the full IDisposable pattern whenever either of the following is true:
You have unmanaged resources being allocated by your class, or
You have managed resources that implement IDisposable (which implies that they, in turn, have unmanaged resources)
The presence of the finalizer (the general CLR term for what C++/C# call a "destructor") is to handle cases where your Dispose method is not called for some reason. The boolean value being passed in to your protected Dispose() method indicated if you are being called from within the public Dispose, or from within your finalizer.
If your public Dispose method is being called, that call stack is deterministic: your dispose method is being called directly, so you can safely call methods (including Dispose) on your child objects.
If you are inside of the finalizer, then you have no idea what's going on with other objects that are also being garbage-collected. In general, it may not be safe to call methods on managed objects your control from within your finalizer.
So, the boolean value basically says: "if true, dispose everything; if false, only dispose my unmanaged resources and let everyone else deal with theirs."

The memory used by your DataSet object will be available for garbage collection as soon as it is not referenced anymore by the code.
The garbage collector will make that memory available to the program at a later (non determinate) time.
Both things do not depend of having or not a destructor or calls to Dispose, so the answer is no - you don't need a destructor.

No, you do not need any other method call here, it's already enough what you did.
Dispose will be called by the runtime and you will free resource allocated, the cleanup let's leave up to GC to decide how and when to do it.
If you have really huge problems with memory you can try to cal GC.Collect() to enforce the collection of the garbage, that usually works, but it's never a good practise to use it in that way, so try to avoid it as much as possible.
EDIT
According to the comments, it's important to pay attention on execution flow in your case, cause the DataSet cleanup will be done only if it's not disposed==false and disposing == true, which from the code provided, will be a case only during esplicit call from the code.

Very seldom should user-written classes ever use finalizers (or C# destructors) for any purpose other than to log failures to call Dispose. Unless one is delving deep into the particulars of how finalizers work, and exactly what is or is not guaranteed guaranteed about the context in which they run, one should never call any other object's Dispose method within a finalizer. In particular, if one's object's Finalize() method is running, any IDisposable objects to which it holds a reference will usually fall into one of the following categories:
Someone else still has a reference to that object and expects it to be usable, so calling `Dispose` would be bad.
The object cannot be safely disposed within a finalizer thread context, so calling `Dispose` would be bad.
The object would have kept the present object alive if there were anything meaningful for its `Dispose` handler to do; the fact that the present object's `Finalize` method is running implies that there's no longer any need to call `Dispose` on the other object (this scenario can occur with events).
The object has already had its `Finalize` method called, so calling `Dispose` would be at best superfluous.
The object is scheduled to have its `Finalize` method called, so calling `Dispose` would likely be superfluous.
Although there are a few cases where an object might need to clean up another IDisposable object within a Finalize method, using Finalize properly in such cases is tricky, and using it improperly is apt to be worse than not using it at all. Among other things, Finalize generally only runs when an entity requests an IDisposable and wrongfully fails to call Dispose before abandoning it. It's usually better to focus one's efforts on making sure that Dispose gets properly before an object is abandoned, than on trying to properly handle buggy consumer code.

Calling Dispose() vs when an object goes out scope/method finishes

I have a method, which has a try/catch/finaly block inside. Within the try block, I declare SqlDataReader as follows:
SqlDataReader aReader = null;
aReader = aCommand.ExecuteReader();
In the finally block, the objects which are manually disposed of are those which are set at the class level. So objects in the method which implement IDisposable, such as SqlDataReader above, do they get automatically disposed of? Close() is called on aReader after a while loop executes to get the contents of the reader (which should be Dispose() as that calls Close()). If there is no call to Close(), would this object be closed/disposed of automatically when the method finishes or the object goes out of scope?
EDIT: I am aware of the using statement but there are scenarios which are confusing me.

No, objects are not automatically disposed when they go out of scope.
They're not even guaranteed to be disposed if/when they're garbage-collected, although many IDisposable objects implement a "fallback" finaliser to help ensure that they're eventually disposed.
You are resposible for ensuring that any IDisposable objects are disposed, preferably by wrapping them in a using block.

You should use a using {...} block to wrap your IDisposable objects in - the Dispose() method (which for SqlDataReader passes off to the Close() method) will be called when the using block ends. If you do not use using, the object will not be automatically disposed when it goes out of scope - it will be up to the object finalizer, if it has one, to get rid of resources when it is garbage collected
using (SqlDataReader aReader = aCommand.ExecuteReader())
{
// ... do stuff
} // aReader.Dispose() called here

I agree with all of the above. You should make sure you call Dispose() yourself, and the easiest way to to this is with the using statement (you can also do this yourself in the finally block - this is more verbose, but sometimes necessary). If you don't do this you can find your application leaking unmanaged resources such as handles, or even unmanaged memory, especially if somewhere underneath all of this some COM components are being used, or calls are being made into the Win32 API. This can obviously lead to performance and stability problems, as well as excessive resource usage.
Just because objects that implement IDisposable "should" implement a finaliser that calls their Dispose(bool disposing) method to free unmanaged resources, is no guarantee that this will happen, so you definitely should not rely on it. See, for example, http://msdn.microsoft.com/en-us/library/b1yfkh5e%28VS.71%29.aspx for more information on this point.
Also, something else to bear in mind, is that if your type has members that are disposable, your type should either implement IDisposable (unless the lifecycle of those members is managed by another type, which obviously might get messy), or, if you only use such members in one method, or to implement one particular piece of functionality, you should consider making them local variables/parameters in the methods that use them.

The Dispose pattern doesn't make any guarantees about which objects will call Dispose on which other objects; it may happen sometimes, but you shouldn't care. Instead, it's your responsibility to make sure Dispose() is called for all IDisposable objects. The best way to do that is with the using statement. For example:
using (SqlDataReader aReader = aCommand.ExecuteReader())
{
// your code
}

I am puzzled by the statement "In the finally block, the objects which are manually disposed of are those which are set at the class level." By objects set at the class level, do you mean fields? You probably shouldn't be disposing of these within a ordinary method, because then the life-time of the fields is unpredictable, and depends on which methods you happened to have called. It would be better to implement IDisposable and dispose of fields in your Dispose method.

Might the Using statement help?

Using an object in a constructor which has to be Disposed of

In a class I am writing, I am using an object to set some of its properties in a custom class I am writing.
This is being done in the constructor, but the class has a Dispose() method.
I have never actually used an object in a constructor which has a Dispose() method/implements IDisposable. Should I wrap this in a using(...) statement or should I implement a destructor/finalizer?
My imagination has made me ask this: This class is part of a third party closed source API. How can I find out what needs to be disposed of?
Thanks

If your reference to the object is local to the constructor then just wrap it in a using statement.
If your reference to the object is a class member then your class should implement IDisposable as well, with it's Dispose() method calling Dispose() on the object.

Just to add in response to the other parts of your question:
You should generally only implement a finalizer where you are using unmanaged resources which might need to be cleaned up if your program terminates abnormally. Any managed objects will be tidied up by the GC at some point. Don't rely on a finalizer to dispose of any managed objects as you can't predict when it will be executed.
You don't need to care about what needs to be disposed of. You should trust that where a class implements IDisposable, it takes care of everything through that pattern. If it's badly coded then you may encounter problems, but I'd be optimistic in this case.
I'd always opt for wrapping IDisposables in a Using block where possible as I think it's neater than trying to call the Dispose() method explicitly.

if you don't need the object outside the constructor, why don't you use the using statement ?
If there is a special "destruction" code - using is not enough and you need to call it's disposal code from some place...

When should I use "using" blocks in C#? [duplicate]

This question already has answers here:
What are the uses of "using" in C#?
(29 answers)
Closed 8 years ago.
Are there particular instances where I should (or shouldn't?) be using "using" blocks:
using(SomeType t = new SomeType()){
...
}

Some objects need some action to be taken when you have finished with them. Usually this is because the object uses some kind of resource that needs to be disposed of. For example, if you have a file object of class File, and this object opens a file from the file system, the file in the file system will need to be closed again.
If you just left the file object, and forgot to call file.Close() it wouldn't be cleaned up until the Garbage Collector (GC) ran and worked out nothing was still using the file object. When the Garbage Collector runs should be left to the Common Language Runtime (CLR) to decide. If the GC doesn't run for quite a while after you have finished with the file, the file could remain open potentially for a long time. This can pose a big problem if there are many file objects, or if something wants to open a file, but can't because the file object you left is still hanging around.
To solve this problem, C# has the IDisposable interface. This has one method called Dispose. Classes that require some cleanup implement this Dispose method. This gives you a standard way for cleaning up any objects that use resources. There are a lot of classes that need to have Dispose called. The problem with this is that code gets covered with calls to Dispose, and they are tricky to follow because the place where you new'ed the object and call Dispose to clean it up are different. So, you had to look around the code a lot and be very careful to check there were calls to Dispose in the right place.
To solve this problem C# introduced the 'using' keyword. You can put a 'using' keyword around where you new an object, and this ensures Dispose will be called on it for you. It guarantees that Dispose will be called whatever happens... even if there is an exception thrown within the body of the using statement.
So, you should use 'using' when you want to be sure an object that allocates resources will be cleaned up.
using can only be used for objects that are declared on the stack, i.e. in a function. It doesn't work for objects that are declared as members of a class. For them, you have to call Dispose yourself. You may have to implement Dispose in your class so that in can call Dispose on any member objects it has that require it.
Common objects that need using called on them are: Files, Database connections, Graphics objects such as Pen and Brush.
Sometimes it is also used when you want two operations to happen together. For example if you want to write a log statement when a block of code is entered and when it exits you could write a log class that you could use like this:
using( Log log = new Log("Doing stuff") )
{
// Stuff
}
The constructor for the log class could be made to write out the message, and the Dispose method could also write it out. Implement the finalizer (~Log) to assert if the Dispose method doesn't get called to ensure the 'using' is remembered around the 'new Log'.

When the SomeType class implements IDisposable.

Use using whenever the type implements IDisposable, unless you're going to wrap it in a try/catch block anyway, then you might as well (depending on what look you prefer) use a finally block.

I see plenty of other answers indicated when you should have a using statement. I want to address when specifically should not have a using statement:
If you need to use your object outside of the scope of the current function, don't have a using block. Good example are a factory method that returns a database connection or a method that needs to return a datareader. In either of those cases if you create your object with a using statement it would be disposed before the method returned, and therefore not usable outside the method.
Now, you still want to be sure that those objects are disposed, so you still might want a using statement somewhere. Just don't include it in the method where the object is actually created. Instead, you can wrap the function call itself in a using statement.

When SomeType implements IDisposable.
That is a clue to you the developer that SomeType uses unmanaged resources that need to be cleaned up.

Example:
using(SqlConnection MyConnection = new SqlConnection("Connection string"))
{
MyConnection.Open();
//...
// 1. SQLConnection is a type that implements IDisposable
// 2. So you can use MyConnection in a using statement
// 3. When using block finishes, it calls Dispose method of
// SqlConnection class
// 4. In this case, it will probably close the connection to
// the database and dispose MyConnection object
}
You can create your own objects that implements IDisposable:
public class MyOwnObjectThatImplementsIDisposable : IDisposable
{
//... some code
public void Dispose()
{
// Put here the code you want to be executed when the
// using statement finish.
}
}
So you could use an object of MyOwnObjectThanImplementsIDisposable type in a using statement:
using(MyOwnObjectThatImplementsIDisposable MyObject = new MyOwnObjectThatImplementsIDisposable)
{
// When the statement finishes, it calls the
// code you´ve writed in Dispose method
// of MyOwnObjectThatImplementsIDisposable class
}
Hope this helps

In this context the using statement is handy for types that implement IDisposable. When the code block exits the scope of the using statement, Dispose() is called implicitly. It's a good habit when working with objects you want to dispose immediately after use.

One specific instance in which you should be careful using a using block is with a WCF Service Client.
As noted in this MSDN article, wrapping a WCF client (which does implement IDisposable) in a using block could mask any errors which result in the client being left in a faulted state (like a timeout or communication problem). Long story short, when Dispose() is called, the client's Close() method fires, but throws and error because it's in a faulted state. The original exception is then masked by the second exception. Not good.
There are various workarounds out there, including one in the MSDN article itself. Others can be found at IServiceOriented and blog.davidbarret.net.
I prefer the last method, myself.

If you want a summary rule. Anytime an object using IDisposable where you would not have a catch, use using. Using, essentially, is this pattern:
try
{
//instantiate and use object
}
finally
{
//dispose object
}
If you do not need a catch, using can save you typing, which is a good thing.

The primary rule is:
* Use USING statement when objects implements IDisposable interface.
This interface provides the Dispose method, which should release the object's resources. If this method is not invoked then the object will stay in memory as long, as CLR wants to perform garbage collection. If the programmer use the USING statement then on the end the object will be disposed, and all resources will be free.
It is very important that all resources that are no longer in use be free as soon as possible.
For more information about it just visit this link: microsoft

Maybe it is worth mentioning that underlying reason for adding “using” lo C# languge is following: some resources can be scarce enough that it doesn’t make sense to wait for GC to call IDisposable. For example, DB connections. If you use try/catch/finally you won’t end up with a dangling connection, but connection will be left hanging until GC doesn’t kick in and this can take a while (if you do not close it explicitly). IF you use "using" (excuse the pun) you will release the connection immediately even if you forgot to close it and even if some exception occured inside the using block.
Another reason, as previous post mentions, is that programmers do not always use finally to clean up. If not using finally in the case of exception you end up with leaking resources…

One situation is when you want to do something at the beginning of a code block, and then undo it at the end of the block, unconditionally (even if there is a throw).
The ctor for the disposable class that you build (and call within the using) would perform the action, and then the Dispose method would undo that action. This is typically how I use it.

Other people has mentioned about "IDisposable" already.
But one of the caveats when using "using" statement is that,
any exceptions thrown within "using" will not be caught
even thought "SomeType" will be disposed regardless.
So in the following snippet,
using (SomeType t = new SomeType()){
throw new Exception("thrown within using");
}
throw new Exception("thrown within using"); should not be disregarded.

I would also add that use a using() statement if something implements IDispose and also if that something you want to dispose of holds on to NON-MANAGED resources like database connections and file handles.
If it's a normal object with say a List<T>, where T is like a Customer object that holds names and address, then you don't need to. The garbage collector is smart enough to manage this for you. But the garbage collector WILL NOT return connections to the connection pool or close file handles.