Daily .Net Feeds - ASP.Net 2.0 - Advanced - Day 13
Hi Everyone,
Welcome back!!!
As mentioned earlier, today we will be wrapping up with the discussion about the ASP.Net 2.0 reserved folders. Let's take a look and understand the other ASP.Net special folders that we didn't consider yesterday.
The App_Data Folder:
The App_Data folder is expected to contain data stores local to the application. It typically contains data stores in the form of files such as Microsoft Access or Microsoft SQL Server Express databases, XML files, text files, and whatever else your application can support. The contents of the folder are not processed by ASP.NET. The folder is the default location where ASP.NET providers store their data.
Note: The default ASP.NET account is granted full permissions on the folder. If you happen to change the ASP.NET account, make sure that the new account is granted read/write permissions on the folder.
The App_GlobalResources Folder:
Let's quickly understand what are resources? Just like other applications, an ASP.NET application can, and often should, use resources. Resources are an effective way to isolate localizable portions of the application's user interface. In general, a resource is non-executable text associated with the program. Typical resources are images, icons, text, and auxiliary files, but any serializable object can be considered a resource. Application resources are stored outside of the application so that they can be recompiled and replaced without affecting and recompiling the application itself.
In ASP.NET 1.x, compiling resources inside an assembly (or satellite assemblies), although done by Visual Studio but was still a rather transparent task and more often developers need to be aware of several minute details to manage these resources. Basically, an ASP.NET application needs to have a primary assembly to contain the default or neutral resources for the application. In addition, we deploy a number of satellite assemblies, each containing localized resources for a particular culture we want to support. We have to manually compile XML-based resource files (those with a .resx extension) into a .resources binary file. These files can be either embedded in a .NET executable or compiled into satellite assemblies. We use the Resource File Generator (resgen.exe) utility to convert text and XML-based resource files into .resources files. The resource file names follow the naming convention baseName.cultureName.resources. Usually, the base name is the name of the application. A typical command line could be as follows:
resgen.exe MyAppName.resx MyAppName.it.resources |
Once created, the .resources file should be embedded into an assembly, or it can even be used as is as a resource container. To embed the resource file into a satellite assembly, we use the Assembly Linker tool (al.exe). On the command line, we indicate the culture (it in our example, which represents Italian) and the name of the assembly.
al /out:MyAppName.resources.dll /c:it /embed:MyAppName.it.resources |
After we compile our satellite assemblies, they will all have the same name. We deploy them in distinct subdirectories, each named after the culture. Fortunately, with ASP.NET 2.0, gone are the days of satellite assemblies. More precisely, satellite assemblies are still there, but they are a thing of the past for developers thanks to the App_GlobalResources reserved folder. Any .resx files located within the folder are automatically compiled to satellite assemblies. The name of the .resx file contains culture information to help the ASP.NET runtime environment with the assembly generation. The following files—resources.resx, resources.it.resx, resources.fr.resx—generate the neutral assembly and satellite assemblies for the Italian and French cultures respectively. The neutral assembly is the default culture resource used by the application if no specific culture is called for. Resource files located in the App_GlobalResources folder are global to the application and can be referenced from within any page. Resource reading results are greatly simplified as compared to ASP.NET 1.x:
<asp:Label ID="Label1" Runat="server" Text="<%$ Resources:ResxFile, MyResName %>" /> |
We can now bind global resources declaratively using the newest $-expression named Resources. (As already mentioned in one of the session, we'll cover $-expressions in more detail during one of the oncoming sessions) For now, the expression takes two parameters—the name of the .resx source file (no extension), and the name of the resource to retrieve. To access resources programmatically, you resort to the following code:
HttpContext.GetGlobalResourceObject(resxFile, MyResName); |
Both parameters are strings and have the same role as the parameters in the $-expression. Moreover, the implementation of the $- expression Resources uses GetGlobalResourceObject internally.
The App_LocalResources Folder:
App_LocalResources is a subdirectory located below the folder that contains some ASP.NET pages. The folder can be filled with .resx files named after the pages located one level upper in the hierarchy. Assuming that the parent folder contains test.aspx, here are few feasible resource files you can find in the App_LocalResources folder: test.aspx.resx, test.aspx.it.resx, test.aspx.fr.resx. Obviously, resources stored in the aforementioned files have an effect only on test.aspx and are visible (and can be used) only from within the linked page.
How do you access a page-specific resource? For programmatic access, you use the following code:
HttpContext.GetLocalResourceObject("/ProAspNet20/ResPage.aspx", "PageResource1.Title"); |
The first parameter indicates the virtual path of the page; the second parameter is the resource name. For declarative access, you use the meta:ResourceKey attribute. Here's an example:
<asp:Button ID="Button1" Runat="server" meta:resourcekey="ButtonResource1" /> |
The declaration associates a unique resource key with the specified button instance. The local .resx file will contain entries of the form prefix.name, where prefix is a resource key and name is a property name on the bound control. To give the button a localizable caption (the Text property), you simply create a ButtonResource1.Text entry in the resource file.
Resource files found in both the local and global resource folders are compiled to create classes for satellite assemblies. The net effect is that developers create .resx files and test the page. The ASP.NET compilation machinery does the rest.
The App_Themes Folder:
The App_Themes folder defines themes for ASP.NET controls. Each theme takes a folder under App_Themes. Defined, a theme is a collection of files with style information. Compiled, the contents of the files in a theme folder generate a class that, invoked by the page, programmatically sets styles on themed controls.
The App_Themes folder lists themes local to the application. An application can also inherit global themes defined in the following folder:
%WINDOWS%\Microsoft.NET\Framework\[version]\ASP.NETClientFiles\Themes |
From the compilation perspective, there's no difference between global and local themes. If a theme with a given name exists both locally to the application and globally to the server machine, the local theme takes precedence.
The App_WebReferences Folder:
In Visual Studio .NET 2003, an ASP.NET application that requires access to a Web service will obtain the corresponding .wsdl file through the Add Web Reference dialog box. The Web Service Description Language (WSDL) document for the Web service is not sufficient to make the Web service usable from the page. An ASP.NET page is ultimately a managed class and needs another managed class to talk to. So the Web service is wrapped by a proxy class. The proxy class is created by Visual Studio using the services of a command-line tool—wsdl.exe. The proxy class contains as many methods as there are Web methods on the Web service, and it incorporates any custom data type defined by the public interface of the Web service.
There are no significant costs for developers in this operation. However, developers are clearly dependent on Visual Studio to generate the proxy class. Wouldn't it be easier and simpler if you could just drop the .wsdl file somewhere in the application's tree and have ASP.NET deal with the rest? This is just what the App_WebReferences folder is for.
It recognizes .wsdl files describing bound Web services, and it generates runtime proxy classes so that ASP.NET pages can place calls to the Web service in a type-safe manner. The App_WebReferences folder can contain subfolders. The name of the subfolder drives the namespace of the resulting proxy class, whereas the WSDL file defines the classname. For example, the samples.wsdl file in MyApp subfolder will originate a proxy class named MyApp.Samples. The dynamically created assembly is named App_WebReferences.xxx.dll, where xxx is a random sequence of characters.
That's it for today. Thanks for joining!!! See you tomorrow. Tomorrow we will start discussing about Asp.Net 2.0 build providers.
Thanks,
Sukesh Khare
Coordinator Daily .Net Feed Program
Comments
Anonymous
August 06, 2007
Very informative. I am really impressed.Anonymous
March 12, 2008
Truly informative.... Good & ThanksAnonymous
December 20, 2009
I am really impressed.Truly informativeAnonymous
February 25, 2010
I really liked it that it generates runtime proxy classes so that ASP.NET pages can place calls to the Web service in a type-safe manner.Anonymous
July 12, 2010
The comment has been removedAnonymous
April 11, 2011
its awesome informative really impressed thanksAnonymous
March 07, 2012
great site, i like it http://www.aghatech.com/