Home Random Page


CATEGORIES:

BiologyChemistryConstructionCultureEcologyEconomyElectronicsFinanceGeographyHistoryInformaticsLawMathematicsMechanicsMedicineOtherPedagogyPhilosophyPhysicsPolicyPsychologySociologySportTourism






Nbsp;   Culture

Like version numbers, assemblies also have a culture as part of their identity. For example, I could have an assembly that is strictly for German, another assembly for Swiss German, another assembly for US English, and so on. Cultures are identified via a string that contains a primary and a secondary tag (as described in RFC 1766). Table 2-6 shows some examples.

 

TABLE 2-6Examples of Assembly Culture Tags

 

Primary Tag Secondary Tag Culture
De (none) German
De AT Austrian German
De CH Swiss German
En (none) English
En GB British English
En US US English

 

In general, if you create an assembly that contains code, you don’t assign a culture to it. This is because code doesn’t usually have any culture-specific assumptions built into it. An assembly that isn’t assigned a culture is referred to as being culture neutral.

If you’re designing an application that has some culture-specific resources to it, Microsoft highly recommends that you create one assembly that contains your code and your application’s default (or fallback) resources. When building this assembly, don’t specify a culture. This is the assembly that other assemblies will reference when they create and manipulate types it publicly exposes.

Now you can create one or more separate assemblies that contain only culture-specific resources— no code at all. Assemblies that are marked with a culture are called satellite assemblies. For these satellite assemblies, assign a culture that accurately reflects the culture of the resources placed in the assembly. You should create one satellite assembly for each culture you intend to support.


You’ll usually use the AL.exe tool to build a satellite assembly. You won’t use a compiler because the satellite assembly should have no code contained within it. When using AL.exe, you specify the desired culture by using the /c[ulture]:text switch, where text is a string such as “en-US,” repre- senting US English. When you deploy a satellite assembly, you should place it in a subdirectory whose name matches the culture text. For example, if the application’s base directory is C:\MyApp, the US English satellite assembly should be placed in the C:\MyApp\en-US subdirectory. At run time, you ac- cess a satellite assembly’s resources by using the System.Resources.ResourceManager class.

       
   
 
 

 

Normally, you shouldn’t build an assembly that references a satellite assembly. In other words, an assembly’s AssemblyRef entries should all refer to culture-neutral assemblies. If you want to access types or members contained in a satellite assembly, you should use reflection techniques as discussed in Chapter 23, “Assembly Loading and Reflection.”

 

 

 
 

Simple Application Deployment (Privately Deployed Assemblies)

Throughout this chapter, I’ve explained how you build modules and how you combine those modules into an assembly. At this point, I’m ready to explain how to package and deploy all of the assemblies so that users can run the application.



Windows Store apps have very strict rules about packaging assemblies, and Visual Studio will pack- age all of an application’s required assemblies together into a single .appx file, which is either uploaded to the Windows Store or can be side-loaded onto a machine. When a user installs an .appx file, all

the assemblies it contains are placed in a directory where the CLR will load them and Windows adds an application tile to the user's Start screen. If other users install the same .appx file, the previously installed assemblies are used and the new user simply gets a tile added to their Start screen. When a user uninstalls a Windows Store app, the system removes the tile from the user's Start screen. If no

other users have the app installed, then Windows destroys the directory along with all the assemblies. Note that different users can install different versions of the same Windows Store app. To accom- modate this, Windows installs the assemblies into different directories so that multiple versions of a single app can reside on a single machine simultaneously.

For desktop (non-Windows Store) applications, assemblies don’t dictate or require any special means of packaging. The easiest way to package a set of assemblies is simply to copy all of the files directly. For example, you could put all of the assembly files on a CD-ROM and ship it to the user


with a batch file setup program that just copies the files from the CD to a directory on the user’s hard drive. Because the assemblies include all of the dependent assembly references and types, the user can just run the application and the runtime will look for referenced assemblies in the application’s directory. No modifications to the registry are necessary for the application to run. To uninstall the application, just delete all the files—that’s it!

