One of the most common topics in your questions to us is the deployment of the applications you developed with Telerik Data Access. While working side-by-side with you to execute this generally complex task, we were quite pleased to find out that Telerik Data Access participates in a wide variety of scenarios. To make the process flawless for you, here, we suggest a few tips for solving the easy-to-miss hitches related to Telerik Data Access.

DON’T: Install Telerik Data Access on the deployment machine

This one applies to publishing either a desktop or a web application. Installing Telerik Data Access on the hosting machine may intuitively sound like a good idea. The reality is that doing so may cause numerous problems during runtime. For example, a very probable situation is an application to be developed with one version of Telerik Data Access and the host to have another one installed on it. Or, two different applications are hosted on the same machine and the second one refers a version of Telerik Data Access higher than the installed one. In both cases, you will observe errors due to a collision between the expected version of Data Access and the actual one.

This will happen because the design time mode of Telerik Data Access requires four of its own assemblies to be placed inside the host's Global Assembly Cache (GAC) folder. In other words, our handy development tools are powered by Data Access itself. Being like all .NET applications, our wizards and editors will look for the assemblies they refer to in the GAC folder first. However, the same is valid for your applications as well. In this situation, if Telerik Data Access is installed on the host, the published projects developed with it will most probably find a Telerik.OpenAccess.* assembly with an unexpected version. To you this will mean an error on start up. 

DO Instead: Set the Copy Local property of the Telerik.OpenAcces.* references to True

The recommended approach towards ensuring the presence of the necessary assemblies is to make sure that the Copy Local property of all the referenced Telerik.OpenAccess.* assemblies is True.

DON’T: Place a few applications that consume different versions of Telerik Data Access in one Application Pool

This one is really easy to miss, especially if two web applications are conceptually close, share resources in general, their references to the Telerik.OpenAccess.* assemblies are setup correctly, but are developed with two different versions of Telerik Data Access. Here, you will encounter the same version mismatch issue described in DON’T: Install Telerik Data Access on the server, but this time the application that runs first will work properly while the other one will suffer on start up.

DO Instead: Take the time to prepare

Here you can choose between either setting up a different application pool for each application, or upgrading the applications existing in the pool to the latest version you have available. In case you decide to upgrade, Telerik Data Access offers the Upgrade Wizard, which ensures that all the needed upgrade actions are performed. In this article you can find the details.

DON’T: Miss to add a reference to the Telerik.OpenAccess.Runtime assembly

Until now, we mentioned the setup of the references to the Telerik.OpenAccess.* assemblies that actually existed in the projects of your solutions, and as you might already suppose, a reference to the Runtime assembly is not one of them. We admit it, there is a dependency between our assemblies. So let’s check what happens: a dependency between the assemblies, and Runtime being one of the assemblies Telerik Data Access places in the GAC folder during installation. The result: no need to add a reference to Telerik.OpenAccess.Runtime while you develop your application, and an error on startup after publishing.

DO Instead: Configure the project that will be published

Here is the setup we recommend:

• The data access layer should be developed in a separate class library and the application that will be published has to refer to it.
• The application that will be published has to contain references to the following assemblies:
  • Telerik.OpenAccess.dll
  • Telerik.OpenAccess.35.Extensions.dll
  • Telerik.OpenAccess.40.Extensions.dll - in case the application targets .NET framework 4.0 or higher.
  • Telerik.OpenAccess.Config.dll
  • Telerik.OpenAccess.Runtime.dll
  • Telerik.OpenAccess.Web.40.dll - if you are developing a web application and it uses OpenAccessLinqDataSource.
• The Copy Local property of each of the latter references should be set to True.
• The Specific Version property of each of these references should be False.

Rebuild the solution after changing the properties of the references

A common source of runtime errors is that the performed changes are not actually applied. So, make sure to rebuild your solution before publishing. The proper assemblies will then be copied locally during build.


What are your problems and solutions when deploying Telerik Data Access data layer?