Permitting Excel VSTO doc to run from anywhere on intranet

I have an Excel VSTO document that is installed via a Visual Studio setup project. I have security working to the extent that the document automation executes if the document is opened from the target installation directory. However, I need to allow for it to execute regardless of the location of the document. That is, anywhere from within the intranet. It is an XLT file and the user will never save to the installation directory. Basically, the automation should still work if the document is saved to a network share or any location other than the installation directory.

Do I need to install msosec.dll in the GAC on the installation system (to make use of the Office Document Membership Condition) What parameters are required with caspol.exe to permit the document to be opened from anwhere in the intranet zone and for all users (That is, I don't want to limit it to a share or a server.) Is this even possible

Follow up...

I seem to have a couple issues. First, I'm attempting to update the embedded application manifest during setup to use an environment variable to point to the automation DLL. Using an application manifest editor I saw that wasn't working. It was still hardcoded to C:\Program Files\AssemblyDir\Assembly.dll instead of %ProgramFiles%\AsemblyDir\Assembly.dll. I used the manifest editor to change it to the environment variable. Now the document automation will execute but only if the document is launched from a local drive. It will still not launch when I move it to a mapped drive or a network share. What am I missing

Thanks for the response Ji. I'm aware of that deployment model and I'd rather not use it. The main factor for using that deployment model is number of users. There are only going to be 3 or 4 users of this application so managing updates to the app will be easy even with local installations. It seems in this case that deploying to a server location adds complexity that isn't necessary.

To recap...

• I have an Excel template (XLT) and the automation DLLs installing to Program Files\CorpDir\AppDir. The user is not able to alter the installation directory.
• During installation I update the embedded application manifest to look for the automation DLL in %ProgramFiles%\CorpDir\AppDir. Using the environment variable allows the automation to be found regardless of where Program Files exists (like if it is not on the C drive).
• I update CAS according to the MS walkthrough on deploying a VSTO document locally.

The sticking point is that last bullet. I'm not sure how to update CAS so that if the document is opened from a network location it is still allowed to run the automation. I want the automation to remain local but the document can be opened from a network location. If a user has the automation installed then it will run. If a user does not then they'll get that message stating the automation cannot be found but they can still use the document. This seems like it should be possible because the embedded application manifest should always point to the local automation whether or not it exists. Using the environment variable in the automation path should guarantee that it will be found if it exists.

The confusing part is where does CAS consider the automation to be running from if the document is opened from a network location Only the document has moved, not the automation. The automation still exists in the local (Program Files) directory for which I'm granting permissions for it to run. Do I need to change how I grant permission for the automation to run Do I need to do something in CAS for document permissions

Since I've only received 1 response to this and it didn't really answer my questions (no offense Ji) I'm assuming I won't get any answers so I may have to use server deployment.

Hi Arnell,

Sorry about not making my response as clear as possible. Surely, your scenario could be achieved. To some point, it has some familiar features with the Server Deployment Model because we put the document to the network location, right If your document is stored at local driver, it will load the customization codes without any errors. But if you open it from network, the document is not recognized as trusted, even while the assembly in local driver is granted full trust. So you will receive the error message. To avoid this, you should use caspol.exe to trust the document too. The way is in the link I have already posted above. It is same with deploy document part in Server Deployment Model.

I also perform in my virtual machine, it works fine. The following is my steps:

1. Copy the assembly to my want installation directory, in this case, ※C:\LocalAssembly\ToDeploy.dll§.

2. Copy the document to a network location, in my case, ※\\sha-vjzho-vpcxp\Shared\ToDeploy.xlt§

3. Change the embedded manifest to point the assembly to the right place: ※C:\LocalAssembly\ToDeploy.dll§. In your scenario, you use the Environment Variable. I think it does not affect the result when I am using the exact path.

4. Use caspol to grant full trust to the assembly in a user level. Command line is as follow:

Caspol 每u 每ag All_Code 每url ※C:\LocalAssembly\ToDeploy.dll§ FullTrust 每n ※LocalAssembly§

5. Use caspol to grant full trust to the document in machine level. Command line:

Caspol 每m 每ag LocalIntranet_Zone 每url "\\sha-vjzho-vpcxp\Shared\ToDeploy.xlt※ FullTrust -n ※NetworkDocument§

Then I open the document ToDeploy.xlt from the trusted network location, it pops up a message box say ※Deploy Success§, which implemented in my codes. If you want to open the document from other network place, you should trust the new location again. It seems a little inconvenience, but I think it is designed to be so to ensure the security.

Thanks

Ji

Thanks for the suggestions but it was not quite the solution I needed. I did not need the XLT to be able to run from network locations. I needed to allow the resulting files (saved from the XLT) to run from network locations. I finally found the answer and it is not well documented or referenced, which really surprises me. After all, it is COMMON that a user will open an Excel document and save it to another location from where it was opened. It is ESPECIALLY COMMON that a user will open an Excel template and save it elsewhere. That is the situation I needed to account for. Specifically, for when the file is saved in a network location. (If it were always saved locally this wouldn't be required because by default VSTO documents are granted permissions at the machine level.)

The solution requires that a custom membership condition be added to the CAS policy. The membership condition required is provided by msosec.dll. It allows for security matches on Word and Excel documents. I followed the instructions in this article but to summarize:

• Ensure msosec.dll is installed in the GAC.
  • This component should not be installed using an installer package. If any security policy is setup using the condition it provides and then msosec.dll is uninstalled ALL managed code will fail to run. Since an uninstall operation removes installed components it should be setup in the GAC via a manual process or via a custom process that runs during installation so that it will remain even after an uninstall operation.
• Setup a CAS code group under LocalIntranet_Zone pointing to the network location from which documents will be opened.
  caspol -m -ag LocalIntranet_Zone -url "\\ServerName\FolderName\*" Nothing -n "Doc Folder"
• Setup a CAS code group under the preceeding code group that grants full trust to Office documents. This step requires a file installed by office called msosec.xml which documents the custom membership condition.
  caspol -m -ag "Doc Folder" -custom "C:\Program Files\Microsoft Office\Office11\Addins\msosec.xml" FullTrust -n "Documents"

I really didn't want to limit it to a specific network location but it is not recommended to allow VSTO office documents to be opened from any location because it opens the system up to security threats.

I think I'll eventually create a tool for client IT personnel or our consultants to specify network locations for VSTO document storage. The tool will then perform the required steps via the System.Security namespace. It could also check the current security policy and display specific existing settings (based on code group name possibly).

Hi

I\m stuck with a similar problem, hope some one can help. Well i have a vsto word document in sharepoint document library, and it's customization assembly in a hard-coded location (for testing). When i open the doc from it's original location i.e. same as the assembly, it works fine.

After uploading to sharepoint document library, i added msosec.dll to GAC, added the sharepoint document path to LocalIntranet_Zone as you have mentioned above and also the msosec.xml under the folder in .Net Framework 2.0 configuration. When i open the document from sharepoint the document errors saying it cannot load the customication assembly as it does not have required permissions to execute. But if i save the document locally and open it works. What am i missing

Kind regards

satish