Figure 15-26

Even though the classes are located in different assemblies, IntelliSense still finds them because all these classes are grouped within the same namespace. You can now use the classes as follows:

Learn2develop.net.Class1 c1 = new Learn2develop.net.Class1();

c1.DoSomething();

Learn2develop.net.Class2 c2 = new Learn2develop.net.Class2();

c2.DoSomething();

Learn2develop.net.Class3 c3 = new Learn2develop.net.Class3();

c3.DoSomething();

Learn2develop.net.Class4 c4 = new Learn2develop.net.Class4();

c4.DoSomething();

For Class5, you need to use the CoolLabs.net namespace. If you don't, IntelliSense will check against all the referenced assemblies and suggest an appropriate namespace (see Figure 15 -27).

Figure 15-27

You can use Class5 as follows:

CoolLabs.net.Class5 c5 = new CoolLabs.net.Class5();

c5.DoSomething();

Namespace Alias

There are times when you want to specify the fully qualified name of a class so that your code is easier to understand. For example, you usually import the namespace of a class and use the class like this:

using CoolLabs.net;

//...

Class5 c5 = Class5();

c5.DoSomething();

However, you might want to use the fully qualified name for Class5 to make it clear that Class5 belongs to the CoolLabs.net namespace. To do so, you can rewrite your code like this:

CoolLabs.net.Class5 c5 = new CoolLabs.net.Class5();

c5.DoSomething();

But the CoolLabs.net namespace is quite lengthy and may make your code look long and unwieldy. To simplify the coding, you can give an alias to the namespace, like this:

using cl = CoolLabs.net;

//...

cl.Class5 c5 = cl.Class5();

c5.DoSomething();

Then, instead of using the full namespace, you can simply refer to the CoolLabs.net namespace as cl.

To summarize, this example shows that:

□ Classes belonging to a specific namespace can be located in different assemblies.

□ An assembly can contain one or more namespaces.

□ Assemblies created using different languages are transparent to each other.

Private versus Shared Assemblies

So far, all the assemblies you have seen and created are all private assemblies — that is, they are used specifically by your application and nothing else. As private assemblies, they are stored in the same folder as your executable and that makes deployment very easy — there is no risk that someone else has another assembly that overwrites yours particular and thus breaks your application.

DLL Hell

If you programmed prior to the .NET era, you've no doubt heard of (maybe even experienced) the phrase DLL Hell. Suppose that you have installed an application on your customer's computer and everything works fine until one day your customer calls and says that your application has suddenly stopped working. Upon probing, you realize that the customer has just downloaded and installed a new application from another vendor. Your application stopped working because one of the libraries (DLLs) that you have been using in your application has been overwritten by the application from the other vendor. And because your application could no longer find the particular DLL that it needs, it ceases to work.

.NET eliminates this nightmare by ensuring that each application has its own copy of the libraries it needs.

But assemblies can also be shared — that is, used by more than one application running on the computer. Shared assemblies are useful if they provide generic functionalities needed by most applications. To prevent DLL Hell, Microsoft has taken special care to make sure that shared assemblies are well protected. First, all shared assemblies are stored in a special location known as the Global Assembly Cache (GAC). Second, each shared assembly must have a strong name to uniquely identify itself so that no other assemblies have the same name.

A strong name comprises the following:

□ Name of the assembly

□ Version number

□ Public key

□ Culture

Understanding Cryptography

In the world of cryptography, there are two main types of encryption and encryption algorithms — symmetric and asymmetric.

Symmetric encryption is also sometimes known as private key encryption. With private key encryption, you encrypt a secret message using a key that only you know. To decrypt the message, you need to use the same key. Private key encryption is effective only if the key can be kept a secret. If too many people know the key, its effectiveness is reduced.

Imagine that you are trying to send a secret message to your faraway friend, Susan, using a private key. For Susan to decrypt the secret message, she must know the private key. So you need to send it to her. But if the secrecy of the key is compromised somehow (such as through people eavesdropping on your conversation), then the message is no longer secure. Moreover, if Susan tells another friend about the private key, her friend can then also decrypt the message. Despite the potential weakness of private key encryption, it is very easy to implement and, computationally, it does not take up too many resources.

Private key encryption requires that the key used in the encryption process be kept a secret. A more effective way to transport secret messages to your intended recipient is to use asymmetric encryption (also known as public key encryption). In public key encryption, there is a pair of keys involved. This pair, consisting of a private key and a public key, is related mathematically such that messages encrypted with the public key can only be decrypted with the corresponding private key. The contrary is true; messages encrypted with the private key can

Вы читаете C# 2008 Programmer's Reference
Добавить отзыв
ВСЕ ОТЗЫВЫ О КНИГЕ В ИЗБРАННОЕ

0

Вы можете отметить интересные вам фрагменты текста, которые будут доступны по уникальной ссылке в адресной строке браузера.

Отметить Добавить цитату