Privately Deploying SQL Server Compact with the ADO.NET Entity Provider

re: Privately Deploying SQL Server Compact with the ADO.NET Entity Provider

Maarten van Stam — Sat, 01 Nov 2008 05:39:36 GMT

Steve,

I just created (well been messing around for a week now ... ) to create an installer for a VSTO project including the compact dlls. Everything fine until I deploy to this clean machine and the customized vsto document in a different location than the .vsto manifest (and the rest of the dlls).

In that case you get the darn "Unable to load sqlceme35.dll" crash. I tested this and it can be solved to move the dlls to a location that can be found in the system path (such as System32) but this makes the private install excercise a bit useless as the advantage of having the private install was that I didn't have to involve IT in any way.

Do you have a suggestion on how to get these dlls 'in vision' without having IT in my face ;-) ?

re: Privately Deploying SQL Server Compact with the ADO.NET Entity Provider

Steve.Lasker — Sat, 01 Nov 2008 18:59:30 GMT

Hi Marteen,

The problem you’re hitting is the way private deployment works is by leveraging the probing path of the .NET loader. When the .NET Loader first runs, it looks in the GAC for that strong name assembly. …assuming it’s strongly named. If it can’t find that specific version in the GAC, it will then go through its probing path. The next path is the directory for the app that started the process. Being a VSTO app, I’m assuming you’re launching this from Word or Excel. This is likely why it’s not working in your scenario.

I’d have to think if there are other probing path options available, but can’t think of any right now…

Steve

SQL Compact privately installed and VSTO

Maarten van Stam - Soft As In Software :-) — Wed, 05 Nov 2008 01:44:40 GMT

I just created (well been messing around for a week now with various parts of that installer) an installer