Comments
3 comments
-
I have solved my own problem but it does raise another question. The problem with the event log security was because the service did not have admin rights to create the event log source and the reason why it was creating an event log entry because it had escalated an error that it could not report on regarding Linq-to-SQL error.
So my problem was Linq-to-SQL which I have now solved by excluding the data objects from obfuscation but because these objects are created by a designer rather than code, how can I decorate the classes with the DoNotObfuscate attribute and is it possible to change the Linq-to-SQL templates so that they are always decorated? -
how can I decorate the classes with the DoNotObfuscate attribute and is it possible to change the Linq-to-SQL templates so that they are always decorated?
I think you'll need to do this from the GUI. When you select an assembly to be obfuscated (or pruned) you get the option to Exclude any namespace, class, method or field.
Can you please try this and see how it goes?[/quote] -
I am already doing this as this is how I discovered to solution to my problem.
What I want to do is to decorate the classes in code so that I do not have to go into the SA GUI to exclude the classes. As the code is generated by a designer in VS2010, I wanted to know how to decorate them without losing the information if the designer rebuilds the classes.
Ideally, I want to amend the VS2010 templates so that all Linq-to-SQL code generated by VS is automatically decorated with the necessary information to prevent it from being obfuscated
Add comment
Please sign in to leave a comment.
I have checked that all the service contract interfaces and classes are not obfuscated but it would appear that that is what SA does anyway.
I am only doing obfuscation with none of the other fancy SA tricks.
Any ideas why it might be going wrong?