What are the challenges you face when working across database platforms? Take the survey
Options

Can an Outlook Add-in be obfuscated, and if so, how do I do

mdpowersslomdpowersslo Posts: 9
edited January 23, 2013 11:24AM in SmartAssembly
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"???

Comments

  • Options
    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.


    Merging/embedding is an option.
  • Options
    Merging/embedding is NOT an option ... merging the other DLLs into the main changes the main so that it no longer matches the hash recorded in the Manifest.
  • Options
    Have anyone solved this problem? I'm on the same scenario with VSTO.
    Thank you in advance.
  • Options
    Actually, the solution is fairly simple, if not cumbersome ... and may not necessarily work for you.

    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.
Sign In or Register to comment.