There are a number of ways to sign an assembly with a strong name:
- By using the Signing tab in a project’s Properties dialog box in Visual Studio. This is the easiest and most convenient way to sign an assembly with a strong name.
- By using the Assembly Linker (Al.exe) to link a .NET Framework code module (a .netmodule file) with a key file.
- By using assembly attributes to insert the strong name information into your code. You can use either the AssemblyKeyFileAttribute or the AssemblyKeyNameAttribute attribute, depending on where the key file to be used is located.
- By using compiler options.
You must have a cryptographic key pair to sign an assembly with a strong name.
Strong name signatures help prevent malicious parties from tampering with an assembly and then re-signing the assembly with the original signer’s key. However, strong name keys don’t contain any reliable information about the publisher, nor do they contain a certificate hierarchy. A strong name signature does not guarantee the trustworthiness of the person who signed the assembly or indicate whether that person was a legitimate owner of the key; it indicates only that the owner of the key signed the assembly. Therefore, Microsoft do not recommend using a strong name signature as a security validator for trusting third-party code. Microsoft Authenticode is the recommended way to authenticate code.
To disable the strong-name bypass feature for a single application
Assemblies placed in the global assembly cache must have the same assembly name and file name (not including the file name extension). For example, an assembly with the assembly name of myAssembly must have a file name of either myAssembly.exe or myAssembly.dll.
ildasm sample usage
The .NET Framework features two serializing technologies:
- Binary serialization preserves type fidelity, which is useful for preserving the state of an object between different invocations of an application. For example, you can share an object between different applications by serializing it to the Clipboard. You can serialize an object to a stream, to a disk, to memory, over the network, and so forth. Remoting uses serialization to pass objects “by value” from one computer or application domain to another.
- XML serialization serializes only public properties and fields and does not preserve type fidelity. This is useful when you want to provide or consume data without restricting the application that uses the data. Because XML is an open standard, it is an attractive choice for sharing data across the Web. SOAP is likewise an open standard, which makes it an attractive choice.
Why would you want to use serialization?
The two most important reasons are to persist the state of an object to a storage medium so an exact copy can be re-created at a later stage, and to send the object by value from one application domain to another.
This example uses a binary formatter to do the serialization.
Restoring the object back to its former state
It is important to note that the Serializable attribute cannot be inherited. If you derive a new class from MyObject, the new class must be marked with the attribute as well, or it cannot be serialized.
A class often contains fields that should not be serialized.
DO think about serialization when you design new types. Serialization is an important design consideration for any type, because programs might need to persist or transmit instances of the type.
XML serialization can also be used to serialize objects into XML streams that conform to the SOAP specification. SOAP is a protocol based on XML, designed specifically to transport procedure calls using XML.
XML serialization does not convert methods, indexers, private fields, or read-only properties (except read-only collections). To serialize all an object’s fields and properties, both public and private, use the DataContractSerializer instead of XML serialization.
The process for overriding XML serialization of objects as SOAP messages is similar to the process for overriding standard XML serialization.
The following command creates an assembly named Data.XmlSerializers.dll for serializing all the types contained in the assembly named Data.dll.
The following command generates XML schemas for all types in the assembly myAssembly.dll and saves them as schema0.xsd in the current directory.
You deploy localized app resources in satellite assemblies. A satellite assembly contains the resources of a single culture; it does not contain any app code. In the satellite assembly deployment model, you create an app with one default assembly (which is typically the main assembly) and one satellite assembly for each culture that the app supports. Because the satellite assemblies are not part of the main assembly, you can easily replace or update resources corresponding to a specific culture without replacing the app’s main assembly.
The .NET Framework offers five ways to create resources files:
- Create a text file that contains string resources. You can use Resource File Generator (Resgen.exe) to convert the text file into a binary resource (.resources) file. You can embed it in a satellite assembly by using Assembly Linker (Al.exe).
- Create an XML resource (.resx) file that contains string, image, or object data. You can use Resource File Generator (Resgen.exe) to convert the .resx file into a binary resource (.resources) file.
- Create an XML resource (.resx) file programmatically by using types in the System.Resources namespace.
- Create a binary resource (.resources) file programmatically.
- Use Visual Studio to create a resource file and include it in your project.
You should save resources in text file format by using UTF-8 encoding or UTF-16 encoding in either little-endian or big-endian byte order. However, Resource File Generator (Resgen.exe), which converts a .txt file to a .resources file, treats files as UTF-8 by default.
If you are using C#, and the source code file is named Greeting.cs, the following command creates an executable file that includes the embedded .resources file:
csc greeting.cs /resource:GreetingResources.resources
If you are adding localized resources, you should give them the same root file name as the main resource file, and you should also designate their culture in the file name. For example, if you add a resource file named Resources.resx, you might also create resource files named Resources.en-US.resx and Resources.fr-FR.resx to hold localized resources for the English (United States) and French (France) cultures, respectively.
You should also designate your application’s default culture. This is the culture whose resources are used if no localized resources for a particular culture can be found. To specify the default culture, in Solution Explorer in Visual Studio, right-click the project name, point to Application, click Assembly Information, and select the appropriate language/culture in the Neutral language list.
At compile time, Visual Studio first converts the .resx files in a project to binary resource (.resources) files and stores them in a subdirectory of the project’s obj directory.
The following example creates a .resx file named CarResources.resx
The default culture is the fallback culture for the application; it is used when no localized resources are available.
The hub-and-spoke model requires that you place resources in specific locations so that they can be easily located and used. If you do not compile and name resources as expected, or if you do not place them in the correct locations, the common language run-time will not be able to locate them and will use the resources of the default culture instead. The .NET Framework Resource Manager, represented by a ResourceManager object, is used to automatically access localized resources. The Resource Manager requires the following:
- A single satellite assembly must include all the resources for a particular culture. In other words, you should compile multiple .txt or .resx files into a single binary .resources file.
- There must be a separate sub-directory in the application directory for each localized culture that stores that culture’s resources. The sub-directory name must be the same as the culture name.
- The satellite assembly must have the same name as the application, and must use the file name extension “.resources.dll“. For example, if an application is named Example.exe, the name of each satellite assembly should be Example.resources.dll. Note that the satellite assembly name does not indicate the culture of its resource files. However, the satellite assembly appears in a directory that does specify the culture.
- Information about the culture of the satellite assembly must be included in the assembly’s metadata. To store the culture name in the satellite assembly’s metadata, you specify the /culture option when you use Assembly Linker to embed resources in the satellite assembly.
The following illustration shows a sample directory structure and location requirements for applications:
Use Resgen.exe to compile each text or XML resource file to a binary .resources file.