locked
Obfuscate Add-in ? RRS feed

  • Question

  • My company tasked me to develop an add-in using .NET technology but they require that any code shipped to be obfuscated. Can this be done? I told them because the home server must be able to load the add in that this is not possible and i got yelled at... What options can i provide them to protect my company's code?

     

    Saturday, May 3, 2008 4:47 AM

Answers

  • The current requirements for a WHS add-in require a specific class name in a specific namespace that relates to the assembly name... by default your average obfuscator is going to throw a lot of these requirements out the window... instead it'd be up to you to configure the obfuscator (I know Dotfuscator can do it) to explicitly exclude obfuscating the HomeServerTabExtender and HomeServerSettingsExtender classes which is all the WHS Console is looking for... beyond that you should have no problem obfuscating all of the other code in your assembly.

    Monday, May 5, 2008 6:34 PM
    Moderator

All replies

  • Yes, you can obfuscate .Net code. See e.g. this MSDN article, found as the top result of a Google search for obfuscate .net code.

    Please search before you post. You can almost always answer this sort of question yourself, and you may learn something interesting in the process.
    Saturday, May 3, 2008 12:40 PM
    Moderator
  • Are you sure you can obfuscate an WHS Add-in? i tried all the major obfuscators like Dotfuscator, Skater etc after obfucscation WHS will NOT load the addin.

     

    Saturday, May 3, 2008 7:21 PM
  • I have no personal reason to want to obfuscate the source for a WHS add-in (or any other .Net code), but the only thing that I can think of that would be problematic is that assembly names, namespaces, etc. need to match up properly. I have no trouble believing that the simple obfuscation tools would break that, but I also have to believe that the more robust ones can be tweaked to avoid the issue.
    Sunday, May 4, 2008 2:41 AM
    Moderator
  • The current requirements for a WHS add-in require a specific class name in a specific namespace that relates to the assembly name... by default your average obfuscator is going to throw a lot of these requirements out the window... instead it'd be up to you to configure the obfuscator (I know Dotfuscator can do it) to explicitly exclude obfuscating the HomeServerTabExtender and HomeServerSettingsExtender classes which is all the WHS Console is looking for... beyond that you should have no problem obfuscating all of the other code in your assembly.

    Monday, May 5, 2008 6:34 PM
    Moderator