Problem using a third party dll in my VSTO add-in

[John]

Hello

I've made an Outlook 2003 add-in, using VSTO and vb.net.

Everything is working fine, except i can't run functions from a third party dll.

Does this dll need to be secured before it can be used? I've read through the documentation, and alot of guides and forums, but hasn't been able to find a good answer.

If so, how do i do this?

I've built my add-in based on the documentation on MSDN, 2-step guide.

(step 1 - http://msdn2.microsoft.com/en-us/library/aa537173(office.11).aspx)
(step 2 - http://msdn2.microsoft.com/en-us/library/aa537179(office.11).aspx)

Therefor i use a modified version on the appcheck/PIACheck, as well as the SetSecurity dll, to get the add-in to execute in the end user enviroment.


I'm kinda new to Office development, so if anyone got some good documentation or how-to's, i'd be very happy for your respons



Short about my add-in,

It add's a toolbar and button to a new inspector (if it's a mailItem) in Outlook 2003 (Office 2003 Pro + SP2). When the button is clicked, it should use a third party dll, which connects to a document management system. It stops executing the code when it tries the dll functionality.

All required software is installed. The add-in works fine in my dev.enviroment, so i guess it's only the security on the end user computer that has to be a little modified.


Thanks in advance
John

 

[Ken Slovak - [MVP - Outlook]]

SetSecurity doesn't account for auxiliary DLL's or additional assemblies and
they won't run in a VSTO addin unless they are strong named, signed and have
security set on them. You would have to modify SetSecurity specifically to
set the security context for that DLL or use similar code in another
security project to set the security for that DLL. Alternatives would be to
program something to write to CASPOL to set things or manually or some other
way of using the framework configuration tool to set the security context.

As a test just to verify that is the problem run the framework configuration
tool yourself on the test target system and set the security for the DLL and
then verifies your code runs.

 

[John]

Thanks alot for the response. I will try to extend the SetSecurity to manage other dll's aswell, to avoid having multiple security projects in my solution


John

 

[Ken Slovak - [MVP - Outlook]]

As a test to verify the problem you can use the configuration utility for
the Framework to add full trust for that DLL on a test machine and verify
that does solve the problem. If so, and I think it is, that means that
SetSecurity must be modified or another way of setting security for that DLL
used.

 

[John]

Solved the problem by doing the following,

The easy way to manage thirdparty dll's using the SetSecurity project provided by Microsoft, is simply to create multiple custom actions of the active output from the SetSecurity project..

ex.

You want to use a third party dll named "thirdparty.dll"

Install
/assemblyName="thirdparty.dll"
/targetDir="[TARGETDIR]\"
/solutionCodeGroupName="YourCompany.thirdparty"
/solutionCodeGroupDescription="Code group for thirdparty"
/assemblyCodeGroupName="thirdparty"
/assemblyCodeGroupDescription="Code group for thirdparty"
/allUsers=[ALLUSERS]


Rollback/Uninstall
/solutionCodeGroupName="YourCompany.thirdparty"


Please refer to MSDN for the full description for deploying VSTO add-ins