Referenced assemblies automatically replaced by visual studio

Question

I have 2 projects, a Portable class library and a regular unit test project. In the Portable class library, I use NuGet to reference the Microsoft.BCL Portability pack, which comes with 2 assemblies (System.Threading.Tasks.dll and System.Runtime.dll both v1.5).

However, when I try to reference these same dlls in my unit test project (both with NuGet and manually browsing to the directory \packages\Microsoft.Bcl.1.0.19\lib\portable-net40+sl4+win8+wp71), visual studio automatically points the refence to the dlls in another folder located here C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\, which is of version 4.5.

Now a method I need to test accepts CancellationToken as a parameter and throws the compile error: The type 'System.Threading.CancellationToken' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Threading.Tasks, Version=1.5.11.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' because its v4.5 library is whats referenced and not v1.5.

I have however been able to write tests for methods that does not use any of those features from the v1.5 BCL library.

Why is visual studio replacing my referenced library with the one that came with the framework? How do I tell visual studio to just use the ones I'm pointing to in a specific directory?

Using Visual Studio 2012 Update 2.

Sadism

Unit testing PCL code has been a problem. The workaround is to create tests for the specific platforms you want to support. – Ocampo

Answer 1

This seemed like an issue with visual studio update 2 as this does not occur with visual studio 2013. I opened the project in the newer version of visual studio and the correct assemblies were loaded.

I'm not sure if a plugin was the cause of this.

Sadism

Answer 2

It is expected that references to System.Runtime.dll v1.5/v2.5 and System.Threading.Tasks.dll v1.5/v2.5 are replaced with the ones in the platform for .NET Framework 4.5 projects. However, this should occur behind the scenes and should not be observable.

What I suspect has happened is that you started with a .NET Framework 4.0 test project and retargeted to .NET Framework 4.5. Unfortunately, when this occurs, NuGet does not reinstall the package to get the 4.5 project in the correct state. To attempt to fix this, try the following:

1) Uninstall Microsoft.Bcl.Async package including all of its dependencies from all projects - you can do this by right-clicking on Solution Explorer -> Managed NuGet Packages for Solution

2) Open any App.Config in each project that had the package installed and remove all assemblyBinding entries that reference to System.Runtime and System.Threading.Tasks.

3) Ensure that no project is referencing System.Runtime and System.Threading.Tasks, if they are, remove the references

4) Reinstall the packages

This should get you in a good state.

Make note, that this behavior is being improved in NuGet 2.7 where they will now spit out an error/warning on retarget when you get into this state.

Cowbird

I just did this and end up with the same problem. I created a .net 4.5 test project and referenced those exact v1.5 dlls, visual studio still ended up pointing to C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\Facades\System.Runtime.dll, etc. – Sadism

How are you referencing the binaries? Do not directly reference these binaries - let NuGet install the package. If the problem still occurs can you use the Contact Owners link on this page: nuget.org/packages/Microsoft.Bcl/1.0.19. And we'll organize for a repro. – Cowbird

Answer 3

Had similar problem (and might save someone a frustrated days work) - turned out that the Reference Paths in the solution (right-click PROJECT (not solution), and choose properties. In the lefthand side there are settings for the project (Application, Compile, Debug, Referenes ect).

Choose the "references", and then the "Reference Paths" button above the "Referenes" grid. If any of the referenes in here points to directories where OLD DLL's can be found, VS (in my case 2013), will pick a DLL from here.

Which path is actually being used for resolving the DLL can be seend in the "references" grid.

Remove all the obsoltete paths, and recompile.

This also removed NuGets "Failed to generate binding redirects for 'XXYYZZ'. An item with the same key has already been added."

Herein

Answer 4

Thought I would add this in case it helps anyone.

I had third party DLL (version 3.0.120) in a Dependencies folder, and was referencing it in a project, and all was working fine.

A new version of the DLL was released via NuGet. It was installed into:

..\packages\Independentsoft.Exchange.3.0.530\Lib\net45\

In order to use the new DLL I deleted the old reference, cleaned the project and added the new DLL as a new reference.

I then compiled and deployed (I work with SharePoint) the project, but the code failed and debug showed that it was still using the old reference, even though I had deleted it.

I then noticed that when studying the properties of the new reference within VS, the version number of the DLL was always the old one (3.0.120) instead of the new one (3.0.530).

After many hours, I deleted the old DLL in the Dependencies folder, cleaned, built and deployed the project and then all worked fine.

It appears that, as long as the old DLL was present in the project, VS kept pointing any new references to the new version back to the old version.

Hope this helps someone.

Altercation