none
Dotfuscator Problem RRS feed

  • Question

  • Hi!

    I tried to obfuscate a library assembly (dll) with dotfuscator community edition present in Visual Studio 2005 installation.

    this assembly is used by an exe assembly and is strong name signed.

    I've resigned the library assembly and I copy this dll (obfuscated and resigned) in the exe path.

    Result: my exe assembly don't work... because it not find a class contained in my library...

    the exe assembly have a reference for this library assembly... and don't use reflection for use it...

    the sign of my class in the library is "Public NotInheritable Class nameClass".

    I don't use remoting, serializing, but inside this library I use reflection to another library assembly that it's not obfucated...
    I think that the limitation for using remoting, serializing and reflection is to the library obfuscated and not from the library obfuscated to another one (not obfuscated)... it's correct?

    Anyone can help me?

    Thanks


    Tuesday, May 13, 2008 8:33 AM

Answers

  • Well, I sorted out my issue- I'll post what I found here in case someone finds this thread via a search and has a similar problem.

     

    My first mistake- no point in obsfucating the Microsoft.Office.Interop.Excel assembly at all- its Microsofts and not mine, so none of my secrets are in there anyway- as long as the .dll is in the same directory as the other assemblies it will work fine.

     

    Once I did this my assemblies obsfucated without any issue, but when I ran the application I got a new error;

     

    Could not find any resources appropriate for the specified culture or the neutral culture. Make sure "<assemblyname>.Properties.Resources.resources" was correctly embedded or linked into assembly "<assemblyname>" at compile time, or that all the satellite assemblies required are loadable and fully signed.

     

    This was quick to resolve- when Dotfuscator renames everything it renames all the resources- and if you are calling those resources by name via a string in a get function they wont be found.

     

    To resolve that it was a simple rule under the naming exclusions, as described by the suppliers site (you need to register to get access, but its available with the community edition)

     

    It was a simple case of putting a filter that caused certain types to not be renamed- putting this text

     

        .*[\.]Properties[\.]Resources$" regex="true"

     

    on the Rename tab, Exclude sub tab, after adding a type-  it goes in the Name field for the type.

     

    This resulted in a wonderfully renamed assembly- nothing is unreadable, but it sure makes it hard.

    Thursday, May 15, 2008 9:27 PM

All replies

  • You will need to tell to the obfuscator to leave alone the types you would like to use in other assemblies. I am assuming that all public classes would be left alone normally. So try to check the obfuscated library in Reflector first and see if the class from the dll that you are using from your exe still has the unobfuscated name, if not you will need to change the obfuscation settings. If this does not help then paste here the error message you get when running your app with the obfuscated dll.

     

    Thanks,

    Krisztian

     

    Tuesday, May 13, 2008 8:22 PM
  • I think I'm experiencing the same (similar?) issue. 

     

    I'm working on an application that uses  Microsoft.Office.Interop.Excel

     

    I'm using the comunity edition of Dotfuscator  in Visual Studio Pro 2008

     

    The error I get at the very end of the Dotfuscator build is 

     

    Creating PE file
    Could not create output file, error code=0x8013141C

    ***** FAILURE *****

     

     

    It seems the error is "Strong name key container not found ..." (based on a google search)

    Under the "Rename" tab in dotfuscator I checked the Microsoft.Office.Interop.Excel box to exclude it, but still get this error.

     

    I do not think I am signing my assemblies (properties of the projects all show no check in "sign the assembly")

     

     (and BTW I am using Clickonce and am signing the manifest)- although since this step does not yet seem to work, I havnt gotten to the point of publishing the new files.

     

     

     

    Wednesday, May 14, 2008 5:20 PM
  • ClickOnce and Dotfuscator does not play too wel. I mean that first you need to obfuscate and then preparing the ClickOnceDeployment. I managed to do this by writing an msbuild script by first calling dotfuscator and then calling the tools needed to prepare the obfuscated assemblies for clickonce deployment.

     

     

     

    Wednesday, May 14, 2008 5:32 PM
  •  

    First, you will need to obfuscate and then prepare the clickonce deployment by using the command line tools. I tried this before and did not manage to do it from the IDE. I ended up writing an msbuild script to automate this, so I do not have to do this by hand all the time.
    Wednesday, May 14, 2008 5:35 PM
  •  

    OK.  That will be another learning curve for me- but thanks for the advice.

     

    But back to the obfuscation- I have no issue obfuscating a "hello world" app- the issue appears to be around the Interop module.

     

    Looking throught the build- I've found this warning as well;

     

    WARNING: An assembly name (Microsoft.Office.Interop.Excel) is inconsistent with its prime module name (Excel.dll).  Dotfuscator uses the input file name when writing the output module.

     

    Is this inconsistancy in the name perhaps related to the error?

    Wednesday, May 14, 2008 6:00 PM
  • Well, I sorted out my issue- I'll post what I found here in case someone finds this thread via a search and has a similar problem.

     

    My first mistake- no point in obsfucating the Microsoft.Office.Interop.Excel assembly at all- its Microsofts and not mine, so none of my secrets are in there anyway- as long as the .dll is in the same directory as the other assemblies it will work fine.

     

    Once I did this my assemblies obsfucated without any issue, but when I ran the application I got a new error;

     

    Could not find any resources appropriate for the specified culture or the neutral culture. Make sure "<assemblyname>.Properties.Resources.resources" was correctly embedded or linked into assembly "<assemblyname>" at compile time, or that all the satellite assemblies required are loadable and fully signed.

     

    This was quick to resolve- when Dotfuscator renames everything it renames all the resources- and if you are calling those resources by name via a string in a get function they wont be found.

     

    To resolve that it was a simple rule under the naming exclusions, as described by the suppliers site (you need to register to get access, but its available with the community edition)

     

    It was a simple case of putting a filter that caused certain types to not be renamed- putting this text

     

        .*[\.]Properties[\.]Resources$" regex="true"

     

    on the Rename tab, Exclude sub tab, after adding a type-  it goes in the Name field for the type.

     

    This resulted in a wonderfully renamed assembly- nothing is unreadable, but it sure makes it hard.

    Thursday, May 15, 2008 9:27 PM