----------------------------------------------------------- New Message on BDOTNET
----------------------------------------------------------- From: Mahesh ChandraMouli Message 3 in Discussion Hi, The term 'managed' is the cause of much confusion. It is used in various places within .NET, meaning slightly different things. Managed code: The .NET framework provides several core run-time services to the programs that run within it - for example exception handling and security. For these services to work, the code must provide a minimum level of information to the runtime. Such code is called managed code. All C# and Visual Basic.NET code is managed by default. VS7 C++ code is not managed by default, but the compiler can produce managed code by specifying a command-line switch (/com+). Managed data: This is data that is allocated and de-allocated by the .NET runtime's garbage collector. C# and VB.NET data is always managed. VS7 C++ data is unmanaged by default, even when using the /com+ switch, but it can be marked as managed using the __gc keyword. Managed classes: This is usually referred to in the context of Managed Extensions (ME) for C++. When using ME C++, a class can be marked with the __gc keyword. As the name suggests, this means that the memory for instances of the class is managed by the garbage collector, but it also means more than that. The class becomes a fully paid-up member of the .NET community with the benefits and restrictions that brings. An example of a benefit is proper interop with classes written in other languages - for example, a managed C++ class can inherit from a VB class. An example of a restriction is that a managed class can only inherit from one base class. For the unmanaged world, check out this article in MSDN http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconinteroperatingwithunmanagedcode.asp Regards Mahesh ChandraMouli Global Microsoft Business Unit Wipro Technologies Bangalore -----Original Message----- From: Sitaraman [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 8:07 AM To: BDOTNET Subject: Re: Managed & Unmanaged code New Message on BDOTNET Managed & Unmanaged code Reply Reply to Sender Recommend Message 2 in Discussion From: Sitaraman The textbook definition of Managed Code is "Code that runs under a "contract of cooperation" with the common language runtime. " Simpler explanation is "Code that you develop with a language compiler that targets the runtime is called managed code" As you know that .Net Applications run under the Common Language Runtime or the CLR. CLR, as the name implies is a runtime inside of which the code executes. Now the reason why one would want to use the CLR is that it provides a) Automatic Memory Management b) Automatic Lifetuime Control of objects and Garbage Collection c) Code Access Security and Enhanced Security d) Cross Language Integration e) Cross-language exception handling f) Versioning and deployment support g) Debugging and Profiling services As with any other frameworks, if one wants to take advantage of these features, certain rules have to be adhered to. These rules are specified in the Common Language Specifications and the Common Type System Specifications. So any code that is developed in a language which is based on the CLS( e.g. C#, VB.Net etc...) is eligible for being called as managed code. Whereas systems developed as legacy(!!!!) COM applications are unmanaged code. One thing that you should also understand in this context is that, it ispossible that one might write a managed code which in turn makes use of the services provided by unmanaged code. Example is a VB.Net client making a call to a COM Server Application. In this case the unmanaged code WILL still run inside the common language runtime. B ut it wont be able to take advantage of the features mentioned above offered by the CLR Conclusion is that Managed Code is the code which follows the conventions and requirements of the CLR and is able to take advantage of the features offered by the CLR. Unmanaged Code are those which do not follow the conventions of the CLR and therefore cannot take advantage of the features Which leads to the next question, what are these requirements and conventions Checkout 1) Common Language Runtime Overview - http://msdn.microsoft.com/library/en-us/cpguide/html/cpconcommonlanguageruntimeoverview.asp?frame=true 2) Common Language Specification - http://msdn.microsoft.com/library/en-us/cpguide/html/cpconwhatiscommonlanguagespecification.asp?frame=true 3) Common Type System - http://msdn.microsoft.com/library/en-us/cpguide/html/cpconthecommontypesystem.asp?frame=true <MSDN Snippet > .NET Framework Developer's Guide General Considerations See Also Design Considerations for Interoperation All calls made between managed and unmanaged code must negotiate the requirements imposed by each respective programming model. Managed and unmanaged programming models are dissimilar in many respects. The following table shows the defining characteristics of each model. Characteristic Unmanaged model Managed model Coding model Interface-based Object-based Identity GUIDs Strong names Error handling mechanism HRESULTs Exceptions Type compatibility Binary standard Type standard Type definition Type library Metadata Type safety Not type safe Optionally safe Versioning Immutable Resilient Some programming model characteristics have associated entities that you can view, such as type libraries and metadata. Some you can pass as arguments, such as GUIDs and strong names. Other characteristics are more conceptual: you will undoubtedly consider their impact on your application design, but you will not encounter direct mapping between the managed and unmanaged models for these characteristics. The following sections explain each characteristic in more detail. Coding models Unmanaged objects always communicate through interfaces; managed objects and classes can pass data directly without implementing interfaces. By default, COM interop generates a class interface to expose managed functionality through an interface to COM when the object or class does not implement one. Error handling mechanisms COM methods usually return an HRESULT, indicating that the call succeeded or failed. Managed code incorporates exceptions. By default, COM interop maps managed exceptions to failure HRESULTs. Identities GUIDs identify a specific unmanaged type and provide no location information for that type. Strong names consist of a unique assembly name in addition to a type name. Because the assembly name uniquely identifies the type, you can reuse a type name across multiple assemblies. An assembly also introduces publisher key, version, and location information to a managed type. Interoperation services generate GUIDs and are strong-named as required. Type compatibility Types vary between managed and unmanaged code, and also among languages. Type definitions If you are accustomed to working with type libraries, you know that they contain only public types. Moreover, a type library is optional. In the managed programming model, type information is mandatory for all types. Interoperation services provide tools that convert type libraries to metadata in assemblies and metadata to type libraries. Type safety Unmanaged compilers provide no type checking on pointer types, making the code susceptible to potentially harmful activity. In general, managed code requires a higher level of trust. Programmers can continue to use pointers in managed code, although the code has restrictions due to its unsafe behavior. Interoperation services prevent non-trusted, managed code from accessing unmanaged code. Versioning COM interfaces are immutable. If you change an interface, you must rename it with a new GUID. Managed types can evolve, keeping the same name. See Also Design Considerations for Interoperation Send comments on this topic. <MSHelp:link tabIndex=0 keywords="copybeta_nonconfidential"> 2001 Microsoft Corporation. All rights reserved.</MSHelp:link> </MSDN Snippet> View other groups in this category. ----------------------------------------------------------- To stop getting this e-mail, or change how often it arrives, go to your E-mail Settings. http://groups.msn.com/BDotNet/_emailsettings.msnw Need help? If you've forgotten your password, please go to Passport Member Services. http://groups.msn.com/_passportredir.msnw?ppmprop=help For other questions or feedback, go to our Contact Us page. http://groups.msn.com/contact If you do not want to receive future e-mail from this MSN group, or if you received this message by mistake, please click the "Remove" link below. On the pre-addressed e-mail message that opens, simply click "Send". Your e-mail address will be deleted from this group's mailing list. mailto:[EMAIL PROTECTED]