Of course, you can package and install the assembly files by using other mechanisms, such as .cab files (typically used for Internet download scenarios to compress files and reduce download times). You can also package the assembly files into an MSI file for use by the Windows Installer service (MSIExec.exe). Using MSI files allows assemblies to be installed on demand the first time the CLR attempts to load the assembly. This feature isn’t new to MSI; it can perform the same demand-load functionality for unmanaged EXE and DLL files as well.

       
   
 
 

 

Of course, Visual Studio has a built-in mechanism that you can use to publish an application by dis- playing a project’s Properties pages and clicking the Publish tab. You can use the options available on the Publish tab to cause Visual Studio to produce an MSI file and copy the resulting MSI file to a web- site, FTP server, or file path. The MSI file can also install any prerequisite components such as the .NET Framework or Microsoft SQL Server Express Edition. Finally, the application can automatically check for updates and install them on the user’s machine by taking advantage of ClickOnce technology.

Assemblies deployed to the same directory as the application are called privately deployed assem- blies because the assembly files aren’t shared with any other application (unless the other application is also deployed to the same directory). Privately deployed assemblies are a big win for developers, end users, and administrators because they can simply be copied to an application’s base directory, and the CLR will load them and execute the code in them. In addition, an application can be uninstalled by simply deleting the assemblies in its directory. This allows simple backup and restore as well.

This simple install/move/uninstall scenario is possible because each assembly has metadata indi- cating which referenced assembly should be loaded; no registry settings are required. In addition, the referencing assembly scopes every type. This means that an application always binds to the same type it was built and tested with; the CLR can’t load a different assembly that just happens to provide a type with the same name. This is different from COM, in which types are recorded in the registry, making them available to any application running on the machine.

In Chapter 3, I’ll discuss how to deploy shared assemblies that are accessible by multiple applications.


 
 

Simple Administrative Control (Configuration)

The user or the administrator can best determine some aspects of an application’s execution. For example, an administrator might decide to move an assembly’s files on the user’s hard disk or to over- ride information contained in the assembly’s manifest. Other scenarios also exist related to versioning; I’ll talk about some of these in Chapter 3.

To allow administrative control over an application, a configuration file can be placed in the ap- plication’s directory. An application’s publisher can create and package this file. The setup program would then install this configuration file in the application’s base directory. In addition, the machine’s administrator or an end user could create or modify this file. The CLR interprets the content of this file to alter its policies for locating and loading assembly files.

These configuration files contain Extensible Markup Language (XML) and can be associated with an application or with the machine. Using a separate file (versus registry settings) allows the file to be easily backed up and also allows the administrator to copy the application to another machine—just copy the necessary files and the administrative policy is copied too.

In Chapter 3, we’ll explore this configuration file in more detail. But I want to give you a taste of it now. Let’s say that the publisher of an application wants its application deployed with the MultiFile- Library assembly files in a different directory than the application’s assembly file. The desired direc- tory structure looks like the following.

 

AppDir directory (contains the application’s assembly files) Program.exe

Program.exe.config (discussed below)

 

AuxFiles subdirectory (contains MultiFileLibrary’s assembly files) MultiFileLibrary.dll

FUT.netmodule RUT.netmodule

 

Because the MultiFileLibrary files are no longer in the application’s base directory, the CLR won’t be able to locate and load these files; running the application will cause a System.IO.FileNot­ FoundException exception to be thrown. To fix this, the publisher creates an XML configuration file and deploys it to the application’s base directory. The name of this file must be the name of the application’s main assembly file with a .config extension: Program.exe.config, for this example. The configuration file should look like the following.

 

<configuration>

<runtime>

<assemblyBinding xmlns="urn:schemas­microsoft­com:asm.v1">

<probing privatePath="AuxFiles" />

</assemblyBinding>

</runtime>

</configuration>


