Disposing View Models - FULL STACK WPF (.NET CORE) MVVM #31

[@janhendrikschreier]

Hi Sean, as to your question of never hitting the destructor I do not have a definite answer, but I think it has to do with the GC not being too aggressive in Debug-Mode. So in Release-Mode it should be collected. I haven't had the time/pressure to validate this, but if need be, I would put some logging in the destructor to see if it gets hit in release-Mode. maybe this helps

[@SingletonSean]

That is a great point Jan! Throughout my career I've run into tons of differences between debug and release mode, so this could definitely be one of them. I'm excited to try this out. Thanks!

[@ivandrofly]

@@SingletonSean Hello Sean have you tested this theory of switching to release to hit the IDisposable.Dispose?

[@ivandrofly]

15:05 - IDisposable Issue

[@rosscarlson3701]

As opposed to the technique you describe at 8:30 for setting CanDispose, why not set CanDispose in each derived class constructor? Or, better yet, make CanDispose an abstract property and thus require each derived class to explicitly state whether or not it can be disposed with e.g. "public override bool CanDispose => true;".

[@ibrahim8905]

Thanks, really helped, excellent video!

[@joachimally1534]

I really liked the video, thanks man!

[@DrSteve123456]

Hi Sean, I understand both Transient and Singleton ViewModels makes our life difficult but why not just keep the all Singleton ViewModels?

[@vincentotieno9197]

Hi, from Nairobi. Would you kindly demonstrate some kind of error logging, especially for diagnostic purposes in production? Thanks in advance!

[@SingletonSean]

Definitely Vincent! Logging has saved my life in production apps. Of course for WPF apps, that involves logging to a file. Thanks for the suggestion.

[@omerkorkut]

perfect source thanks from turkey

[@k1ntoho]

Video quality: default (awesome)

[@SingletonSean]

Yes sir, thanks kiinetic!

[@ludovicwagner2656]

Hi Sean! I think that you're definitely an IDisposable-noob. I believe that all IDisposable-classes should be prefixed by "using" when instantiating them, right? I had to IDisposable my ExcelConnector class in one of my projects in order to make sure that I properly clean the memory or more precisely close the file (COM-marshal stuffs). By the way, really good tutorials, except that I got a bug somewhere which I haven''t managed to fix yet (I slightly change naming conventions and added a bunch of comments).

[@SingletonSean]

Hey Ludovic, I am familiar with using blocks and IDisposable. However, IDisposables most certainly do not need to be wrapped in a using block. A using statement is simply syntactic sugar to automatically call IDisposable.Dispose whenever the IDisposable goes out of scope (even from an exception).

[@ludovicwagner2656]

@@SingletonSean Hey Sean! I'm just wondering. I think I have some issues with my own program. So, I have an ExcelConnector class which implements IDisposable. I instantiate it via dependency injection (same kind of architecture as yours). It seems that I never reach the Dispose() method no matter is I use singleton, transient or scope... So, the Excel file never closes. Do you have some advice about how to get it working with using statement?

[@vesnx]

correctly implement IDosposable and you should be ok