CSLA & Obfuscation

rrlanders2 posted on Wednesday, July 25, 2007

Apologies to all if this has been asked/answers/rehashed before.

I'm new to CSLA (starting with 2.1, and I have the book and I am actually reading it!).

My question is regarding obfuscation. Can the code I write using CSLA be obfuscated (like with the Dotfuscator product) ? We use that product for all of our .NET code we release. (I was not planning on obfuscating any of the csla dlls).

We have had some issues with classes in our code, and it seems to be with those involved with .NET's reflection - we never did pin down exactly what the cause was, we just did not obfuscate the class in question and everything worked (and of course due to time/schedule constraints we have never gone back to determine exactly what the issue was).

Thanks, Rod

RockfordLhotka replied on Wednesday, July 25, 2007

rrlanders2 replied on Wednesday, July 25, 2007

Rocky,

Thanks for the link to the thread.

In reading your response, you referenced "anywhere reflection is used to call method by name will fail".

The product I am using allows me to turn off renaming of objects (and their methods). The code in the methods is still obfuscated and that suffices (that is what we have done in past for an object in an exe that gave us a problem).  I have noticed that all the objects in our dlls still have the object/method names (it's only the exes that seem to have everything obfuscated). One thought - following your ProjectTracker code is to put all the business objects that inherit from CLSA into a seperate project/library/dll

Speculating here (and I will have to test this), if I were to disable renaming of all business objects I create (that inherit from CSLA), do you think CSLA would work ?

Alternatively - and maybe simplier -  putting these objects in a seperate DLL would suffice.

Your thoughts ?

Thanks, Rod

RockfordLhotka replied on Wednesday, July 25, 2007

The short of it is this: reflection calls use pre-determined method names. Obfuscators, by default, rename methods. The result is that the method name doesn't match the pre-determined name, so failure is the result.

If you can disable renaming of all CSLA subclass method/property names I would think that'd work.

Alternately, if you aren't obfuscating Csla.dll, you can probably just not allow renaming of your DataPortal_XYZ methods (if your tool allows per-method blocking). I think (from memory) that those are the only methods called via reflection by name in standard usage.

Of course if you use the DataMapper or ObjectAdapter then things are much harder, because they reflect against all your properties.

Also, you must NOT use the auto-detection of property names when calling CanReadProperty(), CanWriteProperty() and PropertyHasChanged(). You'll need to explicitly provide the "real" property name, or the validation/authorization rules won't hook up.

Hmm. But if you do that, the PropertyChanged event will fire with the "real" property name, rather than the "actual" name - so that could mess up data binding... That's an interesting puzzle, that might require changing CSLA .NET itself - probably to use the stack trace to find the "actual" name for the OnPropertyChanged() call, but to use the passed-in "real" name for the CheckRules() call.

rrlanders2 replied on Wednesday, July 25, 2007

Thanks for the thoughts & ideas.

I took the project tracker solution - cut it down to the library and the PTWIN executable (we are developing windows apps), built it and made sure it ran.

I the obfuscated it, built an install package, installed it, and of course it would not run.

I modified the obfuscation project properties for the library to "NOT rename" and "NOT Remove". I think the "Not Remove" referrs to removal of the ability of reflection to find private methods (private due to the Criteria class being private ?) - not quite sure on that reasoning. I am not obfuscating csla or any of it's dlls. Just the code in the PtTracker library and PtWin.

The program works. The only issue is I get MSDTC errors thrown when I try to save a new project and assign a resource at the same time (it works if I create and save the project and then go back and assign a resource - assume that is due to some sort of enterprise transation service/feature). I do get the same error with the unmodified PTTracker project, so I think it's something I don't have setup via Sql*Server Express - or something else, but probably not obfuscation (error is from System.Data.SqlClient.....).

If I'm wrong on the SqlClient error, please let me know...

I have an MSI and the project if you are interested.

Thanks, Rod

rrlanders2 replied on Wednesday, July 25, 2007

Update: The MSDTC issue was a configuration thing in Component Services. I found some instructions on the web.

Now the obfuscated version of the project works just fine - as well as the original code.

Rod

RockfordLhotka replied on Wednesday, July 25, 2007

William replied on Thursday, July 26, 2007