MVVM Light assembly conflict with Microsoft.Practices.ServiceLocation - mvvm-light

I've got an issue where my WPF application cannot be published with ClickOnce.
The application uses Nuget packages MVVM Light 4.1.26.1, Unity 2.1.505.2, CommonServiceLocator 1.0.
The problem is that when I publish, it all build fine, but I get this error when I try and install the clickonce package:
Unable to install or run the application. The application requires that assembly Microsoft.Practices.ServiceLocation Version 1.0.0.0 be installed into the Global Assembly Cache (GAC) first.
I did some digging and saw that there were two references to that assembly in the manifest, and one of them was marked as a prerequisite which I can't get rid of:
<dependency>
<dependentAssembly dependencyType="preRequisite" allowDelayedBinding="true">
<assemblyIdentity name="Microsoft.Practices.ServiceLocation" version="1.0.0.0" publicKeyToken="59D6D24383174AC4" language="neutral" processorArchitecture="msil" />
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly dependencyType="install" allowDelayedBinding="true" codebase="Microsoft.Practices.ServiceLocation.dll" size="29760">
<assemblyIdentity name="Microsoft.Practices.ServiceLocation" version="1.0.0.0" publicKeyToken="31BF3856AD364E35" language="neutral" processorArchitecture="msil" />
<hash>
<dsig:Transforms>
<dsig:Transform Algorithm="urn:schemas-microsoft-com:HashTransforms.Identity" />
</dsig:Transforms>
<dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha256" />
<dsig:DigestValue>eee+a+dQmhpSY/ApLxRipXdEp8UsTaZHXHClBU0Iwyc=</dsig:DigestValue>
</hash>
</dependentAssembly>
</dependency>
I'm pretty sure the issue with the ClickOnce is down to there being two references to this assembly with the same version (but notice the different public key tokens).
I created a very simple repro as follows:
Create a new WPF application
Add Nuget package MVVM Light
Add Nuget package Unity (also adds dependant package called
CommonServiceLocator)
Build and publish the WPF application
Try and install the published MyApp.application clickOnce package....get the error detailed above
Here's a repro project:
skydrive repro project
Any ideas how I might get over this?

It's now 2019 and I ran into a similar problem, found this question as first entry, but found another (more recent) problem and solution to get MVVMLight and Microsoft.Practices.ServiceLocation work together.
Mvvmlight 5.4.1.1 doesn't work with CommonServiceLocater 2.0.4 (which is both the lastest stable build in March 2019) the way mvvmlight bootstraps it's ViewModelLocator.cs
Two things worked:
either downgrading to
CommonServiceLocater 1.3.0
Mvvmlight 5.3.0.0
or changing the reference from
using Microsoft.Practices.ServiceLocation;
to
using CommonServiceLocator;

Please try again. I just pushed a new build (4.1.27.0) to Nuget that is depending on the official CommonServiceLocator package where available. This should fix your issue. If you have more problems, please make sure to let me know.
Cheers
Laurent

Yes. The MVVMLight ServiceLocation assembly uses a different public key token than every other public implementation. It has made my life a nightmare for quite some time. I finally had to rip out all my nuget assemblies and go back to file references in a common directory for now. I am waiting for Laurent to fix this.

I had this problem as well despite having the 4.1.27 build of the MVVMLight nuget package installed. After hours of frustration I figured out it was because I had the MVVMLight toolkit (v.4.1 for Visual Studio 2012) installed. Once I uninstalled it, my deployment started working again.
Just thought I'd leave this here in case anyone else runs into that particular scenario.

Related

System.Threading.Tasks.Extensions unloaded by IIS

I have a project with assembly which refers to System.Threading.Tasks.Extensions, Version=4.6.28619, It's an old ASP.NET App hosted on IIS. After compilation, the app is running and everything is OK. After some time, the app throws an exception.
"System.Exception: Could not load file or assembly
'System.Threading.Tasks.Extensions, Version=4.1.0.0, Culture=neutral,
PublicKeyToken=cc7b13ffcd2ddd51.
After the recompilation and restarting the APP, everything works fine, but after a few hours, the exception is thrown again. What could be the problem?
I have tried to change web.config to use System.Threading.Tasks.Extensions in the correct version, but it didn't help.
Version=4.6.28619 is file version, not the Assembly Version. I did goodle on System.Threading.Tasks.Extensions history.
I found the 4.3.0 should be the correct version in your project.
Other version couldn't find 4.1.0.0 version dll like picture above. Package version >=4.4.0, using 4.1.1.0. <4.3.0, using 4.0.0.0.
Now you can follow the suggestions below to check the issue
Find the package System.Threading.Tasks.Extensions like my first picture.
If you have multi project, make sure all the projects using the same version package.
Delete the .vs folder
Check the web.confg/app.config file, and check the version of System.Threading.Tasks.Extensions, if there are duplicates, please delete them.
If the steps above not works for you, maybe the issue related to deployment. You can try the binding redirects.

