Conceptual
Questions
What is the .NET Framework?
The
Microsoft .NET Framework is a platform for building, deploying, and running Web
Services and applications. It provides a highly productive, standards-based,
multi-language environment for integrating existing investments with
next-generation applications and services as well as the agility to solve the
challenges of deployment and operation of Internet-scale applications. The .NET
Framework consists of three main parts: the common language runtime, a
hierarchical set of unified class libraries, and a componentized version of
Active Server Pages called ASP.NET.
Runtime
Technical Questions
Terminology
The
common language runtime is the execution engine for .NET Framework
applications.
It
provides a number of services, including the following:
- Code management (loading and execution)
- Application memory isolation
- Verification of type safety
- Conversion of IL to native code
- Access to metadata (enhanced type information)
- Managing memory for managed objects
- Enforcement of code access security
- Exception handling, including cross-language exceptions
- Interoperation between managed code, COM objects, and pre-existing DLLs (unmanaged code and data)
- Automation of object layout
- Support for developer services (profiling, debugging, and so on)
The
common type system is a rich type system, built into the common language runtime, that supports the types and operations found in most
programming languages. The common type system supports the complete
implementation of a wide range of programming languages.
What is the Common Language Specification
(CLS)?
The
Common Language Specification is a set of constructs and constraints that serves
as a guide for library writers and compiler writers. It allows libraries to be
fully usable from any language supporting the CLS, and for those languages to
integrate with each other. The Common Language Specification is a subset of the
common type system. The Common Language Specification is also important to
application developers who are writing code that will be used by other
developers. When developers design publicly accessible APIs following the rules
of the CLS, those APIs are easily used from all other programming languages that
target the common language runtime.
What is the Microsoft Intermediate Language
(MSIL)?
MSIL is
the CPU-independent instruction set into which .NET Framework programs are
compiled. It contains instructions for loading, storing, initializing, and
calling methods on objects.
Combined
with metadata and the common type system, MSIL allows for true cross-language
integration.
Prior to
execution, MSIL is converted to machine code. It is not interpreted.
What is managed code and managed
data?
Managed
code is code that is written to target the services of the common language
runtime (see What is the Common Language Runtime?). In
order to target these services, the code must provide a minimum level of
information (metadata) to the runtime. All C#, Visual Basic .NET, and JScript .NET code is managed by default. Visual Studio .NET
C++ code is not managed by default, but the compiler can produce managed code by
specifying a command-line switch (/CLR).
Closely
related to managed code is managed data—data that is allocated and de-allocated
by the common language runtime's
garbage collector. C#, Visual Basic, and JScript .NET
data is managed by default. C# data can, however, be marked as unmanaged through
the use of special keywords. Visual Studio .NET C++ data is unmanaged by default
(even when using the /CLR switch), but when using Managed Extensions for C++, a
class can be marked as managed by using the __gc
keyword. As the name suggests, this means that the memory for instances of the
class is managed by the garbage collector. In addition, the class becomes a full
participating member of the .NET Framework community, with the benefits and
restrictions that brings. An example of a benefit is proper interoperability
with classes written in other languages (for example, a managed C++ class can
inherit from a Visual Basic class). An example of a restriction is that a
managed class can only inherit from one base class.
Assemblies
An
assembly is the primary building block of a .NET Framework application. It is a
collection of functionality that is built, versioned, and deployed as a single
implementation unit (as one or more files). All managed types and resources are
marked either as accessible only within their implementation unit, or as accessible by code outside that unit.
Assemblies
are self-describing by means of their manifest, which is an integral part of
every assembly. The manifest:
- Establishes the assembly identity (in the form of a text name), version, culture, and digital signature (if the assembly is to be shared across applications).
- Defines what files (by name and file hash) make up the assembly implementation.
- Specifies the types and resources that make up the assembly, including which are exported from the assembly.
- Itemizes the compile-time dependencies on other assemblies.
- Specifies the set of permissions required for the assembly to run properly.
This
information is used at run time to resolve references, enforce version binding
policy, and validate the integrity of loaded assemblies. The runtime can
determine and locate the assembly for any running object, since every type is
loaded in the context of an assembly. Assemblies are also the unit at which code
access security permissions are applied. The identity evidence for each assembly
is considered separately when determining what permissions to grant the code it
contains.
The
self-describing nature of assemblies also helps makes zero-impact install and
XCOPY deployment feasible.
A private
assembly is used only by a single application, and is stored in that
application's install directory (or a
subdirectory therein). A shared assembly is one that can be referenced by more
than one application. In order to share an assembly, the assembly must be
explicitly built for this purpose by giving it a cryptographically strong name
(referred to as a strong name). By contrast, a private assembly name need only
be unique within the application that uses it.
By making
a distinction between private and shared assemblies, we introduce the notion of
sharing as an explicit decision. Simply by deploying private assemblies to an
application directory, you can guarantee that that application will run only
with the bits it was built and deployed with. References to private assemblies
will only be resolved locally to the private application
directory.
There are
several reasons you may elect to build and use shared assemblies, such as the
ability to express version policy. The fact that shared assemblies have a
cryptographically strong name means that only the author of the assembly has the
key to produce a new version of that assembly. Thus, if you make a policy
statement that says you want to accept a new version of an assembly, you can
have some confidence that version updates will be controlled and verified by the
author. Otherwise, you don't have to
accept them.
For
locally installed applications, a shared assembly is typically explicitly
installed into the global assembly cache (a local cache of assemblies maintained
by the .NET Framework). Key to the version management features of the .NET
Framework is that downloaded code does not affect the execution of locally
installed applications. Downloaded code is put in a special download cache and
is not globally available on the machine even if some of the downloaded
components are built as shared assemblies.
The
classes that ship with the .NET Framework are all built as shared assemblies.
If I want to build a shared assembly,
does that require the overhead of signing and managing key pairs?
Building
a shared assembly does involve working with cryptographic keys. Only the public
key is strictly needed when the assembly is being built. Compilers targeting the
.NET Framework provide command line options (or use custom attributes) for
supplying the public key when building the assembly. It is common to keep a copy
of a common public key in a source database and point build scripts to this key.
Before the assembly is shipped, the assembly must be fully signed with the
corresponding private key. This is done using an SDK tool called SN.exe (Strong
Name).
Strong
name signing does not involve certificates like Authenticode does. There are no
third party organizations involved, no fees to pay, and no certificate chains.
In addition, the overhead for verifying a strong name is much less than it is
for Authenticode. However, strong names do not make any statements about
trusting a particular publisher. Strong names allow you to ensure that the
contents of a given assembly haven't
been tampered with, and that the assembly loaded on your behalf at run time
comes from the same publisher as the one you developed against. But it makes no
statement about whether you can trust the identity of that
publisher.
A
namespace is a logical naming scheme for types in which a simple type name, such
as MyType, is preceded with a dot-separated
hierarchical name. Such a naming scheme is completely under the control of the
developer. For example, types MyCompany.FileAccess.A
and MyCompany.FileAccess.B might be logically expected
to have functionality related to file access. The .NET Framework uses a
hierarchical naming scheme for grouping types into logical categories of related
functionality, such as the Microsoft® ASP.NET application framework, or remoting functionality. Design tools can make use of
namespaces to make it easier for developers to browse and reference types in
their code. The concept of a namespace is not related to that of an assembly. A
single assembly may contain types whose hierarchical names have different
namespace roots, and a logical namespace root may span multiple assemblies. In
the .NET Framework, a namespace is a logical design-time naming convenience,
whereas an assembly establishes the name scope for types at run time.
Application
Deployment and Isolation
What options are available to deploy my
.NET applications?
The .NET
Framework simplifies deployment by making zero-impact install and XCOPY
deployment of applications feasible. Because all requests are resolved first to
the private application directory, simply copying an application's directory files to disk is all that is needed to
run the application. No registration is required.
This
scenario is particularly compelling for Web applications, Web Services, and
self-contained desktop applications. However, there are scenarios where XCOPY is
not sufficient as a distribution mechanism. An example is when the application
has little private code and relies on the availability of shared assemblies, or
when the application is not locally installed (but rather downloaded on demand).
For these cases, the .NET Framework provides extensive code download services
and integration with the Windows Installer. The code download support provided
by the .NET Framework offers several advantages over current platforms,
including incremental download, code access security (no more Authenticode
dialogs), and application isolation (code downloaded on behalf of one
application doesn't affect other
applications). The Windows Installer is another powerful deployment mechanism
available to .NET applications. All of the features of Windows Installer,
including publishing, advertisement, and application repair will be available to
.NET applications in Windows Installer 2.0.
I've written an assembly that I want to use in more
than one application. Where do I deploy it?
Assemblies
that are to be used by multiple applications (for example, shared assemblies)
are deployed to the global assembly cache. In the prerelease and Beta builds,
use the /i option to the GACUtil SDK tool to install an assembly into the
cache:
gacutil /i myDll.dll
Windows
Installer 2.0, which ships with Windows XP and Visual Studio .NET will be able
to install assemblies into the global assembly cache.
The .NET
Framework ships with a Windows shell extension for viewing the assembly cache.
Navigating to % windir%\assembly with the Windows
Explorer activates the viewer.
What is an
application domain?
An
application domain (often AppDomain) is a virtual
process that serves to isolate an application. All objects created within the
same application scope (in other words, anywhere along the sequence of object
activations beginning with the application entry point) are created within the
same application domain. Multiple application domains can exist in a single
operating system process, making them a lightweight means of application
isolation.
An OS
process provides isolation by having a distinct memory address space. While this
is effective, it is also expensive, and does not scale to the numbers required
for large web servers. The Common Language Runtime, on the other hand, enforces
application isolation by managing the memory use of code running within the
application domain. This ensures that it does not access memory outside the
boundaries of the domain. It is important to note that only type-safe code can
be managed in this way (the runtime cannot guarantee isolation when unsafe code
is loaded in an application domain).
Garbage
Collection
What is garbage
collection?
Garbage
collection is a mechanism that allows the computer to detect when an object can
no longer be accessed. It then automatically releases the memory used by that
object (as well as calling a clean-up routine, called a "finalizer," which is written by the user). Some garbage
collectors, like the one used by .NET, compact memory
and therefore decrease your program's
working set.
For most
programmers, having a garbage collector (and using garbage collected objects)
means that you never have to worry about deallocating
memory, or reference counting objects, even if you use sophisticated data
structures. It does require some changes in coding style, however, if you
typically deallocate system resources (file handles,
locks, and so forth) in the same block of code that releases the memory for an
object. With a garbage collected object you should provide a method that
releases the system resources deterministically (that is, under your program
control) and let the garbage collector release the memory when it compacts the
working set.
All
languages that target the runtime allow you to allocate class objects from the
garbage-collected heap. This brings benefits in terms of fast allocation, and
avoids the need for programmers to work out when they should explicitly
'free' each object.
The CLR
also provides what are called ValueTypes—these are
like classes, except that ValueType objects are
allocated on the runtime stack (rather than the heap), and therefore reclaimed
automatically when your code exits the procedure in which they are defined. This
is how "structs" in C# operate.
Managed
Extensions to C++ lets you choose where class objects are allocated. If declared
as managed Classes, with the __gc keyword, then they
are allocated from the garbage-collected heap. If they don't include the __gc
keyword, they behave like regular C++ objects, allocated from the C++ heap, and
freed explicitly with the "free" method.
For
additional information about Garbage Collection see:
- Garbage Collection: Automatic Memory Management in the Microsoft .NET Framework
- Garbage Collection, Part 2: Automatic Memory Management in the Microsoft .NET Framework
Remoting
There are
two aspects to in-process communication: between contexts within a single
application domain, or across application domains. Between contexts in the same
application domain, proxies are used as an interception mechanism. No
marshaling/serialization is involved. When crossing
application domains, we do marshaling/serialization using the runtime binary
protocol.
Cross-process
communication uses a pluggable channel and formatter protocol, each suited to a
specific purpose.
- If the developer specifies an endpoint using the tool soapsuds.exe to generate a metadata proxy, HTTP channel with SOAP formatter is the default.
- If a developer is doing explicit remoting in the managed world, it is necessary to be explicit about what channel and formatter to use. This may be expressed administratively, through configuration files, or with API calls to load specific channels. Options are:
HTTP
channel w/ SOAP formatter (HTTP works well on the Internet, or anytime traffic
must travel through firewalls)
TCP
channel w/ binary formatter (TCP is a higher performance option for local-area
networks (LANs))
When
making transitions between managed and unmanaged code, the COM infrastructure
(specifically, DCOM) is used for remoting. In interim
releases of the CLR, this applies also to serviced components (components that
use COM+ services). Upon final release, it should be possible to configure any
remotable component.
Distributed
garbage collection of objects is managed by a system called "leased based
lifetime." Each object has a lease time, and when that time expires, the object
is disconnected from the remoting infrastructure of
the CLR. Objects have a default renew time-the lease is renewed when a
successful call is made from the client to the object. The client can also
explicitly renew the lease.
Interoperability
Yes. Any
COM component you have deployed today can be used from managed code, and in
common cases the adaptation is totally automatic.
Specifically,
COM components are accessed from the .NET Framework by use of a runtime callable
wrapper (RCW). This wrapper turns the COM interfaces exposed by the COM
component into .NET Framework-compatible interfaces. For OLE automation
interfaces, the RCW can be generated automatically from a type library. For
non-OLE automation interfaces, a developer may write a custom RCW and manually
map the types exposed by the COM interface to .NET Framework-compatible types.
Can .NET Framework
components be used from a COM program?
Yes.
Managed types you build today can be made accessible from COM, and in the common
case the configuration is totally automatic. There are certain new features of
the managed development environment that are not accessible from COM. For
example, static methods and parameterized constructors cannot be used from COM.
In general, it is a good idea to decide in advance who the intended user of a
given type will be. If the type is to be used from COM, you may be restricted to
using those features that are COM accessible.
Depending
on the language used to write the managed type, it may or may not be visible by
default.
Specifically,
.NET Framework components are accessed from COM by using a COM callable wrapper
(CCW). This is similar to an RCW (see previous question), but works in the
opposite direction. Again, if the .NET Framework development tools cannot
automatically generate the wrapper, or if the automatic behavior is not what you
want, a custom CCW can be developed.
Can I use the
Win32 API from a .NET Framework program?
Yes.
Using platform invoke, .NET Framework programs can access native code libraries
by means of static DLL entry points.
Here is
an example of C# calling the Win32 MessageBox
function:
using System;
using System.Runtime.InteropServices;
class MainApp
{
[DllImport("user32.dll", EntryPoint="MessageBox")]
public static extern int MessageBox(int hWnd, String strMessage, String strCaption, uint uiType);
public static void Main()
{
MessageBox( 0, "Hello, this is PInvoke in operation!", ".NET", 0 );
}
}
Security
Usually,
not a thing—most applications will run safely and will not be exploitable by
malicious attacks. By simply using the standard class libraries to access
resources (like files) or perform protected operations (such as a reflection on
private members of a type), security will be enforced by these libraries. The
one simple thing application developers may want to do is include a permission
request (a form of declarative security) to limit the permissions their code may
receive (to only those it requires). This also ensures that if the code is
allowed to run, it will do so with all the permissions it
needs.
Only
developers writing new base class libraries that expose new kinds of resources
need to work directly with the security system. Instead of all code being a
potential security risk, code access security constrains this to a very small
bit of code that explicitly overrides the security system.
Why does my code
get a security exception when I run it from a network shared
drive?
Default
security policy gives only a restricted set of permissions to code that comes
from the local intranet zone. This zone is defined by the Internet Explorer
security settings, and should be configured to match the local network within an
enterprise. Since files named by UNC or by a mapped drive (such as with the NET
USE command) are being sent over this local network, they too are in the local
intranet zone.
The
default is set for the worst case of an unsecured intranet. If your intranet is
more secure you can modify security policy (with the .NET Framework
Configuration tool or the CASPol tool) to grant more
permissions to the local intranet, or to portions of it (such as specific
machine share names).
Security
exceptions occur when code attempts to perform actions for which it has not been
granted permission. Permissions are granted based on what is known about code;
especially its location. For example, code run from the Internet is given fewer permissions than that run from the local machine
because experience has proven that it is generally less reliable. So, to allow
code to run that is failing due to security exceptions, you must increase the
permissions granted to it. One simple way to do so is to move the code to a more
trusted location (such as the local file system). But this won't work in all cases (web applications are a good
example, and intranet applications on a corporate network are another). So,
instead of changing the code's
location, you can also change security policy to grant more permissions to that location. This is done using either the
.NET Framework Configuration tool or the code access security policy utility
(caspol.exe). If you are the code's
developer or publisher, you may also digitally sign it and then modify security
policy to grant more permissions to code bearing that
signature. When taking any of these actions, however, remember that code is
given fewer permissions because it is not from an identifiably trustworthy
source—before you move code to your local machine or change security policy, you
should be sure that you trust the code to not perform malicious or damaging
actions.
How do I
administer security for my machine? For an
enterprise?
The .NET
Framework includes the .NET Framework Configuration tool, an MMC snap-in (mscorcfg.msc), to configure several aspects of the CLR
including security policy. The snap-in not only supports administering security
policy on the local machine, but also creates enterprise policy deployment
packages compatible with System Management Server and Group Policy. A command
line utility, CASPol.exe, can also be used to script policy changes on the
computer. In order to run either tool, in a command prompt, change the current
directory to the installation directory of the .NET Framework (located in
%windir%\Microsoft.Net\Framework\v1.0.2914.16\) and type mscorcfg.msc or
caspol.exe.
Evidence-based
security (which authorizes code) works together with Windows 2000 security
(which is based on log on identity). For example, to access a file, managed code
must have both the code access security file permission and must also be running
under a log on identity that has NTFS file access rights. The managed libraries
that are included with the .NET Framework also provide classes for role-based
security. These allow the application to work with Windows log on identities and
user groups.
Comments
Post a Comment