Obfuscating ASP.Net dll breaks web application

Question

I wouldn\'t usually bother to obfuscate a web application DLL but right now I have to share some server space with someone who might have a conflict of interest and might be

Answer 1

I have never used the Dotfuscator community edition, but try to see if you can rename only the Private types, variables. That should make it more difficult to see. IMO most of the Obfuscators have issues, and when you find a bug they want you to send your code so they can fix the problem. I have found issues with most of commercial versions, but maybe they have gotten better in the last couple of years...

Answer 2

You're close to the solution. In your situation I don't know in which context 'Browse' is used, but are you referencing it somewhere as a string?

There are some things which simply can't be obfuscated when you're using it in a certain way.

For example, when you have custom objects which is bound to a control. Those properties which you've specified as a displaymember of valuemember cannot be obfuscated. This is because the properties are defined as a string. So at designtime there's no connection between the control and the actual property, but at runtime there is. I don't know how to explain it better; but here's some code:

// custom object
Public Class MyObject
{
    string Test() { get; set; }
}

// here the object is bound to a combobox

MyCombo.ValueMember = "Test";  // The Test property cannot be obfuscated because of this 'indirect' reference.
MyCombo.DisplayMember = "Test";
MyCombo.DataSource = lstListOfMyObjects;

Hopefully it addresses your problem. If not, let me know.

Answer 3

For asp.net I don't know of a quick way out. The quickest way I've found is Secure Team's code protection functionality. It leaves the interface but encrypts all the il and makes it hard for someone to reverse it.

Asp.net is tricky due to all the dynamic resolving and reflection used once you start changing the names of things it becomes fragile and in the need of a whole other round of testing to make sure everything loads and nothing breaks.

Answer 4

We needed something like that and tried bitHelmet. It provides predefined exclusions for certain objects which are known to be accessed by name by the framework, for instance Web.UI.Page Descendants. It works perfectly with web aplications.