ASPNETCOMPILER error ASPCONFIG: Could not load file or assembly

I believe this is not the same question as this for a couple of reason
There was no upgrading
I tried doing the x86 and x64 build and that did not work
The current versions of for newtorn.JSON are 4.5
First time working with TeamCity. The ASPNETCOMPILIER cannot load the assembly for 'Newtonsoft.json'
I do not know how to handle this. Some key points
NewtonSoft is in the packages folder
When restoring refences this could not be resolved
You're probably using indirect multiple versions of NewtonSoft.Json. As there can be only one version in the bin folder and NewtonSoft.Json is strong named, you will get
"Could not load file or assembly" errors runtime.
Solution is then to use the version 12 of NewtonSoft.Json also in your ASP.NET project, so version 12 could be loaded. It's recommend to update NewtonSoft.Json with NuGet.
If you still get load errors then with other version number, then also add to your config (if not done by nuget):
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30AD4FE6B2A6AEED" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-12.0.0.0" newVersion="12.0.0.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
I've encountered this sort of issues more times than I like to admit and I've been doing this for a while now, so don't feel bad. Each time it's something small that really should not be an issue. Patience is required and is good for any developer to be reminded of.
In web projects changing the target CPU does not always change the values where it's supposed to. It's probably a bug. But what you can do is go into the project file itself and check for cases of "any cpu" and explicitly change any occurrence to x64.
If that fails make sure all your references use the the most up to date version of the framework (and target cpu if applicable) required for the newtonsoft library, although I think 4.5 is fine.
Create a blank project and see if you can install the library there and have it compile correctly, less stuff in a project will make it easier to troubleshoot.
Lastly, turn on full debugging with verbose output, you might get some more detail if you haven't already done that.
The best way I've found to resolve these issues is to isolate the problem by recreating the conditions I believe exist. When creating a new project, often I'm able to assess what's changed or missing. In the case of the target CPU, I knew it could only have been a mismatch since none of my code was present when I tested it in a fresh project.

VIsual Studio 2017 NuGet package installs well but is not recognized

I have Solution A which has a .NET Core 1.1 class library project. In the Package properties I filled all NuGet fields and selected to create the NuGet upon successful build. This project builds just fine and the NUPKG is created. BTW How can I automatically copy the generated NUPKG to a local directory (my own repository)?
Then I have Solution B which is an ASP.NET Core 1.1 web application. In it I browse to my local repository (where I have manually copied the NUPKG built by Solution A) and install my SolutionA.MyPackage into the web application. VS.2017 says it was successful at installing it. I see it listed in the project's NuGet dependencies.
However, when I try to use ANY of the objects defined in that NuGet package I get a red highlight saying it is not found as if there was no NuGet or assembly reference to that DLL but there is!
What is causing this Visual Studio generated Nuget package to be installed and yet act as if it has not even been referenced?
UPDATE - CSPROJ TARGET
As for copying to my local repository, I added this to CSPROJ but it was not working (somebody had suggested it as I put it). I finally figured out why it did not work, the ItemGroup must be inside the Task.
<Target Name="CopyPackage" AfterTargets="GenerateNuspec">
<ItemGroup>
<MyPackageFiles Include="bin\Release\PackageId.*.nupkg" />
</ItemGroup>
<Copy SourceFiles="#(MyPackageFiles)" DestinationFolder="D:\My Repository\MyNugget\Publish" />
</Target>
UPDATE NuGet Inspection
I opened the NUPKG with NuGet Package Explorer and it shows this more or less:
content\
Properties\
launchSettings.json
Views\
Shared\
rest of my stuff here
contentFiles\
any\
netcoreapp1.1\
Properties\
launchSettings.json
Views\
Shared\
rest of my stuff here
lib\
netcoreapp1.1 (.NEtCoreApp, Version=v1.1)
MyPackage.dll
UPDATE 3
Since NuGet seems to have stopped working (used to work well earlier) I opted for using an Assembly Reference rather than a NuGet (for now). In this situation something odd happens, when coding I can reference ALL the objects in the referenced assembly (former NuGet) and therefore no compilation errors on the main project BUT when I then run the web application I get an internal error because it says
FileNotFoundException: Could not load file or assembly
'MyPackage, Version=0.0.3.0, Culture=neutral, PublicKeyToken=null'.
The system cannot find the file specified.
Unknown location
Which is strange because in the Solution Explorer I see the assembly reference and when I click on it (main application) I can navigate to all the objects that I have defined in that assembly. Why it cannot find it anymore?
It is working again (as it was before!). Today I could open the solutions but when I tried to download an extension (Tools | Extensions) I got an error message about an Access Denied or something like that. It has happened before since I installed to VS.2017.
Of all the Visual Studios I have used since 2002 this has been the most unstable! (and I have update 15.2).
When I saw this error happening again I knew how to get rid of it and thought, "hey, maybe that is what is keeping the NuGet package to be installed but not found or the problem with a direct assembly reference".
So I went to my C:\Users\AppData\USER\Local\Microsoft\VisualStudio\15.2* folder and removed it completely.
After that I the ACCESS DENIED issue went away with the side effect that I had to reinstall all extensions again. I attempted again to install my own NuGet, it did so successfully and as expected (was not happening during the long glitch) the objects were found and the web application worked again.

