You don’t manually destroy .Net objects. That’s what being a managed environment is all about. In fact, if the object is actually reachable, meaning you have a reference you can use to tell the GC which object you want to destroy, collecting that object will be impossible. The GC will never collect any object that’s … Read more
foreach (ManagementObject result in results) using(result) { //code here } It’s not normally good practice to assign the variable outside the using block because the resource would be disposed but could stay in scope. It would, however, result in clearer code here because you can nested the using statement against the foreach. EDIT: As pointed … Read more
A couple of important points should be made to address the OP’s question: .NET GC is non-deterministic (i.e. you never know nor should you depend on when it happens) Dispose is never called by the .NET Framework; you must call it manually – preferably by wrapping its creation in a using() block. Explicitly setting a … Read more
When you return an IDisposable from a method, you are relegating the responsibility of disposing it to your caller. Thus, you need to declare your using block around the entire usage of the stream, which in your case presumably spans the UploadFile call. using (var s = GetFileStream()) UploadFile(s);
Do I really need to Dispose() every Process object and how do I decide if I need to do so? Yes, you should dispose them. Note this text in the documentation for Process: A system process is uniquely identified on the system by its process identifier. Like many Windows resources, a process is also identified … Read more
The fact that you need to ensure that the object is disposed indicates a design flaw. It’s fine if disposing is the polite or efficient thing to do, but it should not be semantically necessary. There is no way to enforce that an object is disposed of via the using statement. However, what you can … Read more
The static variable of your class are not garbage collected until the app domain hosting your class is unloaded. The Dispose() method will not be called, because it is an instance method, and you said that you wouldn’t create any instances of your class. If you would like to make use of the Dispose() method, … Read more
The full pattern including a finalizer, introduction of a new virtual method and “sealing” of the original dispose method is very general purpose, covering all bases. Unless you have direct handles on unmanaged resources (which should be almost never) you don’t need a finalizer. If you seal your class (and my views on sealing classes … Read more
One option, which is somewhat nasty but would work, based on the fact that the C# compiler calls Dispose only if the resource is non-null: protected void ValidateExportDirectoryExists() { using (useNetworkAccess ? new Core.NetworkAccess(username, password, domain) : null) { CheckExportDirectoryExists(); } } Another alternative would be to write a static method which returned either null … Read more
Service is responsible for closing stream and unless you change default behavior it does it automatically (the behavior with defalut values is always used). If you set OperationBehavior.AutoDisposeParameters to false you must register handler for OperationContext.OperationCompleted and dispose the stream in the handler as described here. Client cannot close the stream because client has a … Read more