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.
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.
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.
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.
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.
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.
Here is the setup we recommend:
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?
Subscribe to be the first to get our expert-written articles and tutorials for developers!