You know, this sounds like a commercial, or a press release written by
Microsoft. I don't know that much about .NET, but it seems a little
weird to me that a description of benefits that remain to be delivered
should be phrased using terms like "proven". Proven means demonstrated,
There's also the little matter the blurb below mentions security, which
is itself a problem: Whenever the word "security" comes up in relation
to Microsoft, it's usually accompanied by the word "breach". It's
reasonable, therefore, to be a bit skeptical that .NET, a Microsoft
product, will improve security.
How does all this stuff below, which is phrased in very broad and sweeping
terms, apply *specifically* and *concretely* to MySQL?
At 21:15 -0600 11/15/02, Joseph D. Wagner wrote:
>It seems to me that a certain misunderstanding exists about the role of
>the Microsoft .NET Framework in future coding and development on
>Microsoft platforms, and the benefits of utilizing the .NET Framework on
>Win32 platforms. There isn't much I can say about the role of .NET in
>future development that hasn't already been said. I can only hope you
>believe the people that say the .NET Framework is the future of Win32
>development (source: Microsoft; seems credible since they write the
>operating system). However, I can provide you with this information
>about the advantages of .NET, and why the MySQL development team should
>utilize the Microsoft .NET Framework for future development of the MySQL
>Win32 port, not just the ODBC driver.
>The MicrosoftR .NET Framework and Microsoft Visual StudioR .NET belong,
>in the broadest sense, in the software development category. The leading
>edge of the category, according to customers and industry analysts, is
>the distributed application development segment. The software
>development category contains all developer tools products, while the
>distributed application development segment includes only those tools
>aimed at server- and client-side application development. Microsoft
>believes the main contenders in this segment include the .NET Framework
>and Visual Studio .NET, versus the Java-based product offerings of IBM
>WebSphere and VisualAge, and Sun iPlanet Application Server and Forte.
>If you examine the needs of developers and enterprise organizations, you
>can create a list of criteria for evaluating how the .NET Framework and
>Visual Studio .NET enable the rapid development, simple integration, and
>improved operation of the next generation of XML Web services and
>applications. These include:
>Improved Time-to-Market Criteria
>* The ability to use any programming language. Give developers the
>ability to use any programming language. Allow applications written with
>different programming languages to integrate deeply with each other.
>Leverage current development skills to go forward without retraining.
>Customers have discovered the exorbitant cost of finding developers
>skilled in some specialized technologies. Prominent industry analysts
>recommend using existing skills whenever possible, and avoiding the high
>cost and high failure rate of relying on the technical skills in
>* Access to state-of-the-art development tools. Deliver well-designed
>development tools, such as integrated debugging and profiling.
>* Improved code design. Provide a component-based, plumbing-free design
>that enables developers to focus on writing business logic. Eliminate
>the need to generate IDL or registry code. Provide existing, well-tested
>controls that encapsulate common programmer tasks.
>* Support for loosely coupled and tightly coupled architectures. To
>achieve performance, scalability, and reliability in distributed
>applications, there are some operations in which components can be
>tightly coupled, that is, interdependent in real time. Most modern
>systems have this capability. However, successful platforms must also
>have complete support for loosely coupled, message-oriented
>communication, in which the chain of events supporting a distributed
>transaction is not broken or blocked by any real-time dependencies. Both
>architectures must be supported completely and naturally so developers
>create scalable solutions by default.
>Simple Integration Criteria
>* Software as a service. Build and deliver software as a service. Employ
>standards and protocols built on XML and the Simple Object Access
>Protocol (SOAP) family of integration standards. Provide the ability for
>applications to easily to share and gain access to these services.
>* Approved standards for language and infrastructure. Standards are core
>to delivering software as a service. Consequently, Microsoft has
>submitted the specifications for the C# programming language and a
>subset of the .NET Framework called the common language infrastructure
>to ECMA, and ECMA is standardizing them. These specifications represent
>the participation of six other ECMA partners, including Hewlett-Packard
>and Intel, and are currently on track to be considered by the ECMA
>General Assembly later this year for formal approval.
>* Transparent extensions for legacy components and applications. Provide
>the ability to integrate existing software into a language-independent
>platform by using proven technology.
>* Ease of data access. Make available a productive interface to any
>database -- one that is designed to support the use of loosely coupled
>data access by Web applications. Support XML as its native data format.
>Improved Operations Criteria
>* Evidence-based security. Provide an evidence-based security model that
>maintains a fine-grained, method-level control over what applications
>can and can't do based on who wrote the code, what the code is trying to
>do, from where it was installed, and who is trying to run it.
>* Simplified application deployment. Support a simplified application
>deployment method that makes installing applications as easy as copying
>them into a directory. Build in the ability of a framework to detect
>damaged applications and self-heal to solve the problem.
>* Increased reliability for applications. Deliver technologies that make
>applications more reliable, such as high-performance automated memory
>management and event-driven monitoring of Web applications with
>automated granular control of restarts.
>* True performance improvements. At the end of the day, improve the
>performance of typical XML Web services and applications.
>* A comprehensive solution that provides all of the services needed to
>produce an enterprise-class solution. These include application
>services, such as an object request broker, transaction-processing
>monitor, complete scripting engine, feature rich Web server, world-class
>messaging support, monitoring, and management infrastructure. All of
>these services are integrated, so developers can spend their time
>building applications, not cobbling together application services.
>* A consistent and unified programming model for applications running
>within, and applications running across, Internet firewalls. Related to
>loosely coupled architectures, this criterion seeks out the solutions
>that enable organizations to learn, build, and support a simple
>programming model for intranet- and Internet-based applications in order
>to reduce training and support costs.
>* A consistent and unified programming model for broad-reach Web-based
>clients, as well as rich client interfaces, and emerging smart devices.
>Customers today are evaluating the full range of client devices,
>including PCs, browsers, personal digital assistants (PDAs), and
>cellular telephones. To be successful, complex, distributed systems must
>have a programming model that elegantly supports all of today's user
>experiences, and those that will emerge in the future, and that contains
>a simple model for maintaining consistent business logic across any
>A platform embracing the above principles will enable customers to lead
>in their respective industries -- to build, deploy, and maintain better
>applications, and to bring new software and new services to market
>faster and less expensively than competitors. The .NET Framework
>satisfies these requirements more completely and effectively than any
>other product available today, and will do so into the foreseeable
>future. We invite you to examine these new tools carefully, and to make
>your own comparison.
>Use Any Programming Language
>The .NET Framework enables developers to use any programming language,
>and for applications written in different programming languages to
>integrate deeply with each other, enabling current development skills to
>go forward without retraining.
>Objects written on top of the .NET Framework can integrate with each
>other regardless of the language in which they were created, because
>they are built on top of a common type system. The multilanguage
>integration of the .NET Framework includes:
>* Calling methods on other objects
>* Inheriting implementations from other objects
>* Passing instances of a class to other objects
>* Using a single debugger across multiple objects
>* Trapping errors from other objects
>Cross-language integration is useful in several scenarios. For example,
>development projects gain access to a larger skills base-project
>managers can choose developers skilled in any programming language and
>join them together on the same team. Alternately, developers writing
>components for a distributed Web application will find it helpful to
>know that no matter what language they choose to write their components
>in, those components can interact closely with each other and with
>components supplied by other developers.
>Take Advantage of Industry-Leading Tools
>The .NET Framework is designed for development tools and includes many
>features specifically targeted as improving the quality of the tools
>that use it, such as integrated debug and profiling. Microsoft Visual
>Studio .NET is built on top of and designed to take advantage of the
>Developers Write Less Code
>The .NET Framework uses a component-based, plumbing-free design that
>enables developers to focus on writing business logic. Developers don't
>need to write IDL or registry code-and ASP.NET, for example, includes
>dozens of controls that encapsulate common programmer tasks, such as
>implementing a shopping cart feature.
>The .NET Framework decreases the amount of code the developer has to
>write. This is done through many mechanisms, such as self-describing
>metadata, automatic memory management, a rich set of controls,
>simplified programming classes, and the capability to automatically
>transform any application method into an XML Web service with the
>addition of a single keyword.
>Decreasing the Plumbing
>With most development environments today, the developer has to cope with
>infrastructure overhead-details that are required for building an
>application but that aren't actually business logic. The .NET Framework
>reduces this through many mechanisms such as automatic memory
>management, metadata, a rich set of controls, and the ability transform
>an application method into an XML Web service with the addition of a
>Automatic Memory Management
>Many of the problems associated with modern applications can be
>attributed to memory leaks; in fact keeping track of the memory being
>used can be a very daunting task. The .NET Framework solves this problem
>with a high-performance, generational memory manager that is responsible
>for freeing unused memory efficiently and without imposing a high
>overhead on application performance.
>Metadata enables developers to write less code by eliminating the need
>for separate IDL files. This is possible because the objects themselves
>contain metadata that metadata describes information about the methods,
>fields, properties, and events associated with a class.
>The controls in the .NET Framework offer code savings in two primary
>areas: the adaptive user interface features and server-side controls.
>Server-side controls assist developers by separating the code and the
>content, enabling developers to concentrate on the business logic they
>are trying to write.
>Automatic Browser Detection
>Automatic browser detection enables the runtime to sense the
>capabilities of the client automatically and render suitable HTML. The
>HTML rendered to achieve a consistent look of a Web page for down-level
>browser software and up-level browser software, such as Internet
>Explorer 5.5, may look radically different-but the ASP.NET code that
>generates the HTML is exactly the same.
>Employ Windows 2000 Applications Services
>Windows 2000 has the most advanced application services available: the
>fastest transaction monitor and message queuing engine, the most
>advanced data access subsystem, the best Web server. The .NET Framework
>takes advantage of these. For example, .NET Framework transactions are
>COM+ transactions, and all the new COM+ capabilities in Windows XP and
>Windows .NET Server can be used from the .NET Framework.
>Create XML Web Services Easily
>Taking advantage of the Internet by using COM component interfaces was
>made simple in 1996 with the release of Active Server Page (ASP) scripts
>running under the Windows 2000 Server Internet Information Server (IIS).
>For example, most developers could easily update a database from a Web
>page by using ActiveX Data Objects (ADO), Visual Basic Scripting Edition
>(VBScript), and ASP.
>Use COM+ Services
>Introduced in 1992, the Microsoft Component Object Model (COM) is the
>most popular object model for building reusable components, with more
>than 10,000 components commercially available. Over time, COM has
>evolved from a technology for embedding one document inside another
>(OLE) to a technology for distributing self-contained applications
>(ActiveX) to a technology for building and running middle-tier business
>Based on years of experience, Microsoft architects undertook the
>challenge of making COM development easier. Visual Basic began to show
>how to accomplish this in 1995. The .NET Framework takes that
>simplification to its next step by automating COM features, such as
>reference counting, interface description, and registration.
>The .NET Framework natively supports COM. In fact, a COM developer using
>the Microsoft Visual Studio 6.0 development system could call a .NET
>Framework component and, to the developer, it would look like a COM
>component, complete with IUnknown. Conversely, a .NET Framework
>developer using Visual Studio .NET would see a COM component as a .NET
>COM+ is COM combined with Microsoft Transaction Server, distributed COM
>(DCOM), and other component services, such as Partitions. COM+ also
>provides a set of middle-tier-oriented services. In particular, COM+
>provides process management and database and object-connection pooling.
>In future versions, it will also provide stronger process isolation for
>application service providers-a feature called partitioning.
>The COM+ services are primarily oriented toward middle-tier application
>development, and they focus on providing reliability and scalability for
>large-scale, distributed applications. These services are complementary
>to the programming services provided by the .NET Framework. The .NET
>Framework provides direct access to these component services.
>You can think of COM+ as providing the component services for building
>scalable, reliable distributed middle-tier applications. The .NET
>Framework provides the language services that simplify and speed up
>application development and deployment.
>Automatic Transaction Support
>One of the most critical .NET Framework COM+ features that developers
>will want to use is COM+ Transactions. It is easy to build applications
>that use transaction support in the .NET Framework through simple
>keywords and settings. In fact, the .NET Framework takes advantage of
>the COM+ transaction infrastructure to provide both manual and automatic
>The beauty of the integration between the .NET Framework and COM+
>transactions is that .NET Framework developers can use the
>high-performance COM+ transaction environment without needing to learn
>COM+. For example, you can simply copy your .NET Framework components
>that need COM+ Services such as transactions into a directory, and the
>.NET Framework will dynamically add the components to the COM+
>The .NET Framework security system provides fine-grained, method-level
>control over what applications can and can't do based on who wrote the
>code, what it's trying to do, where it was installed from, and who is
>trying to run it.
>The .NET Framework security infrastructure encompasses features to
>handle both authentication of users and code access security that
>enforces security permissions on code based on trust policy. An
>extensible library of cryptographic functions provides easy access to
>hashing and encryption from managed code, including digital signatures
>for XML. All existing security mechanisms in the platform exist with and
>provide the foundation for on which.NET Framework builds.
>Code Access Security and Role-based Security
>The .NET Framework offers security through two high-level categories:
>code access security and role-based security. Code access security is
>the mechanism by which developers can specify the level of access their
>code should have to resources and operations. Role-based security is
>used for controlling permissions based on the user identity.
>Code access security is deeply integrated into the .NET Framework, and
>it provides security enforcement of different levels of trust on
>different code-even different pieces of code within the same running
>application. For example, code from the Internet should be trusted less
>than code from a reliable vendor. Many security problems result from
>less trusted code getting outside the confines meant to secure it. Since
>the runtime has control of execution of all managed code, it continues
>to enforce restrictions for anything the less trusted code might do.
>Code access security is built on an evidence-based security policy
>system that grants to code the appropriate permissions. A permission
>object represents the right to do some operation-for example, to write a
>file, to display on the screen, and so forth. The evidence for any
>code-its location, digital signature, and so forth-is presented to the
>security policy system for it to make a trust decision based on policy
>established by the administrator. If an application attempts to perform
>a protected operation, a security check will demand that the code and
>all of its callers have the necessary permissions to perform that
>operation. The check of all callers is important to prevent less trusted
>code from somehow tricking more trusted code into performing a
>privileged operation. The .NET Framework can force managed code to pass
>a process called verification to enforce security on it. Verification
>ensures that the code uses only well-defined interfaces in interacting
>with other objects, which prevents access to unauthorized memory.
>Role-based security is based on two fundamental concepts: authentication
>and authorization. Authentication is the process of validating a set of
>user credentials against an authority. If the credentials are valid,
>that user is said to have an identity. Authorization is the process of
>using that identity to grant access to or protect a resource.
>Applications can authenticate users with any authentication protocol,
>including Basic, Digest, Microsoft Passport, Integrated Windows
>authentication (formerly known as Microsoft Windows NTR LAN Manager, or
>NTLM, which supports Kerberos), or forms-based authentication. The
>application program is written the same way no matter what type of
>authentication is used. Moreover, additional user-defined authentication
>providers can be plugged into this uniform architecture if needed. For
>example, a customer database with user names and passwords can easily be
>used as a new authentication provider.
>A cryptographic library provides easy-to-use hash, encryption,
>decryption, and random number generation. Encryption support for several
>symmetric and asymmetric algorithms is included. In addition, Microsoft
>is tracking the emerging XML digital signature standards work and will
>have methods to sign and verify signed XML.
>Simplify Application Deployment
>With the .NET Framework metadata technology, installing applications is
>as easy as copying them into a directory. The .NET Framework is even
>capable of self-healing when applications are damaged.
>Application deployment is greatly simplified with the .NET Framework.
>One of the largest challenges faced by developers and administrators
>(and ultimately users) is versioning. If your system works fine today,
>and then you install a new application and suddenly nothing works any
>more, it's very often because the new application overwrote some shared
>library and (more often than not) fixed some bug that existing
>applications were relying on.
>The .NET Framework includes a couple of advances that virtually
>eliminate DLL version conflicts. First, it includes a very strong
>internal naming system that makes it much harder for two libraries that
>may even have the same file name to be mistaken for each other. Beyond
>that, there's a new side-by-side deployment feature. If that new
>application really does overwrite a shared library, the existing
>application can actually repair itself. The next time the existing
>application starts up, it will check all its shared files. If it finds
>that one has changed and that the changes are incompatible, it can ask
>the runtime to fetch a version it knows it can work with.
>Side-by-side deployment is enabled by assemblies and manifests.
>What Is an Assembly?
>An assembly is the primary building block of a .NET application. It is a
>collection of functionality built, versioned, and deployed as a single
>implementation unit (one or multiple files). All managed types and
>resources are marked either as assessable only within their
>implementation unit or as exported for use by code outside that unit.
>Assemblies are self-describing through their manifest, an integral part
>of every assembly.
>What Does the Manifest Do?
>The manifest performs the following functions:
>* Establishes the assembly identity, in the form of a text name,
>version, culture, and if the assembly is to be shared across
>applications, a digital signature.
>* Defines what files (by name and file hash) make up the assembly
>* Itemizes the compile-time dependencies on other assemblies.
>* Specifies the types and resources that make up the assembly, including
>which ones are exported from the assembly.
>* Specifies the set of permissions required for this assembly to run
>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
>Put simply, assemblies contain information about the dependencies of the
>things inside. The runtime is responsible for making sure these
>dependencies are fulfilled, including fetching necessary components from
>approved sites (a technique that uses the.NET Framework security
>Because the runtime is responsible for actually managing applications as
>they run, the .NET Framework is even able to run two versions of the
>same component side by side. The self-describing nature of assemblies
>also helps makes zero-impact install and no-touch deployment feasible.
>It has always been possible for multiple copies of a software component
>to reside on the same system. In the past, however, only one of these
>copies can be registered with the operating system or loaded for
>execution, because the policy for locating and loading components is
>global to the system. Through side-by-side deployment, the .NET
>Framework adds the infrastructure necessary to support per-application
>policies that govern the locating and loading of components.
>Application configuration information defines where to look for
>assemblies, thus the runtime can load different versions of the same
>assembly for two different applications that are running concurrently.
>This eliminates issues that arise from incompatibilities between
>component versions, improving overall system stability. If necessary,
>administrators can add configuration information, such as a different
>versioning policy, to assemblies at deployment time, but the original
>information provided at build time is never lost.
>Because assemblies are self-describing, no explicit registration with
>the operating system is required. Application deployment can be as
>simple as copying files to a directory tree. Configuration information
>is stored in XML files that can be edited by any text editor.
>Run More Reliable Applications
>The .NET Framework includes technologies to make applications more
>reliable. For example, memory, threads, and processes are managed by the
>.NET Framework to ensure that memory leaks don't occur. ASP.NET monitors
>running Web applications and can automatically restart them at
>administrator-defined intervals. Many of the reliability features in the
>.NET Framework come from the application services supplied by the
>unified classes called Enterprise Services (System.EnterpriseServices).
>Using the same engine as COM+, these application services provide such
>features as transactions, messaging, events, partitions, and object
>The .NET Framework improves the performance of typical Web applications.
>ASP.NET includes advanced compilation and caching features that improve
>performance by a factor of two to three over existing Active Server