SynapseIndia DOTNET Development Platform Overview
Outline • • • • • •
What is .NET? - Microsoft’s Strategy Under the Hood Security & Managed Code ASP.NET Cross-Language Debugging Zero-Footprint Desktop Deployment
What is .NET?
A comprehensive XML Web Services platform
Visual Studio
Windows XP, Windows CE, Pocket PC, Office
Passport, Alerts, .NET My Services
Windows Server, Enterprise Servers
Under the Hood
Common Language Runtime (CLR)
The execution environment for IL. Provides security, garbage collection, exception handling, inheritance and support for Base Class Libraries. Comparable to JVM.
Common Language Specification (CLS)
A subset of the Common Type Specification which all language compilers targeting CLR must adhere to.
Intermediate Language (IL)
Compilers generate “platform� independent IL which the JIT will compile for execution by the CLR. For equivalent functionality, the IL should be exactly the same for different languages! Performance is same.
Language Neutrality CLR doesn’t know what language it is running. There are more than 25 languages for .NET, including COBOL, PERL, Eiffel and Java! CLS objects are cross-language. A VB.NET class can be created as an object in PERL and then passed to a COBOL method! Java is language specific and platform neutral. .NET is language neutral, but platform specific.
.NET Base Classes Object Oriented Over 4,500 classes provide most of the features that most applications ever need. Much of the implementation of data is XML inside (ADO.NET) .NET support for Web Services leads industry.
.NET Assembly - The New .DLL Combines MSIL with metadata for code management. Strong Typing allows side-by-side, concurrent execution of different versions of the same assembly! Determination of which version to run can be made through application settings or by administrators of the machine. Global Assembly Cache (GAC) allows commonly shared assemblies to be pre-compiled and stored in one place. No Registry Required! “DLL Hell� is gone.
Security & Managed Code Managed Code is type-safe and has execution boundaries, called Domains. Application Domains can execute in the same process. Unmanaged code in an Assembly is identified by metadata, letting the CLR treat it differently. Policies at the Enterprise, Machine, User and Application levels define permissible actions for execution, and configuration settings.
Role-Based Security
Programmers can use role-based security to control access to methods or properties at run-time. Isolate security from code logic by applying attributes defined in System.Security or EnterpriseServices System.Security is feature-rich, but is limited to Windows user groups. EnterpriseServices uses COM+ roles for more flexibility but classes must inherit from EnterpriseServices You can implement your own security provider for databases, LDAP, ‌
Example: Security Using Attributes using System.Security.Permissions; public class Car { [PrincipalPermission(SecurityAction.Demand,Role=“Parent")] public long StartEngine() {...} [PrincipalPermission(SecurityAction.Demand,Role=“Parent")] [PrincipalPermission(SecurityAction.Demand,Role=“Child")] public long OpenDoor() {...} }
Evidence-Based Security Evidence is the characteristics of the code such as its directory or digital signature. Code Groups are logical groupings of code with evidence that satisfies certain conditions like <Directory=“c:\winnt\”> or <URL=“UseDotNet.com”>. Named Permission Sets define the permissions applied to Code Groups. Application Domain Hosts such as browsers or the shell can enforce more restrictive permissions and, if trusted, provide evidence about the hosted assembly to the CLR.
Evidence-Based Security Effective Permissions are determined by calculating the intersection of Named Permissions granted at each Policy Level. Each Policy Level grants permissions based on the union of Named Permissions for all matching Code Groups defined at that level. Attributes can be applied to Code Groups in each policy level to modify the default determination. The effect is for least restrictive permissions within a Policy Level (unless â&#x20AC;&#x153;nothingâ&#x20AC;? is specified) but most restrictive permissions when Policy Levels are combined. Enterprise, Machine, User and Application policies are adhered to but defined independently.