By Tim Landgrave
Architects and developers will need to consider four key areas that have changed from Version 1.0 (V1.0) to Version 1.1 (V1.1) of the .NET Framework. These areas are newly integrated features, new functionality, compatibility issues, and security changes. Let’s look at each of these in more detail.
Integrated feature support
After V1.0 shipped, Microsoft continued releasing additional features as downloads from MSDN. Although most companies welcomed the new features, releasing them piecemeal made it increasingly difficult to ensure that all desktops and servers had the appropriate drivers and add-ons when deploying applications. With these features consolidated in the V1.1 release, architects can count on all the previously optional features being available. The areas that will have the most significant impact on most companies are Mobile Web support and native database drivers.
Mobile Web support
Shortly after the initial release of the .NET Framework, Microsoft added support for connected mobile devices, called the Microsoft Mobile Internet Toolkit. Now called ASP.NET mobile controls, they’re included in both V1.1 and all future Microsoft Visual Studio .NET releases. ASP.NET mobile controls inherit from the base ASP.NET server controls and add the ability to dynamically generate code that’s optimized for the mobile device on which the Web application is rendering. These mobile devices can be anything from full-featured, PDA browsers to small, five-line, 20-character mobile phone displays. Removing these device-specific rendering decisions allows architects and developers to focus on their Web application logic and extend existing business logic to new devices quickly.
Native database drivers
V1.0 shipped with the OLEClient and SQLClient namespaces to optimize access to SQL Server databases and databases with OLE drivers. But many companies have either invested in newer database technologies that can take advantage of features not offered efficiently by OLE drivers or have an investment in legacy systems that require the use of older ODBC drivers. Both of these drivers were made available as Web downloads after V1.0 shipped, but now V1.1 includes drivers for both of these scenarios.
Many of my corporate engagements over the last year have required access to Oracle databases. Although I used the beta versions of the Oracle driver or the OLE provider for many projects, I can now count on the Oracle driver being accessible with any V1.1 installation. The .NET Framework Data Provider for Oracle extends the System.Data namespace with a new OracleClient namespace, providing access to Oracle databases using the Oracle Call Interface (OCI) provided by Oracle’s Client software. You can find out more about the .NET Framework Data Provider for Oracle in “Access Oracle data with .NET’s new managed provider.”
For databases that only provide ODBC interfaces, the .NET Framework Data Provider for ODBC provides a System.Data.Odbc namespace, which you’ll also find is included in V1.1. I’ve tested it with many older databases and even with MySql running on Linux. It works well as long as the underlying ODBC driver is efficient.
The most significant new functionality in V1.1 is the addition of the .NET Compact Framework (CF) version of the runtime. The CF is a rewrite of the common language runtime, Windows Forms controls, and other .NET Framework features designed to work efficiently on small devices. It also supports a large subset of the .NET Framework class library that Microsoft optimized for small devices. The CF will support devices including the Pocket PC 2000, Pocket PC 2002, Pocket PC 2002 Phone Edition, and custom-designed embedded devices built with the Windows CE .NET 4.1 operating system. Microsoft also recently announced that the CF will be extended later this year to allow developers to create applications for their SmartPhone (formerly Stinger) platform.
The addition of CF is significant because application developers have largely ignored the CE platform in the past unless they had C++ skills. VB developers had to use an interpreted, poorly performing platform called embedded Visual Basic (eVB) to develop applications for CE. Those applications wouldn’t even run unless they also deployed the eVB runtime. C++ developers could write applications using eVC, but even they had a difficult time developing efficient applications, as eVC requires an intimate knowledge of the hardware, controls, and threading model to create usable applications. Until recently, CE developers had to use a crippled ADO data access library (ADOCE) and a first-generation version of SQL Server CE as their database platform.
The new CF changes all of that for the better. It brings the benefits of managed code (such as memory management, code reliability, and language neutrality) to CE devices and unifies the desktop and server programming models. The CF provides seamless connection to XML Web services and rich data access features, including many XML classes and core ADO.NET functionality. The SQLServerCE namespace allows developers to create applications that access data using Microsoft SQL Server 2000 Windows CE 2.0. Although many of the underlying platform features are exposed through classes, the CF allows developers to access native platform features using P/Invoke. For more background on CF, see “What will you find in the .NET Compact Framework?”
Companies that began deploying applications on V1.0 will be pleased to know that V1.1 supports side-by-side execution, enabling system administrators to store and execute multiple versions of an application or component on the same computer. Side-by-side execution means that you can have multiple versions of the .NET Framework and multiple versions of applications and components that use different versions of the Framework on the same computer at the same time. This doesn’t mean that a V1.0 application is automatically compatible with V1.1, but it does mean that a managed application can select which Framework version it and its components will execute under. Further, system administrators can control the version that an application will use through the application’s configuration file.
The major security change for V1.1 involves how .NET handles Windows Forms assemblies that originate from the Internet security zone. Dynamic distribution of Windows Forms applications is one of the best features of the .NET Framework, and the V1.1 release makes distribution easier without compromising security. Applications can be loaded either through the Web browser or programmatically using the System.Reflection.Assembly.LoadFrom method. In either case, V1.1 gives applications the permissions necessary to execute in a semi-trusted manner. The default security policy has been changed starting with V1.1 so that assemblies assigned by the common language runtime to the Internet security zone code group will receive the constrained permissions associated with the Internet permission set. V1.0 releases gave these applications permissions associated with the Nothing permission set and required administrators to set up custom permissions so that they could execute. Remember that this code still runs in a very restricted manner and may access only a limited set of resources that are safe to use. The code can neither damage your system, nor access any private information unless you expressly allow it.
A reason to deploy
V1.1 includes other significant improvements in area of scalability and performance. There’s also a new ASP.NET code security model that should make it easier to deploy applications with unique security requirements on the same machine—a huge benefit to hosting companies. Overall, the combination of new features and the fit and finish of V1.1 should encourage application designers to actively develop applications for the .NET Framework.
Subscribe to the Developer Insider Newsletter
From the hottest programming languages to commentary on the Linux OS, get the developer and open source news and tips you need to know. Delivered Tuesdays and Thursdays