TFS 2013 Build - Newtonsoft.Json - Visual Studio 2015

Update:
So, I logged on to the server and opened the project with VS 2013. I clicked "enable nuget package restore" on the solution context menu. Now, it builds on the server. The problem is, I don't know how to do the same thing in VS 2015. There is no right-click menu. I have already enabled "allow automatic package restore" in Options.
-End update
I have a project in Visual Studio 2015. I can build and run it successfully on my local machine. It uses Newtonsoft.Json (JSON.net) which it obtains from Nuget. When I check in, and my continuous integration build runs on the build server, it throws an exception that it cannot locate the JSON.net assemblies:
The type or namespace name 'Newtonsoft' could not be found (are you missing a using directive or an assembly reference?)
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets (1605): Could not resolve this reference. Could not locate the assembly "Newtonsoft.Json, Version=7.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed, processorArchitecture=MSIL". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
I have looked all over to see what is causing the Nuget package to fail. Is it because I am using Visual Studio 2015? Is Nuget jacked up?
Has anyone experienced this issue?
Check the references in your project carefully against the entry in your packages.config file.
I had this same error and found that the project referenced Newtonsoft.Json 4.5.1 in its references, but in packages.config, the entry was as follows:
<package id="Newtonsoft.Json" version="5.0.8" targetFramework="net45" />
Changing the entry in packages.config to 4.5.1 instead of 5.0.8 fixed the problem.
<package id="Newtonsoft.Json" version="4.5.1" targetFramework="net45" />
I discovered this by examining the local _work folder on my CI build server, and finding that the location that it was trying to pull the .dll from was not available in there; then I traced it back to figure out why. (Another possible cause of this issue is a NuGet package that has been deprecated. I had one of those as well that threw the same error.) I'm not sure how they got out of sync; this was a project that was originally worked on by someone else that I inherited.
Hopefully, even if this doesn't solve the problem for you, this will help somebody else down the road.

Umbraco 7.2 cannot add controller

I'm trying to add a controller to the Controllers folder in my Umbraco 7.2 project (I've created a new empty ASP.NET MVC 4 in VS2013) but I'm getting the error
Could not load file or assembly 'ClientDependency.Core, Version=1.7.1.2, Culture=neutral, PublicKeyToken=null` or one of its dependencies. The system cannot find the specified file.
Why is this?
Normally if you add umbraco to your project, it will also add ClientDependency as a DLL reference. You should check if you have these DLL's in your bin folder.
I am pretty sure you don't have them.
IF you have the dll's in your BIN folder, it's the wrong version. In that case you need to clarify your setup more indepth.
This is a known issue in Umbraco 7.2.0 and 7.2.1 (and probably others). It has been fixed on 7.2.2 but even when/if you update you might still experience the issue.
Let's not follow the following workaround because it will put your website at risk. Read this: http://umbraco.com/follow-us/blog-archive/2015/2/5/security-alert-update-clientdependency-immediately
The suggested workaround is to run the following command in the Package Manager Console:
Uninstall-Package ClientDependency -Force
And once the uninstall is done:
Install-Package ClientDependency -Version 1.7.1.2
Source: http://issues.umbraco.org/issue/U4-5996 and https://our.umbraco.org/forum/getting-started/installing-umbraco/38333-Error-creating-Controller-in-Umbraco-v6?p=2#comment169649
Your only 2 options are really:
Update to Umbraco >= 7.2.2: Update-package UmbracoCms
Add your controllers as classes and manually inherit from Controller or UmbracoController (or other base controller classes you want to use)
I had the same problem tonight. I changed the versions in packages.config to the following:
<package id="ClientDependency" version="1.7.1.2" targetFramework="net45" />
<package id="ClientDependency-Mvc" version="1.7.0.4" targetFramework="net45" />
Make sure the bin dir matches and you should be good to go. You might need to shutdown the project in VS and reopen it too. If you run into the same issue with EntityFramework, change to 5.0.0 and make sure the correct version is in your bin dir.
Upgrading the umbraco mvc to the latest version(v7.2.2) solves the problem.
I use Nuget Package Manager v2.8.50926.663 and Visual Studio 2013.
Hope this helps you as well.

Resources