Issues with CommonServiceLocator >2.0.2

[josesimoes]

I've just updated the MVVM Nuget to v5.4.1.

In the process the new CommonServiceLocator was updated to 2.0.2. All that went fine. But there is now a 2.0.3 of CommonServiceLocator available. When updating to that version the app doesn't run anymore throwing this:

System.IO.FileNotFoundException: Could not load file or assembly 'CommonServiceLocator, Version=2.0.2.0

So I guess, despite the Nuget dependency mentioning CommonServiceLocator (>= 2.0.2) the package it's not actually that happy when using something above 2.0.2...

[Rod-in-NM]

@josesimoes I've experienced the same problem today. I added MVVM Light to a new WPF project, using the Package Manager Console, but when I went to build the app it complained about Microsoft.Practices.ServiceLocation not being found. Looking up that error I found that I should install the CommonServiceLocator package 2.0.3, which I did. But that had no effect on the problem. Would it be better to uninstall 2.0.3 and install some previous version, perhaps 2.0.1?

Addendum: I tried to uninstall the CommonServiceLocator package, but that failed with an error telling me that MvvmLightLibs 5.4.1 requires CommonServiceLocator.

[Rod-in-NM]

I posted a message on the MSDN WPF Forum about this. Got a reply, telling me that the issue was likely due to the version 2.0.3 of MVVMLight package. I was told to downgrade the CommonServiceLocator package from version 2.0.3 to 1.3.0, which would downgrade MVVMLight to a version where they would both "play nice" with each other.

[lbugnion]

Hi

At this point, given how many issues the ComonServiceLocator is causing, I would recommend moving you app to the. Net standard version of MVVM Light, where I got rid of the CommonServiceLocator. See http://mvvmlight.net/std10

[Rod-in-NM]

Thank you @lbugnion for that suggestion!

[Rod-in-NM]

@lbugnion, I got to thinking more about your recommendation. If I understand this link on Microsoft's documentation, I will probably not be able to use the .NET Standard version. We have a large Windows 7 user base that, unfortunately, will be with us for quite a while. 😞

[Spaier]

I have a separate .NET Standard 2.0 project with ViewModels and a .NET Framework 4.7.2 WPF app. I had to install MvvmLightLibsStd10 and CommonServiceLocator to both of them in order to get this error fixed. The same goes for any dependency of .NET Standard libraries.

[MrYossu]

@lbugnion Has this issue ever been addressed? I'm in the same position as @Rod-in-NM in that we are not moving to .NET Standard.

Thanks

[MrYossu]

@lbugnion And MvvmLightLibsStd doesn't support .NET4, which we need to. Please fix this.

[lbugnion]

Hi CommonServiceLocator is not maintained by me so I recommend that you talk to the maintainers of this project. It is unfortunate that they are not addressing the backwards compatibility.

Because of my new role, I won't have time to address the issue before a few weeks. I would be ok taking a PR and releasing a new version if that helps.

As for the Std version, it is the .net standard version so of course it won't work with DotNet 4.

Thanks Laurent

[pylgrym]

We now have 27 may 2021, and this issue is still not resolved. This means MVVMLight is the cause for the single nuget package in my company's application, that I have to keep permanently locked at version 2.0.2, because MVVMLight is not maintained. If I could only figure out what MVVMLight is actually used for, what problem it is trying to solve, I could port our application away from it. But when I look at the documentation, I have not been able to figure out what it is MVVMLight actually DOES, the documentation seems to sort of assume I already know why I need/want MVVMLight, and instead focuses on spreading the gospel. Does anyone know what it is MVVMLight does, that I can't already do without it? Thanks, Jakob.

[MrYossu]

@pylgrym If you look at the commits for the project, you'll see that there haven't been any updates to the code for two and a half years, so I think you are wasting your time expecting this to be fixed.

As for what MVVMLight is for, the main page here links you to the MVVMLight web site, which gives plenty of information about the library. I assume you understand MVVM in the first place, as if you don't, then you need to understand that first. Once you do, MVVMLight becomes fairly simple, as it just does the plumbing for you.

However, If I were you, I would look at moving to another library, as I don't think this one is going anywhere. It's been a couple of years since I did any MVVM, so I can't recommend any other framework specifically, but if you search around, I'm sure you'll find people discussing it, and people who are willing to advise.

Hope that helps.

[Rod-in-NM]

@pylgrym recently a friend of mine, whose knowledgeable on these things, informed me that MVVMLight is no longer being supported. He recommends using Windows Community Toolkit, which he said is taking over from MVVMLight. Looking at that repo I see that it is actively supported; there was an update only 10 days ago. I've yet to try it myself, but my friend is someone I trust to know what he's talking about. Looks like there's various versions of the Windows Community Toolkit on NuGet as well.

[robinTsl]

There is even documentation on how to migrate

[Rod-in-NM]

I didn't know that @robinTsl, thanks!

[pylgrym]

Thank you -

As for what MVVMLight is for, the main page here links you to the MVVMLight web site, which gives plenty of information about the library.

I may be looking in the wrong place, because the links to its documentation seem to just funnel into a 6-part Pluralsight course, which appears to be on MVVM in general, and not MVVM Light. I would expect the pitch to be a diff pinpointing what MVVM-Light does right that WPF got wrong.

I have been lost there before, with its phrases like "... The main purpose of the toolkit is to accelerate the creation and development of MVVM applications in Windows Universal, WPF, Silverlight, Xamarin.iOS, Xamarin.Android and Xamarin.Forms. The MVVM Light Toolkit helps you to separate your View from your Model which creates applications that are cleaner and easier to maintain and extend. ..." which I find give little insight - everybody already separates their views and models, so why-how does MVVMLight do this better than default WPF.. And of course it will 'accelerate', I wouldn't expect anyone to make a toolkit to make something worse and slower (well, not on purpose, at least..)

But you are right, and I will migrate away from it - thanks.

UPDATE: I attempted to access the pluralsight thing, but it appears I would have to be a plural-sight member to do so. So, this is the cause of my confusion - when I try to find the official documentation, I just find a phrase like 'to accelerate the creation and development of MVVM applications', and a pointer to a subscription-based site.