VSTO/ CAS Deployment Hell - How Good Intentions Go Bad

The Scenario

I'm supporting a VSTO application that does a pretty typical Office style thing. CAS policy updates to let the particular .NET assembly run are added to the end-users machine at install time, and the application works fine when the document is on the local machine.

The Nightmare

When the Office document is on a network share, a CAS error is raised. The solution is to add the server share to the OfficeDocumentMembershipCondition, and based on the code group membership condition, it can be granted full trust.

For some reason, the Office 2003 DLL (Msosec.dll) isn't installed in the GAC when Office is installed, so it is left to the poor VSTO developer to try to get the assembly into the GAC to do all the necessary CAS work. This MSDN document describes how to do it, and what a mess. You can tell your user "Umm, I hope your an admin. Let crack open the .NET Framework configuration tool and manually add an assembly to something called the GAC". That's a great experience. Alternatively, you can hope that the .NET Framework SDK is installed and batch out to GACUtil during your install (which will be running under the context of a local admin).

Obviously, this is a total mess. It creates a vulnerability (users need at least a temporary promotion to admin to add Msosec to the GAC), and it seriously error-prone. It is crazy installation experiences like this that really hinder the uptake of smart clients.