ASP. NET foreground cannot access background internal type variables

This articleArticleIs the front-end of the previous Article ASP. NETCodeAnalysis and answer to a related question in the summary of BIND background variables.

As mentioned in the previous article, in the Code hiding mode, the foreground aspx file cannot access the background variables modified by its internal, but can only access values of the public or protected type. Obviously, from the perspective of the problem itself, it must be the Aspx. CS file corresponding to the front-end aspx and the background. After compilationProgramResult from a set (this can be learned by analyzing the definition of the internal modifier ). To solve this problem, we need to see if they are actually in different programming sets. This can be achieved through getexecutingassembly. The following code is used:

Front-end code:

 <  Html  Xmlns  = "Http://www.w3.org/1999/xhtml"> <  Head  > <  Title  > </  Title > </  Head  > <  Body  > <  Form  ID  = "Form1"  Runat  = "Server"> <  Span  > Background assembly: <%  = Getvariablestr %>  </  Span > <  BR  /> <  Span  > Foreground assembly: <%  = System. reflection. Assembly . Getexecutingassembly (). codebase %>  </  Span  > </  Form  > </  Body  > </ Html  > 

Background code:

 
Public partial classWebform2: System. Web. UI.Page{Public StringGetvariablestr;Protected voidPage_load (ObjectSender,EventargsE ){If(! Ispostback) {getvariablestr = system. reflection.Assembly. Getexecutingassembly (). codebase ;}}}
 

The result is(The result varies depending on the project location and related settings)

Background Assembly: file: // D:/project code/mytestproject/mytestwebproject/bin/mytestwebproject. dll
Foreground Assembly: file: // C:/Windows/Microsoft. NET/framework/v4.0.30319/Temporary ASP. NET files/mytestwebproject/4e3b6d4c/6fc8a242/app_web_czkfai3a.dll

It can be seen that the background code and the foreground code are located in different programming sets, and the two DLL files are viewed through reflector. The foreground code compilation generates a class, which inherits the class generated by the background code, therefore, the foreground code can access the background variables of the protected type, but internal is not accessible because they are not in the same assembly.

Note: This article is limited to Asp.net 2.0 and later compilation methods, because it is different from the previous Asp.net 1.1 compilation method, so the conclusions of each method may be different.

References:

(Conversion) in-depth analysis of ASP. NET compilation principles

The compilation model for ASP. NET 2.0 is not exactly what the MS says

Author: lerit Source: Artificial. http://www.cnblogs.com/lerit/archive/2010/10/25/1860433.html

This article analyzes and answers a related question in the previous article ASP. NET foreground code bind background variable method summary.

As mentioned in the previous article, in the Code hiding mode, the foreground aspx file cannot access the background variables modified by its internal, but can only access values of the public or protected type. Obviously, from the perspective of the problem itself, it must be the aspx corresponding to the foreground and background. CS files, which are generated in different sets of programs after compilation (this can be learned by analyzing the definition of the internal modifier ). To solve this problem, we need to see if they are actually in different programming sets. This can be achieved through getexecutingassembly. The following code is used:

Front-end code:

 <  Html  Xmlns  = "Http://www.w3.org/1999/xhtml"> <  Head  > <  Title  > </  Title  > </  Head  > < Body  > <  Form  ID  = "Form1"  Runat  = "Server"> <  Span  > Background assembly: <%  = Getvariablestr %>  </  Span  > <  BR  /> < Span  > Foreground assembly: <%  = System. reflection. Assembly . Getexecutingassembly (). codebase %>  </  Span  > </  Form  > </  Body  > </  Html  > 

Background code:

Public partial classWebform2: System. Web. UI.Page{Public StringGetvariablestr;Protected voidPage_load (ObjectSender,EventargsE ){If(! Ispostback) {getvariablestr = system. reflection.Assembly. Getexecutingassembly (). codebase ;}}}
 

The result is(The result varies depending on the project location and related settings)

Background Assembly: file: // D:/project code/mytestproject/mytestwebproject/bin/mytestwebproject. dll
Foreground Assembly: file: // C:/Windows/Microsoft. NET/framework/v4.0.30319/Temporary ASP. NET files/mytestwebproject/4e3b6d4c/6fc8a242/app_web_czkfai3a.dll

It can be seen that the background code and the foreground code are located in different programming sets, and the two DLL files are viewed through reflector. The foreground code compilation generates a class, which inherits the class generated by the background code, therefore, the foreground code can access the background variables of the protected type, but internal is not accessible because they are not in the same assembly.

Note: This article is limited to Asp.net 2.0 and later compilation methods, because it is different from the previous Asp.net 1.1 compilation method, so the conclusions of each method may be different.

References:

(Conversion) in-depth analysis of ASP. NET compilation principles

The compilation model for ASP. NET 2.0 is not exactly what the MS says