Cash
I am pretty sure you cannot use an obfuscator with CSLA. I know it has been mentioned in the past.
What I am unsure of is:
Is it only CSLA itself that cannot be obfuscated?
Or is my Business Object library also one of the things which cannot be obfuscated?
Or both?
I think it is both - but would like this clarified.
Joe
ajj,
Good point on the reflection issue; the more I hear the more I remember. Some commercial obfuscators allow you to make methods so their names won't be obfuscated. This would have to be done with the dataportal methods since their names are hard coded as strings in the dataportal itself. I think I may have even had a discussion with Rocky at the time of that being an advantage of using an interface for the dataportal methods. I'll have to look more for that paper I wrote on it but IIRC it could definitely be done with the correct tool in 1.5 and I can't think of anything in 2.x that would really have made that impossible.
Thanks,
Kevin
Cash,
I am 100% sure that obfuscation can be done without modifying the framework. IIRC this is what you need to do:
1) Mark all dataportal method names (DataPortal_Fetch, etc) as non obfuscated. This will allow the CSLA dataportal to find and create them with reflection. The fact that these are not obfuscated should not reveal anything about the proprietary business logic in your classes.
2) Make sure your criteria classes inherit from Criteriabase so the proper object is created by the data portal. I don't recall if this is strictly necessary but seems to be sticking around in my head as true.
3) If you want the public interface on your CSLA based DLLs to be obfuscated you need to use a obfuscation product that can obfuscate an entire solution as a unit. If you obfuscate on a project by project basis then you will need to not obfuscate the public interface so you can still use it in your calling projects. In that case only the implementation code inside the public methods would be obfuscated. This is nothing specific to CSLA but true of all projects you make with a publicly consumable interface.
Thats really all I remember. If there is something I forgot I'm sure someone else will chime in.
Thanks,
Kevin
Andy,
The solution thing was me but that's not really an issue here. You would only have issues with items such as MarkOld, MarkNew in BusinessBase if you actually obfuscated the CSLA DLLs themselves instead of just the proprietary DLLs that use CSLA. If you only obfuscate the DLLs that use CSLA then the inherited MarkNew and MarkOld methods wouldn't be renamed anymore than the ToString method from System.Object does.
The reason for obfuscation in a commercial product is to stop reverse engineering of your proprietary content. There is not proprietary content in the CSLA DLLs themselves so there would be no reason to obfuscate them. At least no more reason that you would want to obfuscate any of the .Net system DLLs. If you don't obfuscate the CSLA DLLs themselves then that problem vanishes.
The reason why you want an obfuscator that works on a solution is so that your projects that use those proprietary DLLs can actually be written/maintained if the DLL's public interfaces have been obfuscated as well as the implementation code.
Thanks,
Kevin
Rocky,
Exactly, I had mentioned that obfuscators allow you to mark up method signatures you choose not to be obfuscated and the dataportal methods would be prime candidates for this. The ability to have strongly typed dataportal methods based on the specific criteria classes is very cool and would be hard to loose.
Thanks,
Kevin
I had looked into this a few years ago with CSLA.Net 1.5. What you need is a tool (and there are a few out there) that can obfuscate a solution as a whole. That is, so every project in the solution is using and understands the replaced names. If you try and obfuscate each DLL individually you will run into trouble.
I just don't recall all of the issues at this point nor can I find the white paper I wrote about it for the client the explained the issues and had the results of my testing. I do recall that it could be done with the correct solution wide tool. For whatever reason I also thing that your criteria object might have to inherit from criteriaBase to pass in the proper (obfuscated) type to the constructor so the data portal creates the correct object type. We always used generated code so we did this anyway.
I wish I could remember more about it.
Thanks,
Kevin
Copyright (c) Marimer LLC