Comments
Sort by recent activity
I originally meant error reporting but confused it with feature reporting. I've figured feature reporting out and error reporting either is or isn't is it 8) / comments
I originally meant error reporting but confused it with feature reporting. I've figured feature reporting out and error reporting either is or isn't is it 8)
Found it - it's Feature Usage BTW [image] / comments
Found it - it's Feature Usage BTW
First of all, I'm going to retry but this time keep the SA configuration to just obfuscation. It makes sense that error reporting for what is in fact the compiled html content won't work. It also seems all a bit superfluous as the end content can be viewed in the browser anyhow.
If I don't use -fixednames then each time the program is pre-compiled, the dll names change. I'm useless with regexes so I can't see how I can automate SA processing when the source file name changes all the time. / comments
First of all, I'm going to retry but this time keep the SA configuration to just obfuscation. It makes sense that error reporting for what is in fact the compiled html content won't work. It also s...
Brian Donahue wrote:
Oh, hold on...
The article doesn't mention needing a DLL for each page, just that you should process all of the DLLs... Does it work if you don't use -fixednames?
No but it's impossible to automate the process if you don't. / comments
Brian Donahue wrote:
Oh, hold on...
The article doesn't mention needing a DLL for each page, just that you should process all of the DLLs... Does it work if you don't use -fixednames?
No but i...
I have found that STEP 1 must be to run SA on the App_global.aspx.dll. The new SA protected DLL must then replace the original DLL and remain in the original directory.
After doing the above, I then ran SA on 3 more pages as well as the <WebsiteName>.dll. I did replace the dll's they produced and tested the website on each SA build/dll replacement without problem. I assume that providing the App_global.aspx.dll generated by SA is in the original directory before processing any more SA builds, then it won't matter in which order you SA protect the rest.
If I find any more problems I'll post them here. / comments
I have found that STEP 1 must be to run SA on the App_global.aspx.dll. The new SA protected DLL must then replace the original DLL and remain in the original directory.
After doing the above, I the...
Brian Donahue wrote:
SmartAssembly will change the accessibility of some methods from public/private to internal. That's probably what's happened - then applying the same logic to the Global assembly (which has the entry point and application-level event handlers) probably fixed that.
Glad you understand what happened but unfortunately I have run into more complications...
There are two 'page' dll's that throw the same error reported above no matter in what order I SA protect them. They are the App_Web_masterpage.master.xxxx.dll and the App_Web_default.aspx.xxxx.dll pages. Unfortunately they are the two most important.
Is there some way I can achieve my goal? / comments
Brian Donahue wrote:
SmartAssembly will change the accessibility of some methods from public/private to internal. That's probably what's happened - then applying the same logic to the Global ass...
To be clear, the above command line produces the following files for each page in the web application:
<pageName>.aspx.xxxxx.compiled
App_Web_<pageName>.aspx.xxxxx.dll
[the xxxxx is a hash code and is the same for all the files]
as well as:
App_global.asax.dll
<WebsiteName>.dll
It also will produce dll's for any other dependent dll's in the project.
The <pageName>.aspx.xxxxx.dll is the compiled web page only. That is, the code behind page (.cs) is not compiled into this dll. All the .cs files are compiled into one dll which is the <WebsiteName>.dll .
Using Visual Build, I use SA on the App.global.asax.dll followed by the individual web page dll's and finally the dependant dll's and the <WebsiteName>.dll .
Some of the pages can be viewed fine however others cannot and SA generates the following error reports. The stack trace reads:
System.TypeLoadException: Inheritance security rules violated while overriding member: 'SmartAssembly.SmartExceptionsCore.SmartStackFrame.GetObjectData(System.Runtime.Serialization.SerializationInfo, System.Runtime.Serialization.StreamingContext)'. Security accessibility of the overriding method must match the security accessibility of the method being overriden.
Notwithstanding the above, I have been successful in generating the individual page files on an ad-hoc basis and viewing them successfully. I will do some more testing however this is becoming very time consuming [image] . / comments
To be clear, the above command line produces the following files for each page in the web application:
<pageName>.aspx.xxxxx.compiled
App_Web_<pageName>.aspx.xxxxx.dll
[the xxxxx is a hash code and...
Here's my compiler command line: "%DOTNET_DIR%\aspnet_compiler.exe" -fixednames -f -p "%ProjectsDir%\<ProjectName>\Published" -v / "%ProjectsDir%\<ProjectName>\Compiled" -aptca -keyfile "%ProjectsDir%\<KeyDir>\Key.snk"
If I don't use the -fixednames argument, the compiler creates fewer dll's instead of one for each page. I used -fixednames because your article indicates I need to sa process each one and therefore -fixednames is essential.
I doubt whether the aspnet_compiler.exe behavour has changed.
The individual page dll's appear to contain the aspx page and not the code behind. It is of course the code behind I'm more worried about anyhow.
The question is, can SA obfuscate the individual aspx pages? It doesn't seem to be able to. / comments
Here's my compiler command line:"%DOTNET_DIR%\aspnet_compiler.exe" -fixednames -f -p "%ProjectsDir%\<ProjectName>\Published" -v / "%ProjectsDir%\<ProjectName>\Compiled" -aptca -keyfile ...
Just thought I would mention that I am experiencing the same thing here.
To get around the issue I [DoNotObfuscate] the XtraReport designer namespace for each report.
I'll create a small project in the next few days and let you have it if the OP didn't send you one. / comments
Just thought I would mention that I am experiencing the same thing here.
To get around the issue I [DoNotObfuscate] the XtraReport designer namespace for each report.
I'll create a small project in...
SA 6.6.4.95 had no problem exporting an XtraGrid to xls. DevExpress version was 11.2.11 . DevEx dll's were not embedded nor merged. / comments
SA 6.6.4.95 had no problem exporting an XtraGrid to xls. DevExpress version was 11.2.11 . DevEx dll's were not embedded nor merged.