If you like this article, please click on “+1“ button and share with your friends.

Click here for the Video Tutorial of this article.
visit www.iGnani.com

….continued from “C# 4.0 – Ch:01:C – Language Interoperability”

Garbage Collector (GC)

All .NET programs that run in a managed environment is provided automatic memory management by the .NET CLR. However, to take proper advantage of this automatic memory management requires you to have an overview of the .NET memory management environment. In this chapter, I’ll explain how the automatic memory management in the CLR works.

The Garbage Collector (GC) is .NET ’ s answer to memory management. The GC manages the memory in managed code for you. The purpose of GC is to clean up memory.

Be it any language, all dynamically requested memory is allocated on the heap, however in the case of .NET, the CLR maintains its own managed heap for .NET applications to use. Often, when .NET detects that the managed heap for a given process is becoming full and therefore needs cleaning up, it calls the garbage collector. The garbage collector runs through all the variables in the current scope of your code and checks for references to objects stored on the heap to identify which ones are accessible from the code. In other words, it looks for objects that have references to refer them. Any objects with out reference are deemed to be no longer accessible from your code and can therefore be removed.

However, there are some limitations to Garbage Collector, where in you need to clean up after yourself, too. That is, you are responsible for resources in unmanaged code. For example, you cannot use the garbage collection mechanism with a language such as unmanaged C++, since C++ allows pointers to be freely cast between types.

Garbage collection is not deterministic. In other words, you cannot guarantee when the garbage collector will be called. It will be called when the CLR decides that it is needed. However, it is also possible to override this process and call up the garbage collector in your code manually.

Memory Management is in itself a huge topic which is covered in the coming articles.

Security

.NET excels in terms of complementing the security mechanisms provided by Windows by offering code based security, while Windows only offers role-based security.
While Role-based security is based on the identity of the account under which the process is running, by contrast, Code-based security, is based on what the code actually does and on how much the code is trusted. Thanks to the strong type safety of IL, the CLR is able to inspect code before running it to determine required security permissions. .NET also offers a mechanism by which code can indicate in advance what security permissions it will require to run.

The .NET runtime has been designed so that malicious code cannot infiltrate and execute on a remote machine. If you deliver your software via the Internet or an intranet, or running it directly from the Web, you need to understand the restrictions that the CLR places on your assemblies. Code based security reduces the risks associated with running code of dubious origin, such as those that are downloaded from the Internet. For example, even if code is running under the administrator account, it is possible to use code-based security to indicate that that code should still not be permitted to perform certain types of operations that the administrator account would normally be allowed to do, such as read or write to environment variables, read or write to the registry, or access the .NET reflection features.