Search Results

Search found 257 results on 11 pages for 'idisposable'.

Page 4/11 | < Previous Page | 1 2 3 4 5 6 7 8 9 10 11  | Next Page >

  • using ‘using’ and scope. Not try finally!

    - by Edward Boyle
    An object that implements IDisposable has, you guessed it, a Dispose() method. In the code you write you should both declare and instantiate any object that implements IDisposable with the using statement. The using statement allows you to set the scope of an object and when your code exits that scope, the object will be disposed of. Note that when an exception occurs, this will pull your code out of scope, so it still forces a Dispose() using (mObject o = new mObject()) { // do stuff } //<- out of Scope, object is disposed. // Note that you can also use multiple objects using // the using statement if of the same type: using (mObject o = new mObject(), o2 = new mObject(), o3 = new mObject()) { // do stuff } //<- out of Scope, objects are disposed. What about try{ }finally{}? It is not needed when you use the using statement. Additionally, using is preferred, Microsoft’s own documents put it this way: As a rule, when you use an IDisposable object, you should declare and instantiate it in a using statement. When I started out in .NET I had a very bad habit of not using the using statement. As a result I ran into what many developers do: #region BAD CODE - DO NOT DO try { mObject o = new mObject(); //do stuff } finally { o.Dispose(); // error - o is out of scope, no such object. } // and here is what I find on blogs all over the place as a solution // pox upon them for creating bad habits. mObject o = new mObject(); try { //do stuff } finally { o.Dispose(); } #endregion So when should I use the using statement? Very simple rule, if an object implements IDisposable, use it. This of course does not apply if the object is going to be used as a global object outside of a method. If that is the case, don’t forget to dispose of the object in code somewhere. It should be made clear that using the try{}finally{} code block is not going to break your code, nor cause memory leaks. It is perfectly acceptable coding practice, just not best coding practice in C#. This is how VB.NET developers must code, as there is no using equivalent for them to use.

    Read the article

  • ObjectContext disposed puzzle

    - by jaklucky
    Hi, I have the follwing method. public List<MyEntity> GetMyEntities(MyObjectContext objCtx) { using(MyObjectContext ctx = objCtx ?? new MyObjectContext()) { retun ctx.MyEntities.ToList(); } } The idea is, user of this method can pass in the objectcontext if they have. If not then a new objectcontext will be created. If I am passing an object context to it, then it is getting disposed after the method is done. I was expecting only "ctx" variable gets disposed. If I write a small app, to know the using and dispose mechanism. It is acting differently. class TestClass : IDisposable { public int Number { get; set; } public string Str { get; set; } public ChildClass Child { get; set; } #region IDisposable Members public void Dispose() { Console.WriteLine("Disposed is called"); } #endregion } class ChildClass : IDisposable { public string StrChild { get; set; } #region IDisposable Members public void Dispose() { Console.WriteLine("Child Disposed is called"); } #endregion } class Program { static void Main(string[] args) { TestClass test = null; test = new TestClass(); test.Child = new ChildClass(); using (TestClass test1 = test ?? new TestClass()) { test1.Number = 1; test1.Str = "hi"; test1.Child.StrChild = "Child one"; test1.Child.Dispose(); } test.Str = "hi"; test.Child.StrChild = "hi child"; Console.ReadLine(); } } In this example, "test1"gets disposed but not "test". Where as in the first case both ctx and objCtx get disposed. Any ideas what is happening here with objectContext? Thank you, Suresh

    Read the article

  • Constructing a WeakReference<T> throws COMException

    - by ChaseMedallion
    The following code: IDisposable d = ... new WeakReference<IDisposable>(d); Has started throwing the following exception on SOME machines. What could cause this? System.Runtime.InteropServices.COMException: Unspecified error (Exception from HRESULT: 0x80004005 (E_FAIL)) EDIT: the machines that experience the error are running Windows Server 2008 R2. Windows Server 2012 and desktop machines running windows 7 work fine. (this is true, but I now think a different issue is the relevant difference... see below). EDIT: as an additional note, this occurred right after updating our codebase to Entity Framework 6.1.1.-beta1. In the above code, The IDisposable is a class which wraps an EF DbContext. EDIT: why the votes to close? EDIT: the stack trace of the failure ends at the WeakReference<T> constructor called in the above code: at System.WeakReference`1..ctor(T target, Boolean trackResurrection) // from here on down it's code we wrote/simple LINQ. None of this code has changed recently; // we just upgraded to EF6 and saw this failure start happening at Core.Data.EntityFrameworkDataContext.RegisterDependentDisposable(IDisposable child) at Core.Data.ServiceFactory.GetConstructorParameter[TService](Type parameterType) at System.Linq.Enumerable.WhereSelectListIterator`2.MoveNext() at System.Linq.Buffer`1..ctor(IEnumerable`1 source) at System.Linq.Enumerable.ToArray[TSource](IEnumerable`1 source) at Core.Data.ServiceFactory.CreateService[TService]() at MVC controller action method EDIT: it turns out that the machines having issues with this were running AppDynamics. Uninstalling that seems to have removed the issue.

    Read the article

  • WCF: Is it safe to override the Client's Dispose method using a partial class?

    - by pdiddy
    I'd like to override the Dispose method of generated proxy (ClientBase) because of the fact that disposing of a proxy calls Close and can throw an exception when the channel is faulted. The only way I came up was to create a partial class to my generated proxy, make it inherit from IDisposable: public partial class MyServiceProxy : IDisposable { #region IDisposable Members public void Dispose() { if (State != System.ServiceModel.CommunicationState.Faulted) Close(); else Abort(); } #endregion } I did some test and my Dispose method is indeed called. Do you see any issue with this strategy? Also, I don't like the fact that I'll have to create this partial class for every generated proxy. It be nice if I was able to make my proxy inherit from a base class...

    Read the article

  • wcf possible to override the dipose of proxy

    - by pdiddy
    I'd like to override the Dispose method of generated proxy (ClientBase) because of the fact that disposing of a proxy calls Close and can throw an exception when the channel is faulted. The only way I came up was to create a partial class to my generatedproxy, make it inherit from IDisposable. : public partial class MyServiceProxy : IDisposable { #region IDisposable Members public void Dispose() { if (State != System.ServiceModel.CommunicationState.Faulted) Close(); else Abort(); } #endregion } I did some test and my Dipose method is indeed called. Do you see any issue with this strategy? Also, I don't like the fact that I'll have to create this partial class for every generated proxy. It be nice if I was able to make my proxy inherit from a base class...

    Read the article

  • Partially Modifying an XML serialized document.

    - by Stacey
    I have an XML document, several actually, that will be editable via a front-end UI. I've discovered a problem with this approach (other than the fact that it is using xml files instead of a database... but I cannot change that right now). If one user makes a change while another user is in the process of making a change, then the second one's changes will overwrite the first. I need to be able to request objects from the xml files, change them, and then submit the changes back to the xml file without re-writing the entire file. I've got my entire xml access class posted here (which was formed thanks to wonderful help from stackoverflow!) using System; using System.Linq; using System.Collections; using System.Collections.Generic; namespace Repositories { /// <summary> /// A file base repository represents a data backing that is stored in an .xml file. /// </summary> public partial class Repository<T> : IRepository { /// <summary> /// Default constructor for a file repository /// </summary> public Repository() { } /// <summary> /// Initialize a basic repository with a filename. This will have to be passed from a context to be mapped. /// </summary> /// <param name="filename"></param> public Repository(string filename) { FileName = filename; } /// <summary> /// Discovers a single item from this repository. /// </summary> /// <typeparam name="TItem">The type of item to recover.</typeparam> /// <typeparam name="TCollection">The collection the item belongs to.</typeparam> /// <param name="expression"></param> /// <returns></returns> public TItem Single<TItem, TCollection>(Predicate<TItem> expression) where TCollection : IDisposable, IEnumerable<TItem> { using (var list = List<TCollection>()) { return list.Single(i => expression(i)); } } /// <summary> /// Discovers a collection from the repository, /// </summary> /// <typeparam name="TCollection"></typeparam> /// <returns></returns> public TCollection List<TCollection>() where TCollection : IDisposable { using (var list = System.Xml.Serializer.Deserialize<TCollection>(FileName)) { return (TCollection)list; } } /// <summary> /// Discovers a single item from this repository. /// </summary> /// <typeparam name="TItem">The type of item to recover.</typeparam> /// <typeparam name="TCollection">The collection the item belongs to.</typeparam> /// <param name="expression"></param> /// <returns></returns> public List<TItem> Select<TItem, TCollection>(Predicate<TItem> expression) where TCollection : IDisposable, IEnumerable<TItem> { using (var list = List<TCollection>()) { return list.Where( i => expression(i) ).ToList<TItem>(); } } /// <summary> /// Attempts to save an entire collection. /// </summary> /// <typeparam name="TCollection"></typeparam> /// <param name="collection"></param> /// <returns></returns> public Boolean Save<TCollection>(TCollection collection) { try { // load the collection into an xml reader and try to serialize it. System.Xml.XmlDocument xDoc = new System.Xml.XmlDocument(); xDoc.LoadXml(System.Xml.Serializer.Serialize<TCollection>(collection)); // attempt to flush the file xDoc.Save(FileName); // assume success return true; } catch { return false; } } internal string FileName { get; private set; } } public interface IRepository { TItem Single<TItem, TCollection>(Predicate<TItem> expression) where TCollection : IDisposable, IEnumerable<TItem>; TCollection List<TCollection>() where TCollection : IDisposable; List<TItem> Select<TItem, TCollection>(Predicate<TItem> expression) where TCollection : IDisposable, IEnumerable<TItem>; Boolean Save<TCollection>(TCollection collection); } }

    Read the article

  • MVVM Light V4 preview 2 (BL0015) #mvvmlight

    - by Laurent Bugnion
    Over the past few weeks, I have worked hard on a few new features for MVVM Light V4. Here is a second early preview (consider this pre-alpha if you wish). The features are unit-tested, but I am now looking for feedback and there might be bugs! Bug correction: Messenger.CleanupList is now thread safe This was an annoying bug that is now corrected: In some circumstances, an exception could be thrown when the Messenger’s recipients list was cleaned up (i.e. the “dead” instances were removed). The method is called now and then and the exception was thrown apparently at random. In fact it was really a multi-threading issue, which is now corrected. Bug correction: AllowPartiallyTrustedCallers prevents EventToCommand to work This is a particularly annoying regression bug that was introduced in BL0014. In order to allow MVVM Light to work in XBAPs too, I added the AllowPartiallyTrustedCallers attribute to the assemblies. However, we just found out that this causes issues when using EventToCommand. In order to allow EventToCommand to continue working, I reverted to the previous state by removing the AllowPartiallyTrustedCallers attribute for now. I will work with my friends at Microsoft to try and find a solution. Stay tuned. Bug correction: XML documentation file is now generated in Release configuration The XML documentation file was not generated for the Release configuration. This was a simple flag in the project file that I had forgotten to set. This is corrected now. Applying EventToCommand to non-FrameworkElements This feature has been requested in order to be able to execute a command when a Storyboard is completed. I implemented this, but unfortunately found out that EventToCommand can only be added to Storyboards in Silverlight 3 and Silverlight 4, but not in WPF or in Windows Phone 7. This obviously limits the usefulness of this change, but I decided to publish it anyway, because it is pretty damn useful in Silverlight… Why not in WPF? In WPF, Storyboards added to a resource dictionary are frozen. This is a feature of WPF which allows to optimize certain objects for performance: By freezing them, it is a contract where we say “this object will not be modified anymore, so do your perf optimization on them without worrying too much”. Unfortunately, adding a Trigger (such as EventTrigger) to an object in resources does not work if this object is frozen… and unfortunately, there is no way to tell WPF not to freeze the Storyboard in the resources… so there is no way around that (at least none I can see. In Silverlight, objects are not frozen, so an EventTrigger can be added without problems. Why not in WP7? In Windows Phone 7, there is a totally different issue: Adding a Trigger can only be done to a FrameworkElement, which Storyboard is not. Here I think that we might see a change in a future version of the framework, so maybe this small trick will work in the future. Workaround? Since you cannot use the EventToCommand on a Storyboard in WPF and in WP7, the workaround is pretty obvious: Handle the Completed event in the code behind, and call the Command from there on the ViewModel. This object can be obtained by casting the DataContext to the ViewModel type. This means that the View needs to know about the ViewModel, but I never had issues with that anyway. New class: NotifyPropertyChanged Sometimes when you implement a model object (for example Customer), you would like to have it implement INotifyPropertyChanged, but without having all the frills of a ViewModelBase. A new class named NotifyPropertyChanged allows you to do that. This class is a simple implementation of INotifyPropertyChaned (with all the overloads of RaisePropertyChanged that were implemented in BL0014). In fact, ViewModelBase inherits NotifyPropertyChanged. ViewModelBase does not implement IDisposable anymore The IDisposable interface and the Dispose method had been marked obsolete in the ViewModelBase class already in V3. Now they have been removed. Note: By this, I do not mean that IDisposable is a bad interface, or that it shouldn’t be used on viewmodels. In the contrary, I know that this interface is very useful in certain circumstances. However, I think that having it by default on every instance of ViewModelBase was sending a wrong message. This interface has a strong meaning in .NET: After Dispose has been executed, the instance should not be used anymore, and should be ready for garbage collection. What I really wanted to have on ViewModelBase was rather a simple cleanup method, something that can be executed now and then during runtime. This is fulfilled by the ICleanup interface and its Cleanup method. If your ViewModels need IDisposable, you can still use it! You will just have to implement the interface on the class itself, because it is not available on ViewModelBase anymore. What’s next? I have a couple exciting new features implemented already but that need more testing before they go live… Just stay tuned and by MIX11 (12-14 April 2011), we should see at least a major addition to MVVM Light Toolkit, as well as another smaller feature which is pretty cool nonetheless More about this later! Happy Coding Laurent   Laurent Bugnion (GalaSoft) Subscribe | Twitter | Facebook | Flickr | LinkedIn

    Read the article

  • What&rsquo;s new in MVVM Light V3

    - by Laurent Bugnion
    V3 of the MVVM Light Toolkit was released during MIX10, after quite a long alpha stage. This post lists the new features in MVVM Light V3. Compatibility MVVM Light Toolkit V3 can be installed for the following tools and framework versions: Visual Studio 2008 SP1, Expression Blend 3 Windows Presentation Foundation 3.5 SP1 Silverlight 3 Visual Studio 2010 RC, Expression Blend 4 beta Windows Presentation Foundation 3.5 SP1 Windows Presentation Foundation 4 RC Silverlight 3 Silverlight 4 RC For more information about installing the MVVM Light Toolkit V3, please visit this page. For cleaning up existing installation, see this page. New in V3 RTM The following features have been added after V3 alpha3: Project template for the Windows Phone 7 series (Silverlight) This new template allows you to create a new MVVM Light application in Visual Studio 2010 RC and to run it in the Windows Phone 7 series emulator. This template uses the Silverlight 3 version of the MVVM Light Toolkit V3. At this time, only the essentials features of the GalaSoft.MvvmLight.dll assembly are supported on the phone. New in V3 alpha3 The following features have been added after V3 alpha2: New logo An awesome logo has been designed for MVVM Light by Philippe Schutz. DispatcherHelper class (in GalaSoft.MvvmLight.Extras.dll) This class is useful when you work on multi-threaded WPF or Silverlight applications. Initializing: The DispatcherHelper class must be initialized in the UI thread. For example, you can initialize the class in a Silverlight application’s Application_Startup event handler, or in the WPF application’s static App constructor (in App.xaml). // Initializing in Silverlight (in App.xaml) private void Application_Startup( object sender, StartupEventArgs e) { RootVisual = new MainPage(); DispatcherHelper.Initialize(); } // Initializing in WPF (in App.xaml) static App() { DispatcherHelper.Initialize(); } Verifying if a property exists The ViewModelBase.RaisePropertyChanged method now checks if a given property name exists on the ViewModel class, and throws an exception if that property cannot be found. This is useful to detect typos in a property name, for example during a refactoring. Note that the check is only done in DEBUG mode. Replacing IDisposable with ICleanup The IDisposable implementation in the ViewModelBase class has been marked obsolete. Instead, the ICleanup interface (and its Cleanup method) has been added. Implementing IDisposable in a ViewModel is still possible, but must be done explicitly. IDisposable in ViewModelBase was a bad practice, because it supposes that the ViewModel is garbage collected after Dispose is called. instead, the Cleanup method does not have such expectation. The ViewModelLocator class (created when an MVVM Light project template is used in Visual Studio or Expression Blend) exposes a static Cleanup method, which should in turn call each ViewModel’s Cleanup method. The ViewModel is free to override the Cleanup method if local cleanup must be performed. Passing EventArgs to command with EventToCommand The EventToCommand class is used to bind any event to an ICommand (typically on the ViewModel). In this case, it can be useful to pass the event’s EventArgs parameter to the command in the ViewModel. For example, for the MouseEnter event, you can pass the MouseEventArgs to a RelayCommand<MouseEventArgs> as shown in the next listings. Note: Bringing UI specific classes (such as EventArgs) into the ViewModel reduces the testability of the ViewModel, and thus should be used with care. Setting EventToCommand and PassEventArgsToCommand: <Grid x:Name="LayoutRoot"> <i:Interaction.Triggers> <i:EventTrigger EventName="MouseEnter"> <cmd:EventToCommand Command="{Binding MyCommand}" PassEventArgsToCommand="True" /> </i:EventTrigger> </i:Interaction.Triggers> </Grid> Getting the EventArgs in the command public RelayCommand<MouseEventArgs> MyCommand { get; private set; } public MainViewModel() { MyCommand = new RelayCommand<MouseEventArgs>(e => { // e is of type MouseEventArgs }); } Changes to templates Various changes have been made to project templates and item templates to make them more compatible with Silverlight 4 and to improve their visibility in Visual Studio and Expression Blend. Bug corrections When a message is sent through the Messenger class using the method Messenger.Default.Send<T>(T message, object token), and the token is a simple value (for example int), the message was not sent correctly. This bug is now corrected. New in V3 The following features have been added after V2. Sending messages with callback Certain classes have been added to the GalaSoft.MvvmLight.Messaging namespace, allowing sending a message and getting a callback from the recipient. These classes are: NotificationMessageWithCallback: Base class for messages with callback. NotificationMessageAction: A class with string notification, and a parameterless callback. NotificationMessageAction<T>: A class with string notification, and a callback with a parameter of type T. To send a message with callback, use the following code: var message = new NotificationMessageAction<bool>( "Hello world", callbackMessage => { // This is the callback code if (callbackMessage) { // ... } }); Messenger.Default.Send(message); To register and receive a message with callback, use the following code: Messenger.Default.Register<NotificationMessageAction<bool>>( this, message => { // Do something // Execute the callback message.Execute(true); }); Messenger.Default can be overriden The Messenger.Default property can also be replaced, for example for unit testing purposes, by using the Messenger.OverrideDefault method. All the public methods of the Messenger class have been made virtual, and can be overridden in the test messenger class. Sending messages to interfaces In V2, it was possible to deliver messages targeted to instances of a given class. in V3 it is still possible, but in addition you can deliver a message to instances that implement a certain interface. The message will not be delivered to other recipients. Use the overload Messenger.Default.Send<TMessage, TTarget>(TMessage message) where TTarget is, in fact, an interface (for example IDisposable). Of course the recipient must register to receive the type of message TMessage. Sending messages with a token Messages can now be sent through the Messenger with a token. To send a message with token, use the method overload Send<TMessage>(TMessage message, object token). To receive a message with token, use the methods Register<TMessage>(object recipient, object token, Action<TMessage> action) or Register<TMessage>(object recipient, object token, bool receiveDerivedMessagesToo, Action<TMessage> action) The token can be a simple value (int, string, etc…) or an instance of a class. The message is not delivered to recipients who registered with a different token, or with no token at all. Renaming CommandMessage to NotificationMessage To avoid confusion with ICommand and RelayCommand, the CommandMessage class has been renamed to NotificationMessage. This message class can be used to deliver a notification (of type string) to a recipient. ViewModelBase constructor with IMessenger The ViewModelBase class now accepts an IMessenger parameter. If this constructor is used instead of the default empty constructor, the IMessenger passed as parameter will be used to broadcast a PropertyChangedMessage when the method RaisePropertyChanged<T>(string propertyName, T oldValue, T newValue, bool broadcast) is used. In the default ViewModelBase constructor is used, the Messenger.Default instance will be used instead. EventToCommand behavior The EventToCommand behavior has been added in V3. It can be used to bind any event of any FrameworkElement to any ICommand (for example a RelayCommand located in the ViewModel). More information about the EventToCommand behavior can be found here and here. Updated the project templates to remove the sample application The project template has been updated to remove the sample application that was created every time that a new MVVM Light application was created in Visual Studio or Blend. This makes the creation of a new application easier, because you don’t need to remove code before you can start writing code. Bug corrections Some bugs that were in Version 2 have been corrected: In some occasions, an exception could be thrown when a recipient was registered for a message at the same time as a message was received. New names for DLLs If you upgrade an existing installation, you will need to change the reference to the DLLs in C:\Program Files\Laurent Bugnion (GalaSoft)\Mvvm Light Toolkit\Binaries. The assemblies have been moved, and the versions for Silverlight 4 and for WPF4 have been renamed, to avoid some confusion. It is now easier to make sure that you are using the correct DLL. WPF3.5SP1, Silverlight 3 When using the DLLs, make sure that you use the correct versions. WPF4, Silverlight 4 When using the DLLs, make sure that you use the correct versions.   Laurent Bugnion (GalaSoft) Subscribe | Twitter | Facebook | Flickr | LinkedIn

    Read the article

  • Weak References and Disposable objects.

    - by Steve Sheldon
    In C# it is possible to create weak references to objects as described here: WeakReference Class In .net some classes also implement the IDisposable interface. Calling the Dispose method of this interface is performed to manually dispose of any managed or unmanaged resources currently being held onto. An example might be a Bitmap object or class. If I assign an object that implements IDisposable to a weak reference, will Dispose be called if the weak reference collects the object?

    Read the article

  • C# Finalize/Dispose pattern

    - by robUK
    Hello, C# 2008 I have been working on this for a while now. And I am still confused about some issues. My questions below 1) I know that you only need a finalizer if you are disposing of unmanaged resources. However, if you are using managed resources that make calls to unmanaged resources. Would you still need to implement a finalizer? 2) However, if you develop a class that doesn't use any unmanged resources directly or indirectly and you implement the IDisposable so that clients of your class can use the 'using statement'. Would it be acceptable to implement the IDisposable just so that clients of your class can use the using statement? using(myClass objClass = new myClass()) { // Do stuff here } 3) I have developed this simple code below to demostrate the Finalize/dispose pattern: public class NoGateway : IDisposable { private WebClient wc = null; public NoGateway() { wc = new WebClient(); wc.DownloadStringCompleted += wc_DownloadStringCompleted; } // Start the Async call to find if NoGateway is true or false public void NoGatewayStatus() { // Start the Async's download // Do other work here wc.DownloadStringAsync(new Uri(www.xxxx.xxx)); } private void wc_DownloadStringCompleted(object sender, DownloadStringCompletedEventArgs e) { // Do work here } // Dispose of the NoGateway object public void Dispose() { wc.DownloadStringCompleted -= wc_DownloadStringCompleted; wc.Dispose(); GC.SuppressFinalize(this); } } Question about the source code: 1) Here I have not added the finalizer. And normally the finalizer will be called by the GC, and the finalizer will call the Dispose. As I don't have the finalizer, when do I call the Dispose method? Is it the client of the class that has to call it? So my class in the example is called NoGateway and the client could use and dispose of the class like this: Would the Dispose method be automatically called when execution reaches the end of the using block? using(NoGateway objNoGateway = new NoGateway()) { // Do stuff here } Or does the client have to manually call the dispose method i.e.? NoGateway objNoGateway = new NoGateway(); // Do stuff with object objNoGateway.Dispose(); // finished with it Many thanks for helping with all these questions, 2) I am using the webclient class in my 'NoGateway' class. Because the webclient implements the IDisposable interface. Does this mean that the webclient indirectly uses unmanaged resources? Is there any hard and fast rule to follow about this. How do I know that a class uses unmanaged resources?

    Read the article

  • Visual Studio code generated when choosing to explicitly implement interface

    - by fearofawhackplanet
    Sorry for the vague title, but I'm not sure what this is called. Say I add IDisposable to my class, Visual Studio can create the method stub for me. But it creates the stub like: void IDisposable.Dispose() I don't follow what this syntax is doing. Why do it like this instead of public void Dispose()? And with the first syntax, I couldn't work out how to call Dispose() from within my class (in my destructor).

    Read the article

  • Why should we call SuppressFinalize when we dont have a destructor

    - by somaraj
    I have few Question for which I am not able to get a proper answer . 1) Why should we call SuppressFinalize in the Dispose function when we dont have a destructor . 2) Dispose and finalize are used for freeing resources before the object is garbage collected. Whether it is managed or unmanaged resource we need to free it , then why we need a condition inside the dispose funtion , saying pass 'true' when we call this overriden function from IDisposable:Dispose and pass false when called from a finalize. See the below code i copied from net. class Test : IDisposable { private bool isDisposed = false; ~Test() { Dispose(false); } protected void Dispose(bool disposing) { if (disposing) { // Code to dispose the managed resources of the class } // Code to dispose the un-managed resources of the class isDisposed = true; } public void Dispose() { Dispose(true); GC.SuppressFinalize(this); } } what if I remove the boolean protected Dispose function and implement the as below. class Test : IDisposable { private bool isDisposed = false; ~Test() { Dispose(); } public void Dispose() { // Code to dispose the managed resources of the class // Code to dispose the un-managed resources of the class isDisposed = true; // Call this since we have a destructor . what if , if we dont have one GC.SuppressFinalize(this); } }

    Read the article

  • Using Dispose on a Singleton to Cleanup Resources

    - by ImperialLion
    The question I have might be more to do with semantics than with the actual use of IDisposable. I am working on implementing a singleton class that is in charge of managing a database instance that is created during the execution of the application. When the application closes this database should be deleted. Right now I have this delete being handled by a Cleanup() method of the singleton that the application calls when it is closing. As I was writing the documentation for Cleanup() it struck me that I was describing what a Dispose() method should be used for i.e. cleaning up resources. I had originally not implemented IDisposable because it seemed out of place in my singleton, because I didn't want anything to dispose the singleton itself. There isn't currently, but in the future might be a reason that this Cleanup() might be called but the singleton should will need to still exist. I think I can include GC.SuppressFinalize(this); in the Dispose method to make this feasible. My question therefore is multi-parted: 1) Is implementing IDisposable on a singleton fundamentally a bad idea? 2) Am I just mixing semantics here by having a Cleanup() instead of a Dispose() and since I'm disposing resources I really should use a dispose? 3) Will implementing 'Dispose()' with GC.SuppressFinalize(this); make it so my singleton is not actually destroyed in the case I want it to live after a call to clean-up the database.

    Read the article

  • Did the developers of Java conciously abandon RAII?

    - by JoelFan
    As a long-time C# programmer, I have recently come to learn more about the advantages of Resource Acquisition Is Initialization (RAII). In particular, I have discovered that the C# idiom: using (my dbConn = new DbConnection(connStr) { // do stuff with dbConn } has the C++ equivalent: { DbConnection dbConn(connStr); // do stuff with dbConn } meaning that remembering to enclose the use of resources like DbConnection in a using block is unnecessary in C++ ! This seems to a major advantage of C++. This is even more convincing when you consider a class that has an instance member of type DbConnection, for example class Foo { DbConnection dbConn; // ... } In C# I would need to have Foo implement IDisposable as such: class Foo : IDisposable { DbConnection dbConn; public void Dispose() { dbConn.Dispose(); } } and what's worse, every user of Foo would need to remember to enclose Foo in a using block, like: using (var foo = new Foo()) { // do stuff with "foo" } Now looking at C# and its Java roots I am wondering... did the developers of Java fully appreciate what they were giving up when they abandoned the stack in favor of the heap, thus abandoning RAII? (Similarly, did Stroustrup fully appreciate the significance of RAII?)

    Read the article

  • Where should I create my DbCommand instances?

    - by Domenic
    I seemingly have two choices: Make my class implement IDisposable. Create my DbCommand instances as private readonly fields, and in the constructor, add the parameters that they use. Whenever I want to write to the database, bind to these parameters (reusing the same command instances), set the Connection and Transaction properties, then call ExecuteNonQuery. In the Dispose method, call Dispose on each of these fields. Each time I want to write to the database, write using(var cmd = new DbCommand("...", connection, transaction)) around the usage of the command, and add parameters and bind to them every time as well, before calling ExecuteNonQuery. I assume I don't need a new command for each query, just a new command for each time I open the database (right?). Both of these seem somewhat inelegant and possibly incorrect. For #1, it is annoying for my users that I this class is now IDisposable just because I have used a few DbCommands (which should be an implementation detail that they don't care about). I also am somewhat suspicious that keeping a DbCommand instance around might inadvertently lock the database or something? For #2, it feels like I'm doing a lot of work (in terms of .NET objects) each time I want to write to the database, especially with the parameter-adding. It seems like I create the same object every time, which just feels like bad practice. For reference, here is my current code, using #1: using System; using System.Net; using System.Data.SQLite; public class Class1 : IDisposable { private readonly SQLiteCommand updateCookie = new SQLiteCommand("UPDATE moz_cookies SET value = @value, expiry = @expiry, isSecure = @isSecure, isHttpOnly = @isHttpOnly WHERE name = @name AND host = @host AND path = @path"); public Class1() { this.updateCookie.Parameters.AddRange(new[] { new SQLiteParameter("@name"), new SQLiteParameter("@value"), new SQLiteParameter("@host"), new SQLiteParameter("@path"), new SQLiteParameter("@expiry"), new SQLiteParameter("@isSecure"), new SQLiteParameter("@isHttpOnly") }); } private static void BindDbCommandToMozillaCookie(DbCommand command, Cookie cookie) { long expiresSeconds = (long)cookie.Expires.TotalSeconds; command.Parameters["@name"].Value = cookie.Name; command.Parameters["@value"].Value = cookie.Value; command.Parameters["@host"].Value = cookie.Domain; command.Parameters["@path"].Value = cookie.Path; command.Parameters["@expiry"].Value = expiresSeconds; command.Parameters["@isSecure"].Value = cookie.Secure; command.Parameters["@isHttpOnly"].Value = cookie.HttpOnly; } public void WriteCurrentCookiesToMozillaBasedBrowserSqlite(string databaseFilename) { using (SQLiteConnection connection = new SQLiteConnection("Data Source=" + databaseFilename)) { connection.Open(); using (SQLiteTransaction transaction = connection.BeginTransaction()) { this.updateCookie.Connection = connection; this.updateCookie.Transaction = transaction; foreach (Cookie cookie in SomeOtherClass.GetCookieArray()) { Class1.BindDbCommandToMozillaCookie(this.updateCookie, cookie); this.updateCookie.ExecuteNonQuery(); } transaction.Commit(); } } } #region IDisposable implementation protected virtual void Dispose(bool disposing) { if (!this.disposed && disposing) { this.updateCookie.Dispose(); } this.disposed = true; } public void Dispose() { this.Dispose(true); GC.SuppressFinalize(this); } ~Class1() { this.Dispose(false); } private bool disposed; #endregion }

    Read the article

  • "Programming error" exceptions - Is my approach sound?

    - by Medo42
    I am currently trying to improve my use of exceptions, and found the important distinction between exceptions that signify programming errors (e.g. someone passed null as argument, or called a method on an object after it was disposed) and those that signify a failure in the operation that is not the caller's fault (e.g. an I/O exception). As far as I understand, it makes little sense for an immediate caller to actually handle programming error exceptions, he should instead assure that the preconditions are met. Only "outer" exception handlers at task boundaries should catch them, so they can keep the system running if a task fails. In order to ensure that client code can cleanly catch "failure" exceptions without catching error exceptions by mistake, I create my own exception classes for all failure exceptions now, and document them in the methods that throw them. I would make them checked exceptions in Java. Now I have a few questions: Before, I tried to document all exceptions that a method could throw, but that sometimes creates an unwiedly list that needs to be documented in every method up the call chain until you can show that the error won't happen. Instead, I document the preconditions in the summary / parameter descriptions and don't even mention what happens if they are not met. The idea is that people should not try to catch these exceptions explicitly anyway, so there is no need to document their types. Would you agree that this is enough? Going further, do you think all preconditions even need to be documented for every method? For example, calling methods in IDisposable objects after calling Dispose is an error, but since IDisposable is such a widely used interface, can I just assume a programmer will know this? A similar case is with reference type parameters where passing null makes no conceivable sense: Should I document "non-null" anyway? IMO, documentation should only cover things that are not obvious, but I am not sure where "obvious" ends.

    Read the article

  • Using the Static Code Analysis feature of Visual Studio (Premium/Ultimate) to find memory leakage problems

    - by terje
    Memory for managed code is handled by the garbage collector, but if you use any kind of unmanaged code, like native resources of any kind, open files, streams and window handles, your application may leak memory if these are not properly handled.  To handle such resources the classes that own these in your application should implement the IDisposable interface, and preferably implement it according to the pattern described for that interface. When you suspect a memory leak, the immediate impulse would be to start up a memory profiler and start digging into that.   However, before you follow that impulse, do a Static Code Analysis run with a ruleset tuned to finding possible memory leaks in your code.  If you get any warnings from this, fix them before you go on with the profiling. How to use a ruleset In Visual Studio 2010 (Premium and Ultimate editions) you can define your own rulesets containing a list of Static Code Analysis checks.   I have defined the memory checks as shown in the lists below as ruleset files, which can be downloaded – see bottom of this post.  When you get them, you can easily attach them to every project in your solution using the Solution Properties dialog. Right click the solution, and choose Properties at the bottom, or use the Analyze menu and choose “Configure Code Analysis for Solution”: In this dialog you can now choose the Memorycheck ruleset for every project you want to investigate.  Pressing Apply or Ok opens every project file and changes the projects code analysis ruleset to the one we have specified here. How to define your own ruleset  (skip this if you just download my predefined rulesets) If you want to define the ruleset yourself, open the properties on any project, choose Code Analysis tab near the bottom, choose any ruleset in the drop box and press Open Clear out all the rules by selecting “Source Rule Sets” in the Group By box, and unselect the box Change the Group By box to ID, and select the checks you want to include from the lists below. Note that you can change the action for each check to either warning, error or none, none being the same as unchecking the check.   Now go to the properties window and set a new name and description for your ruleset. Then save (File/Save as) the ruleset using the new name as its name, and use it for your projects as detailed above. It can also be wise to add the ruleset to your solution as a solution item. That way it’s there if you want to enable Code Analysis in some of your TFS builds.   Running the code analysis In Visual Studio 2010 you can either do your code analysis project by project using the context menu in the solution explorer and choose “Run Code Analysis”, you can define a new solution configuration, call it for example Debug (Code Analysis), in for each project here enable the Enable Code Analysis on Build   In Visual Studio Dev-11 it is all much simpler, just go to the Solution root in the Solution explorer, right click and choose “Run code analysis on solution”.     The ruleset checks The following list is the essential and critical memory checks.  CheckID Message Can be ignored ? Link to description with fix suggestions CA1001 Types that own disposable fields should be disposable No  http://msdn.microsoft.com/en-us/library/ms182172.aspx CA1049 Types that own native resources should be disposable Only if the pointers assumed to point to unmanaged resources point to something else  http://msdn.microsoft.com/en-us/library/ms182173.aspx CA1063 Implement IDisposable correctly No  http://msdn.microsoft.com/en-us/library/ms244737.aspx CA2000 Dispose objects before losing scope No  http://msdn.microsoft.com/en-us/library/ms182289.aspx CA2115 1 Call GC.KeepAlive when using native resources See description  http://msdn.microsoft.com/en-us/library/ms182300.aspx CA2213 Disposable fields should be disposed If you are not responsible for release, of if Dispose occurs at deeper level  http://msdn.microsoft.com/en-us/library/ms182328.aspx CA2215 Dispose methods should call base class dispose Only if call to base happens at deeper calling level  http://msdn.microsoft.com/en-us/library/ms182330.aspx CA2216 Disposable types should declare a finalizer Only if type does not implement IDisposable for the purpose of releasing unmanaged resources  http://msdn.microsoft.com/en-us/library/ms182329.aspx CA2220 Finalizers should call base class finalizers No  http://msdn.microsoft.com/en-us/library/ms182341.aspx Notes: 1) Does not result in memory leak, but may cause the application to crash   The list below is a set of optional checks that may be enabled for your ruleset, because the issues these points too often happen as a result of attempting to fix up the warnings from the first set.   ID Message Type of fault Can be ignored ? Link to description with fix suggestions CA1060 Move P/invokes to NativeMethods class Security No http://msdn.microsoft.com/en-us/library/ms182161.aspx CA1816 Call GC.SuppressFinalize correctly Performance Sometimes, see description http://msdn.microsoft.com/en-us/library/ms182269.aspx CA1821 Remove empty finalizers Performance No http://msdn.microsoft.com/en-us/library/bb264476.aspx CA2004 Remove calls to GC.KeepAlive Performance and maintainability Only if not technically correct to convert to SafeHandle http://msdn.microsoft.com/en-us/library/ms182293.aspx CA2006 Use SafeHandle to encapsulate native resources Security No http://msdn.microsoft.com/en-us/library/ms182294.aspx CA2202 Do not dispose of objects multiple times Exception (System.ObjectDisposedException) No http://msdn.microsoft.com/en-us/library/ms182334.aspx CA2205 Use managed equivalents of Win32 API Maintainability and complexity Only if the replace doesn’t provide needed functionality http://msdn.microsoft.com/en-us/library/ms182365.aspx CA2221 Finalizers should be protected Incorrect implementation, only possible in MSIL coding No http://msdn.microsoft.com/en-us/library/ms182340.aspx   Downloadable ruleset definitions I have defined three rulesets, one called Inmeta.Memorycheck with the rules in the first list above, and Inmeta.Memorycheck.Optionals containing the rules in the second list, and the last one called Inmeta.Memorycheck.All containing the sum of the two first ones.  All three rulesets can be found in the  zip archive  “Inmeta.Memorycheck” downloadable from here.   Links to some other resources relevant to Static Code Analysis MSDN Magazine Article by Mickey Gousset on Static Code Analysis in VS2010 MSDN :  Analyzing Managed Code Quality by Using Code Analysis, root of the documentation for this Preventing generated code from being analyzed using attributes Online training course on Using Code Analysis with VS2010 Blogpost by Tatham Oddie on custom code analysis rules How to write custom rules, from Microsoft Code Analysis Team Blog Microsoft Code Analysis Team Blog

    Read the article

  • Building a Repository Pattern against an EF 5 EDMX Model - Part 1

    - by Juan
    I am part of a year long plus project that is re-writing an existing application for a client.  We have decided to develop the project using Visual Studio 2012 and .NET 4.5.  The project will be using a number of technologies and patterns to include Entity Framework 5, WCF Services, and WPF for the client UI.This is my attempt at documenting some of the successes and failures that I will be coming across in the development of the application.In building the data access layer we have to access a database that has already been designed by a dedicated dba. The dba insists on using Stored Procedures which has made the use of EF a little more difficult.  He will not allow direct table access but we did manage to get him to allow us to use Views.  Since EF 5 does not have good support to do Code First with Stored Procedures, my option was to create a model (EDMX) against the existing database views.   I then had to go select each entity and map the Insert/Update/Delete functions to their respective stored procedure. The next step after I had completed mapping the stored procedures to the entities in the EDMX model was to figure out how to build a generic repository that would work well with Entity Framework 5.  After reading the blog posts below, I adopted much of their code with some changes to allow for the use of Ninject for dependency injection.http://www.tcscblog.com/2012/06/22/entity-framework-generic-repository/ http://www.tugberkugurlu.com/archive/generic-repository-pattern-entity-framework-asp-net-mvc-and-unit-testing-triangle IRepository.cs public interface IRepository : IDisposable where T : class { void Add(T entity); void Update(T entity, int id); T GetById(object key); IQueryable Query(Expression> predicate); IQueryable GetAll(); int SaveChanges(); int SaveChanges(bool validateEntities); } GenericRepository.cs public abstract class GenericRepository : IRepository where T : class { public abstract void Add(T entity); public abstract void Update(T entity, int id); public abstract T GetById(object key); public abstract IQueryable Query(Expression> predicate); public abstract IQueryable GetAll(); public int SaveChanges() { return SaveChanges(true); } public abstract int SaveChanges(bool validateEntities); public abstract void Dispose(); } One of the issues I ran into was trying to do an update. I kept receiving errors so I posted a question on Stack Overflow http://stackoverflow.com/questions/12585664/an-object-with-the-same-key-already-exists-in-the-objectstatemanager-the-object and came up with the following hack. If someone has a better way, please let me know. DbContextRepository.cs public class DbContextRepository : GenericRepository where T : class { protected DbContext Context; protected DbSet DbSet; public DbContextRepository(DbContext context) { if (context == null) throw new ArgumentException("context"); Context = context; DbSet = Context.Set(); } public override void Add(T entity) { if (entity == null) throw new ArgumentException("Cannot add a null entity."); DbSet.Add(entity); } public override void Update(T entity, int id) { if (entity == null) throw new ArgumentException("Cannot update a null entity."); var entry = Context.Entry(entity); if (entry.State == EntityState.Detached) { var attachedEntity = DbSet.Find(id); // Need to have access to key if (attachedEntity != null) { var attachedEntry = Context.Entry(attachedEntity); attachedEntry.CurrentValues.SetValues(entity); } else { entry.State = EntityState.Modified; // This should attach entity } } } public override T GetById(object key) { return DbSet.Find(key); } public override IQueryable Query(Expression> predicate) { return DbSet.Where(predicate); } public override IQueryable GetAll() { return Context.Set(); } public override int SaveChanges(bool validateEntities) { Context.Configuration.ValidateOnSaveEnabled = validateEntities; return Context.SaveChanges(); } #region IDisposable implementation public override void Dispose() { if (Context != null) { Context.Dispose(); GC.SuppressFinalize(this); } } #endregion IDisposable implementation } At this point I am able to start creating individual repositories that are needed and add a Unit of Work.  Stay tuned for the next installment in my path to creating a Repository Pattern against EF5.

    Read the article

  • Curious about IObservable? Here’s a quick example to get you started!

    - by Roman Schindlauer
    Have you heard about IObservable/IObserver support in Microsoft StreamInsight 1.1? Then you probably want to try it out. If this is your first incursion into the IObservable/IObserver pattern, this blog post is for you! StreamInsight 1.1 introduced the ability to use IEnumerable and IObservable objects as event sources and sinks. The IEnumerable case is pretty straightforward, since many data collections are already surfacing as this type. This was already covered by Colin in his blog. Creating your own IObservable event source is a little more involved but no less exciting – here is a primer: First, let’s look at a very simple Observable data source. All it does is publish an integer in regular time periods to its registered observers. (For more information on IObservable, see http://msdn.microsoft.com/en-us/library/dd990377.aspx ). sealed class RandomSubject : IObservable<int>, IDisposable {     private bool _done;     private readonly List<IObserver<int>> _observers;     private readonly Random _random;     private readonly object _sync;     private readonly Timer _timer;     private readonly int _timerPeriod;       /// <summary>     /// Random observable subject. It produces an integer in regular time periods.     /// </summary>     /// <param name="timerPeriod">Timer period (in milliseconds)</param>     public RandomSubject(int timerPeriod)     {         _done = false;         _observers = new List<IObserver<int>>();         _random = new Random();         _sync = new object();         _timer = new Timer(EmitRandomValue);         _timerPeriod = timerPeriod;         Schedule();     }       public IDisposable Subscribe(IObserver<int> observer)     {         lock (_sync)         {             _observers.Add(observer);         }         return new Subscription(this, observer);     }       public void OnNext(int value)     {         lock (_sync)         {             if (!_done)             {                 foreach (var observer in _observers)                 {                     observer.OnNext(value);                 }             }         }     }       public void OnError(Exception e)     {         lock (_sync)         {             foreach (var observer in _observers)             {                 observer.OnError(e);             }             _done = true;         }     }       public void OnCompleted()     {         lock (_sync)         {             foreach (var observer in _observers)             {                 observer.OnCompleted();             }             _done = true;         }     }       void IDisposable.Dispose()     {         _timer.Dispose();     }       private void Schedule()     {         lock (_sync)         {             if (!_done)             {                 _timer.Change(_timerPeriod, Timeout.Infinite);             }         }     }       private void EmitRandomValue(object _)     {         var value = (int)(_random.NextDouble() * 100);         Console.WriteLine("[Observable]\t" + value);         OnNext(value);         Schedule();     }       private sealed class Subscription : IDisposable     {         private readonly RandomSubject _subject;         private IObserver<int> _observer;           public Subscription(RandomSubject subject, IObserver<int> observer)         {             _subject = subject;             _observer = observer;         }           public void Dispose()         {             IObserver<int> observer = _observer;             if (null != observer)             {                 lock (_subject._sync)                 {                     _subject._observers.Remove(observer);                 }                 _observer = null;             }         }     } }   So far, so good. Now let’s write a program that consumes data emitted by the observable as a stream of point events in a Streaminsight query. First, let’s define our payload type: class Payload {     public int Value { get; set; }       public override string ToString()     {         return "[StreamInsight]\tValue: " + Value.ToString();     } }   Now, let’s write the program. First, we will instantiate the observable subject. Then we’ll use the ToPointStream() method to consume it as a stream. We can now write any query over the source - here, a simple pass-through query. class Program {     static void Main(string[] args)     {         Console.WriteLine("Starting observable source...");         using (var source = new RandomSubject(500))         {             Console.WriteLine("Started observable source.");             using (var server = Server.Create("Default"))             {                 var application = server.CreateApplication("My Application");                   var stream = source.ToPointStream(application,                     e => PointEvent.CreateInsert(DateTime.Now, new Payload { Value = e }),                     AdvanceTimeSettings.StrictlyIncreasingStartTime,                     "Observable Stream");                   var query = from e in stream                             select e;                   [...]   We’re done with consuming input and querying it! But you probably want to see the output of the query. Did you know you can turn a query into an observable subject as well? Let’s do precisely that, and exploit the Reactive Extensions for .NET (http://msdn.microsoft.com/en-us/devlabs/ee794896.aspx) to quickly visualize the output. Notice we’re subscribing “Console.WriteLine()” to the query, a pattern you may find useful for quick debugging of your queries. Reminder: you’ll need to install the Reactive Extensions for .NET (Rx for .NET Framework 4.0), and reference System.CoreEx and System.Reactive in your project.                 [...]                   Console.ReadLine();                 Console.WriteLine("Starting query...");                 using (query.ToObservable().Subscribe(Console.WriteLine))                 {                     Console.WriteLine("Started query.");                     Console.ReadLine();                     Console.WriteLine("Stopping query...");                 }                 Console.WriteLine("Stopped query.");             }             Console.ReadLine();             Console.WriteLine("Stopping observable source...");             source.OnCompleted();         }         Console.WriteLine("Stopped observable source.");     } }   We hope this blog post gets you started. And for bonus points, you can go ahead and rewrite the observable source (the RandomSubject class) using the Reactive Extensions for .NET! The entire sample project is attached to this article. Happy querying! Regards, The StreamInsight Team

    Read the article

  • trouble configuring WCF to use session

    - by Michael
    I am having trouble in configuring WCF service to run in session mode. As a test I wrote this simple service : [ServiceContract] public interface IService1 { [OperationContract] string AddData(int value); } [ServiceBehavior(InstanceContextMode=InstanceContextMode.PerSession)] internal class Service1 : IService1,IDisposable { private int acc; public Service1() { acc = 0; } public string AddData(int value) { acc += value; return string.Format("Accumulator value: {0}", acc); } #region IDisposable Members public void Dispose() { } #endregion } I am using Net.TCP binding with default configuration with reliable session flag enabled. As far as I understand , such service should run with no problems in session mode. But , the service runs as in per call mode - each time I call AddData , constructor gets called before executing AddData and Dispose() is called after the call. Any ideas why this might be happening?

    Read the article

  • What is the best workaround for the WCF client `using` block issue?

    - by Eric King
    I like instantiating my WCF service clients within a using block as it's pretty much the standard way to use resources that implement IDisposable: using (var client = new SomeWCFServiceClient()) { //Do something with the client } But, as noted in this MSDN article, wrapping a WCF client in a using block could mask any errors that 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. The suggested workaround in the MSDN article is to completely avoid using a using block, and to instead instantiate your clients and use them something like this: try { ... client.Close(); } catch (CommunicationException e) { ... client.Abort(); } catch (TimeoutException e) { ... client.Abort(); } catch (Exception e) { ... client.Abort(); throw; } Compared to the using block, I think that's ugly. And a lot of code to write each time you need a client. Luckily, I found a few other workarounds, such as this one on IServiceOriented. You start with: public delegate void UseServiceDelegate<T>(T proxy); public static class Service<T> { public static ChannelFactory<T> _channelFactory = new ChannelFactory<T>(""); public static void Use(UseServiceDelegate<T> codeBlock) { IClientChannel proxy = (IClientChannel)_channelFactory.CreateChannel(); bool success = false; try { codeBlock((T)proxy); proxy.Close(); success = true; } finally { if (!success) { proxy.Abort(); } } } } Which then allows: Service<IOrderService>.Use(orderService => { orderService.PlaceOrder(request); } That's not bad, but I don't think it's as expressive and easily understandable as the using block. The workaround I'm currently trying to use I first read about on blog.davidbarret.net. Basically you override the client's Dispose() method wherever you use it. Something like: public partial class SomeWCFServiceClient : IDisposable { void IDisposable.Dispose() { if (this.State == CommunicationState.Faulted) { this.Abort(); } else { this.Close(); } } } This appears to be able to allow the using block again without the danger of masking a faulted state exception. So, are there any other gotchas I have to look out for using these workarounds? Has anybody come up with anything better?

    Read the article

  • Is this a correct way to host a WCF service?

    - by mafutrct
    For some testing code, I'd like to be able to host a WCF service in only a few lines. I figured I'd write a simple hosting class: public class WcfHost : IDisposable where Implementation : class where Contract : class { public readonly string Address = "net.tcp://localhost:8000/"; private ServiceHost _Host; public WcfHost () { _Host = new ServiceHost (typeof (Implementation)); var binding = new NetTcpBinding (); var address = new Uri (Address); _Host.AddServiceEndpoint ( typeof (Contract), binding, address); _Host.Open (); } public void Dispose () { ((IDisposable) _Host).Dispose (); } } That can be used like this: using (var host = new WcfHost<ImplementationClass, ContractClass> ()) { Is there anything wrong with this approach? Is there a flaw in the code (esp. about the disposing)?

    Read the article

  • DI with disposable objects

    - by sunnychaganty
    Suppose my repository class looks like this: class myRepository : IDisposable{ private DataContext _context; public myRepository(DataContext context){ _context = context; } public void Dispose(){ // to do: implement dispose of DataContext } } now, I am using Unity to control the lifetime of my repository & the data context & configured the lifetimes as: DataContext - singleton myRepository - create a new instance each time Does this mean that I should not be implementing the IDisposable on the repository to clean up the DataContext? Any guidance on such items?

    Read the article

  • Do not use “using” in WCF Client

    - by oazabir
    You know that any IDisposable object must be disposed using using. So, you have been using using to wrap WCF service’s ChannelFactory and Clients like this: using(var client = new SomeClient()) {. ..} Or, if you are doing it the hard and slow way (without really knowing why), then: using(var factory = new ChannelFactory<ISomeService>()) {var channel= factory.CreateChannel();...} That’s what we have all learnt in school right? We have learnt it wrong! When there’s a network related error or the connection is broken, or the call is timed out before Dispose is called by the using keyword, then it results in the following exception when the using keyword tries to dispose the channel: failed: System.ServiceModel.CommunicationObjectFaultedException : The communication object, System.ServiceModel.Channels.ServiceChannel, cannot be used for communication because it is in the Faulted state. Server stack trace: at System.ServiceModel.Channels.CommunicationObject.Close(TimeSpan timeout) Exception rethrown at [0]: at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg) at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type) at System.ServiceModel.ICommunicationObject.Close(TimeSpan timeout) at System.ServiceModel.ClientBase`1.System.ServiceModel.ICommunicationObject.Close(TimeSpan timeout) at System.ServiceModel.ClientBase`1.Close() at System.ServiceModel.ClientBase`1.System.IDisposable.Dispose() There are various reasons for which the underlying connection can be at broken state before the using block is completed and the .Dispose() is called. Common problems like network connection dropping, IIS doing an app pool recycle at that moment, some proxy sitting between you and the service dropping the connection for various reasons and so on. The point is, it might seem like a corner case, but it’s a likely corner case. If you are building a highly available client, you need to treat this properly before you go-live. So, do NOT use using on WCF Channel/Client/ChannelFactory. Instead you need to use an alternative. Here’s what you can do: First create an extension method. public static class WcfExtensions{ public static void Using<T>(this T client, Action<T> work) where T : ICommunicationObject { try { work(client); client.Close(); } catch (CommunicationException e) { client.Abort(); } catch (TimeoutException e) { client.Abort(); } catch (Exception e) { client.Abort(); throw; } }} Then use this instead of the using keyword: new SomeClient().Using(channel => { channel.Login(username, password);}); Or if you are using ChannelFactory then: new ChannelFactory<ISomeService>().Using(channel => { channel.Login(username, password);}); Enjoy!

    Read the article

  • Autofac

    - by csharp-source.net
    A .NET IoC container written in C#. Focus on programmatic configuration with builder syntax. Zero intrusion into existing code. Create components using reflection or with lambda expressions for unlimited flexibility. Managed disposal of any IDisposable components created by the container within a defined scope.

    Read the article

< Previous Page | 1 2 3 4 5 6 7 8 9 10 11  | Next Page >