Notification Services custom delivery channel DLL trust issue

Question

We have an instance of SQL Notifcation Services for which we have written a custom delivery channel. We had this process up and running in our QA environment running Windows Server 2003 with SQL Server 2005. It took a little bit of tweaking to the get the custom DLL trusted however we got it all working.

We have since deployed this code to our Live environment. This runs Windows Server 2008 with an Instance of SQL 2005 for Notification Services but then we have an instance of SQL 2008 which hosts the actual DB instance for Notification Services. Notification Services works as it should however we cannot get the custom DLL to be trusted as a result the custom delivery channel won't work. We simply get the error

That assembly does not allow partially trusted callers

We have tried using the .NET configuration utility and caspol.exe to give the .dll full trust with no luck at all. The .dll is compiled as a .NET 2 dll as notification service requires this.

We are pretty much out of ideas at the moment and hoping someone can suggest something?

Answer 1

We have managed to fix our issue. It would appear that Windows Server 2008 is stricter in its implementation of code access. By giving granting access to the .DLL by it's strong name rather than it's path allowed Notification Services to access the code.

Notification Services was not at fault.

Answer 2

I think you have one of two choices:

1. Embrace SQL 2008 and get rid of Notification Services because it was deprecated. Use Reporting Services or SSIS to do what you need.

2. Revert back to SQL 2005.

IMHO, I'd go option 1. Continuing to build with deprecated tools is going to quickly find you in a situation where support (community or vendor) is going to be extremely hard to come by.

update

This was too long for comments.

Not to beat your head too much, but continuing to develop applications for a technology that was EOL'd (end of life) over 3 years ago was the first mistake. The EOL statement was made quite public.

The second was having a QA environment that is radically different from production. Before deploying anything to production, the QA environment should have been identical... same type of hardware, same OS's, same server versions and patch levels. Otherwise QA is a joke, as you've found.

Now, as to the "resolution", there really is only one path: Revert your production environment back to SQL 2005 with the appropriate patches in place.

I wish you luck.