Whenever the CLR attempts to locate an assembly file, it always looks in the application’s directory first, and if it can’t find the file there, it looks in the AuxFiles subdirectory. You can specify multiple semicolon-delimited paths for the probing element’s privatePath attribute. Each path is considered relative to the application’s base directory. You can’t specify an absolute or a relative path identify- ing a directory that is outside of the application’s base directory. The idea is that an application can control its directory and its subdirectories but has no control over other directories.

 

 

Probing for Assembly Files

When the CLR needs to locate an assembly, it scans several subdirectories. Here is the order in which directories are probed for a culture-neutral assembly (where firstPrivatePath and secondPrivatePath are specified via the config file’s privatePath attribute).

AppDir\AsmName.dll AppDir\AsmName\AsmName.dll AppDir\firstPrivatePath\AsmName.dll AppDir\firstPrivatePath\AsmName\AsmName.dll AppDir\secondPrivatePath\AsmName.dll AppDir\secondPrivatePath\AsmName\AsmName.dll

...

 

In this example, no configuration file would be needed if the MultiFileLibrary assembly files were deployed to a subdirectory called MultiFileLibrary, because the CLR would automatically scan for a subdirectory whose name matches the name of the assembly being searched for.

If the assembly can’t be found in any of the preceding subdirectories, the CLR starts all over, using an .exe extension instead of a .dll extension. If the assembly still can’t be found, a File­ NotFoundException is thrown.

For satellite assemblies, similar rules are followed except that the assembly is expected to be in a subdirectory, whose name matches the culture, of the application’s base directory. For example, if AsmName.dll has a culture of “en-US” applied to it, the following directories are probed.

C:\AppDir\en­US\AsmName.dll C:\AppDir\en­US\AsmName\AsmName.dll C:\AppDir\firstPrivatePath\en­US\AsmName.dll C:\AppDir\firstPrivatePath\en­US\AsmName\AsmName.dll C:\AppDir\secondPrivatePath\en­US\AsmName.dll C:\AppDir\secondPrivatePath\en­US\AsmName\AsmName.dll

 

C:\AppDir\en­US\AsmName.exe C:\AppDir\en­US\AsmName\AsmName.exe C:\AppDir\firstPrivatePath\en­US\AsmName.exe C:\AppDir\firstPrivatePath\en­US\AsmName\AsmName.exe C:\AppDir\secondPrivatePath\en­US\AsmName.exe C:\AppDir\secondPrivatePath\en­US\AsmName\AsmName.exe


 

The name and location of this XML configuration file is different depending on the application type:

 

■ For executable applications (EXEs), the configuration file must be in the application’s base directory, and it must be the name of the EXE file with “.config” appended to it.

■ For Microsoft ASP.NET Web Form applications, the file must be in the Web application’s virtual root directory and is always named Web.config. In addition, subdirectories can also contain their own Web.config file, and the configuration settings are inherited. For example, a Web application located at http://Wintellect.com/Training would use the settings in the Web.config files contained in the virtual root directory and in its Training subdirectory.

As mentioned at the beginning of this section, configuration settings apply to a particular applica- tion and to the machine. When you install the .NET Framework, it creates a Machine.config file. There is one Machine.config file per version of the CLR you have installed on the machine.

The Machine.config file is located in the following directory:

 

%SystemRoot%\Microsoft.NET\Framework\version\CONFIG

Of course, %SystemRoot% identifies your Windows directory (usually C:\WINDOWS), and version is

a version number identifying a specific version of the .NET Framework (something like v4.0.#####).

 

Settings in the Machine.config file represent default settings that affect all applications run- ning on the machine. An administrator can create a machine-wide policy by modifying the single Machine.config file. However, administrators and users should avoid modifying this file because it

contains many settings related to various things, making it much more difficult to navigate. Plus, you want the application’s settings to be backed up and restored, and keeping an application’s settings in the application-specific configuration file enables this.


C HA P T E R 3


Date: 2016-03-03; view: 593


<== previous page | next page ==>
Nbsp;   Assembly Version Resource Information | Building an Assembly That References a Strongly
doclecture.net - lectures - 2014-2024 year. Copyright infringement or personal data (0.011 sec.)