The following is an excerpt from the 'How To' protect a web application...

· Use Aspnet_Compiler to create pre-compiled code for the website(aspnet_compiler -v "/" -d -p "c:\\mywebsite" "c:\\mynewwebsite") · Open the dependent DLLs (not App_Web_xxx.dll) and create an SA project for each · Set up error reporting to report silently · Build the DLL into a new folder in a "bin" subfolder (c:\\mynewSAwebsite\\bin) · Open the main DLL in a new SmartAssembly project (App_Web_xxx.dll) · Set up error reporting as for the dependent DLLs, but do not merge or embed the dependencies. · Copy all of the files that are not DLLs from the original compiled website to the one you just created

My compiled output creates a dll for 'App_global.asax' as well as one for each page, each of which starts with 'App_Web_<pagename>xxx'. It also creates several dll's for themes which I'm not worried about as well as the main dll which is named '<MyWebSitesName>.dll'.

My confusion is that the directions state NOT to create SA projects for the 'App_Web_xxx' files which in my case would cover each of the individual pages. It then goes on to indicate that the main DLL is named 'App_web_xxx.dll' which it obviously isn't.

The final point confuses me more as it infers that the individual page dll's should not be copied to the new web directory.

I have sa built App_global.asax.dll as well as the <MyWebSitesName>.dll and the web site works fine.

Do the individual pages need building with sa projects or is it OK just to copy the original dll's and use them.

Sorry if there is ambiguity - I had to write some instructions for ASP .NET and I am not a developer, so I may have missed a trick that you would need to use to process a more "complicated" web application.

In my example, there was only one App_Web_<random>.dll file produced by aspnet_compiler. Since this contains the ASP namespace, I assumed this would be the "entry point" for the web application and there would only be one.

So the idea was to process all of the codebehind DLLs first, then the App_Web...dll.

My example also only produced one codebehind DLL for all pages (App_Code.dll).

If the behavior of aspnet_compiler has changed, we'll have to spend another day trying to reverse-engineer what the compiler is doing and write a new article because I can't say why you have all of these DLLs.

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.

SA can only obfuscate dotnet code. The aspx pages should only contain HTML... So you can't obfuscate an aspx page I am guessing?
fixednames makes the compiler produce a separate assembly for every page... if this means what it says then you can run SA on every DLL because an assembly by definition contains managed code.
I guess this should be okay...
Can you give it a try and if it doesn't work let me know - I'll have to put some lab time in my schedule to try to reproduce any problem you may have.

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 .

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.

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.

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.

OK, I will have to attempt to reproduce the problem because with this information, I am unable to determine the cause and this product was not tested against an ASP .NET web app with master pages.

This may take a day or two. Hopefully I will encounter the same problem.

Also, please ensure that it works before you process it with smartassembly. I am not entirely sure what the -fixednames option does and the documentation says something about it breaking batch compilation, but I don't understand at all what Microsoft are talking about with "batch compilation" as this aspnet_compiler is supposed to do all of the compilation before you deploy the website.

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.

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?

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.