In a recent post on the OData Blog, the team addressed an issue I encountered when updating from WCF Data Services 5.0 to 5.0.1, which caused my WCF Data Service to break.
The root of the problem lies in the bin deployment process. Bin deployment refers to copying and pasting a folder to a remote machine and expecting it to work without any other prerequisites. This approach is particularly useful when dealing with hosted servers where you may not have rights to install assemblies to the Global Assembly Cache (GAC).
The issue arises when the .svc file contains a specific version string that doesn’t match the version of the Microsoft.Data.Services DLL in your bin folder. For example, if your .svc file includes the following line:
<%@ ServiceHost Language="C#" Factory="System.Data.Services.DataServiceHostFactory, Microsoft.Data.Services, Version=5.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Service="YourNamespace.YourDataService" %>
And you’ve updated to a newer version of WCF Data Services, this mismatch can cause runtime errors. To resolve this, you have two options:
Update the version number in the .svc file to match the version of the Microsoft.Data.Services DLL in your bin folder.
Remove the version number entirely from the .svc file.
Implementing either of these solutions should allow your bin-deployed WCF Data Service to function correctly.
This experience highlights the importance of ensuring that version strings in configuration files align with the actual versions of deployed assemblies, especially when performing bin deployments.