Options
Can an Outlook Add-in be obfuscated, and if so, how do I do
mdpowersslo
Posts: 9
I am brand new to SmartAssembly, and am having problems finding some answers to questions. Please forgive me if this has already been answered.
We have two Outlook add-ins, both written in C#, one using VS2010 and VSTO2010, the other (for Outlook 2003) using VS2005 and VSTO2005.
For now, I'm going to worry only about the VS/VSTO2010 add-in; answers to the questions on this may help me figure out what to do for the older add-in.
As part of the build process, VSTO2010 creates a "Manifest" file that contains hash codes representing each of the DLLs on which the main DLL is dependent. That manifest file is installed along with the DLLs, and is used by the VSTO loader to make sure that nothing has changed.
SmartAssembly is a post-build process that changes the contents of the main DLL ... and either merges or embeds each of the DLLs on which the main DLL is dependent into the main. The hash code for the main then does not match the value saved in the Manifest ... and the other DLLs are not present. The VSTO loader encounters an error, and the add-in does not get loaded into Outlook.
Is there ANY way to get around this "Catch-22"???
We have two Outlook add-ins, both written in C#, one using VS2010 and VSTO2010, the other (for Outlook 2003) using VS2005 and VSTO2005.
For now, I'm going to worry only about the VS/VSTO2010 add-in; answers to the questions on this may help me figure out what to do for the older add-in.
As part of the build process, VSTO2010 creates a "Manifest" file that contains hash codes representing each of the DLLs on which the main DLL is dependent. That manifest file is installed along with the DLLs, and is used by the VSTO loader to make sure that nothing has changed.
SmartAssembly is a post-build process that changes the contents of the main DLL ... and either merges or embeds each of the DLLs on which the main DLL is dependent into the main. The hash code for the main then does not match the value saved in the Manifest ... and the other DLLs are not present. The VSTO loader encounters an error, and the add-in does not get loaded into Outlook.
Is there ANY way to get around this "Catch-22"???
Comments
Merging/embedding is an option.
Thank you in advance.
What I do now is to obfuscate each of the assemblies that I reference in the main Outlook add-in, and reset the references for those assemblies to the obfuscated products. I do NOT obfuscate the main add-in assembly. This way, the manifest generated during the Visual Studio build of the main add-in assembly is calculated against the actual assemblies used. For us it works beautifully.
This works if your main add-in assembly does not need to be obfuscated, but only the lower-level referenced assemblies. If you have things in the main assembly that you want obfuscated, you could refactor those things into another assembly.