Why isn't ServiceStack.Text being copied to Bi

Question

I have added ServiceStack.Redis via Nuget to an assembly that I have. That package has a dependency on ServiceStack.Common which has a dependency on ServiceStack.Text

this project is referenced from my web project, but when I build the Website and load it in a browser I get the error

Could not load file or assembly 'ServiceStack.Text, Version=3.9.24.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.

Sure enough, when I go to the Bin directory of my website it isn't there. Oddly enough, if I go to the Bin directory of the class library I am referencing (the one I pulled the Nuget package into) it IS there.

To recap

• ClassLibrary
  • ServiceStack.Redis via Nuget (includes ServiceStack.Common and ServiceStack.Text)
  • All of these make it in the Bin dir upon build
• Web Proj
  • Refs ClassLibrary
  • all dependencies are moved to Bin except ServiceStack.Text

I'm stumped. Does anyone know why?

Note: The error appears to be looking for version 3.9.24, but the version Nuget pulled is 3.9.26. If I move it to the Web/Bin manually it works though

Answer 1

I had this somewhat bizarre problem in several versions of Visual Studio, atm 2013. It has occurred at random.

I too have dependencies on ServiceStack.Common, which implicitly depends on ServiceStack.Text. However, I am not directly at any place referencing any class, struct or the like inside ServiceStack.Text binary.

Even having set

Copy Local = true

ServiceStack.Text.dll is not being copied to the output folder.

I have experienced this with numerous versions of ServiceStack dll's, currently v4.0.15. This could be a more general Visual Studio bug concerning dependency-chains with dead ends in not directly used libraries? Probably ServiceStack.Text is marked as a dependency in other ServiceStack dll's, but Visual Studio tries to outsmart this by seeing, the library can be excluded (I'm just speculating).

Anyway, I solved it by simply using ServiceStack.Text directly in a private method put in a random used file in my own library:

/// <summary>
/// Needed because of Visual Studio bug? Don't use this method.
/// </summary>
private JsonValue DontDoIt()
{
    return new ServiceStack.Text.JsonValue();
}

I would expect the compiler to exlude an unused private method - indeed maybe it does in the IL code, but none the less this makes VS copy the dll to the output directory.

Answer 2

As esker says there may be some problems with Nuget when updating but there are also some problems with ServiceStack Nuget packages.

The latest package working as of today is 3.9.60. ServiceStack.Text.dll is really 3.9.60.

ServiceStack 3.9.61 and above has ServiceStack.Text.dll version 3.9.59.

The copy problem is appearing again.

Answer 3

Check the assembly reference properties in your .csproj files, perhaps they are still referencing the older version of ServiceStack.Text. Sometimes I find that NuGet will fail at some point during a package update and leave your assembly references in a bad state. For example, your packages.config file may correctly show that all ServiceStack references are at the same version number, but your .csproj file may be referencing 3.9.24 for ServiceStack.Common and 3.9.26 for ServiceStack.Text. Thus, it will copy different versions of these assemblies to your bin directory. It likely can still build successfully because you have the older copy of ServiceStack.Common cached in your NuGet packages directories.

I fix this by either manually editing the .csproj file to have the correct assembly path and version number, or by uninstalling and reinstalling the affected packages via NuGet (this would likely require reinstalling most/all of the ServiceStack packages since ServiceStack.Text is such a low level dependency.