Migrating from ASP.NET 1.1 to ASP.NET 2.0 Scott Guthrie Web Platform and Tools Team Microsoft Corporation

Agenda Migrating from ASP.NET 1.X to ASP.NET 2.0 Visual Studio 2003 to Visual Studio 2005 Conversion

Migrating from ASP.NET 1.X to ASP.NET 2.0

ASP.NET 1.X to ASP.NET 2.0 Goal: Easy to upgrade from V1.1 to V2.0 –We have minimized breaking changes –No OS upgrade required Runs on Windows 2000 & IIS 5.0 Runs on Windows XP & IIS 5.1 Runs on Windows Server 2003 & IIS 6.0 Please Let us know if you find issues with Beta2

ASP.NET 1.X to ASP.NET 2.0 ASP.NET 1.1 & 2.0 can be installed on same machine –Application versions run side-by-side under IIS –Version used identified by IIS vroot ISAPI script-mappings Installing v2.0 on v1.1 server preserves existing v1.1 application mappings –V1.1 applications do not automatically get updated to use V2.0 –Administrator must manually update application using IIS Admin Tool Existing ASP.NET v1.1 applications should run fine using ASP.NET v2.0 –But always test application prior to deployment to verify

Issue Tracker – V1.1 Issue Tracker – V1.1 version running on top of ASP.NET 2.0

ASP.NET 1.X to ASP.NET 2.0 It is possible to upgrade parts of a site to ASP.NET V2.0 while leaving the rest of it to run under ASP.NET V1.1 – on V2.0 and on V1.1http://foo.mysite.comhttp:// – on V2.0 and on V1.1http:// Forms Authentication can work across both ASP.NET versions –To enable in ASP.NET 2.0 you must explicitly set decryption attribute in the machineKey section to 3DES ASP.NET 2.0 encryption default of AES is not compatible with 1.1 Tickets issued in 1.1 are then consumable by ASP.NET 2.0 Tickets issued by ASP.NET 2.0 are then consumable by 1.1 app

Sharing forms authentication tickets

ASP.NET 1.X to ASP.NET 2.0 New ASP.NET reserved directory names (App_) –New naming convention for protecting directories –Avoid naming directories with this prefix ASP.NET Reserved directories –/Bin – Reserved for assemblies. Same as 1.0 and 1.1 –/App_Code – Reserved for code –/App_Data – Reserved for data storage (*.mdf,.xml, etc.) –/App_Themes – Reserved for theme files (.skin) –/App_WebServices – Reserved for.wsdl files –/App_Resouces – Reserved for local page resource files –/App_GlobalResources – Reserved for global resource files

ASP.NET 1.X to ASP.NET 2.0 XHTML compliance switch –XHTML compliant markup is now emitted by default –Good for standards compliance, but can break some UI –Web.config file setting to use older HTML markup rendering –Set this to help with migration of existing sites –Recommend updating pages to be XHTML compliant long-term

ASP.NET 1.X to ASP.NET 2.0 Other XHTML issues: –New pages created using VS2005 include a DOCTYPE directive indicating XHTML 1.1 compliance –IE will render page in browser differently if DOCTYPE present Remove the DOCTYPE to get older html rendering behavior –In future you should update your HTML to be XHTML compliant

ASP.NET 1.X to ASP.NET 2.0 Well known client-side script files are now encapsulated as resources –.js files are now referenced like: WebResource.axd?a=s&r=WebUIValidation.js –Hand-editing WebUIValidation.js file will no longer work –Use the expanded client-side scripting support in ASP.NET 2.0 for enabling common client-scripting scenarios instead

ASP.NET 1.X to ASP.NET 2.0 Potential for naming collisions with existing source code –2,000+ new classes in V2.0 –Common name collisions: Membership, Roles, Profile, Theme Name collisions do not affect already compiled binaries –CLR automatically picks the correct type to use in this case –Name collisions will affect you if you re-compile your project source Recommend you identify collision candidates today –Use a fully qualified class name when referencing these types (e.g. MyProject.Membership instead of Membership) –Alternatively use an alternative class name to avoid future issues

Visual Studio 2003 to Visual Studio 2005 Conversion

Visual Studio Conversion VS 2005 makes significant changes to web projects –Provides much more flexibility for web scenarios Key Benefits: –No more project file required –Web projects no longer compiled into single DLL –Web projects can now be written in multiple languages –No need to re-compile project when making changes –Ability to update pages/code while using the debugger –Significantly cleaner and more robust code-behind model

Visual Studio Conversion VS 2005 converts existing VS 2003 projects on open –One way conversion (cannot open in VS 2003 afterwards) –Always enable backup option as part of upgrade wizard –ConversionReport.txt lists all changes as part of the upgrade Things to be aware of during conversion: –New directories may be created (App_Code, App_WebReferences) –Non-page related class files (.cs,.vb) will be moved to App_Code dir –“Designer generated” sections are processed by the conversion tool –Pages automatically updated to use new code-behind model Recommendations when running under source control: –Move project to new location on disk (out of source control) –Open project and run the conversion wizard –Check back into source control

Visual Studio Conversion New Code-Behind Model –Removes need for VS to generate/modify code in your code-behind –Control definition now handled using new partial class feature of V2 compilers –Still enables definition of custom base pages + control classes Syntax differences: –ASP.NET 1.1 page definition –ASP.NET 1.1 code-behind class definition public class WebForm1 : System.Web.UI.Page –ASP.NET 2.0 page definition –ASP.NET 2.0 code-behind class definition public partial class WebForm1 : System.Web.UI.Page

ASP.NET 2.0 Code-behind Default.aspx Page codefile=“default.aspx.cs” inherits=“Default” public partial class Default : System.Web.UI.Page Default.aspx.cs File containing code behind class definition File containing code behind class definition Class that the page-gen inherits from Class is ‘partial’ and is combined to an auto-generated partial class Base class. Can be defined by user. The required ancestor base class is System.Web.UI.Page Dynamic Compile Auto- generated page class MyClass Auto- generated partial Default Partial class defined in codefile DefaultSystem.Web.UI.Page

Issue Tracker – After running the conversion wizard

Visual Studio Conversion New dynamic compilation model implications: –Monolithic code-behind assembly is no longer used Instead, pages are compiled on-demand into separate assemblies –Code-behind code that references classes defined within other code-behind files will fail Move these classes out of code-behind files into standalone.cs and.vb files (can use App_Code directory or separate assembly) –Best practice to prepare for this with ASP.NET 1.1: Move classes, enumerations and interfaces that are not related to a page into standalone.vb or.cs files now In addition to making migration easier it is a better coding practice

Cross file class references

Visual Studio Conversion New dynamic compilation model implications: –Type casting dynamically loaded user controls requires an explicit reference to the.ascx files In 1.1, since all code lived in the same assembly, user control type names were always available for type casting –In 2.0, add page directive MyControl ctl = (MyControl) Page.LoadControl(“ctl.ascx”); Note: This is not needed if you don’t explicitly cast control

Visual Studio Conversion New dynamic compilation model implications: –Code that calls Type.GetType(“SomeType”) will fail if referencing classes in other code-behind files or in files deployed in App_Code –Instead, use: System.Web.Compilation.BuildManager.GetType The ASP.NET BuildManager has extra logic to “look” at all ASP.NET related assemblies VS 2005 project migration wizard will update code that does this

Type Resolution

Visual Studio Conversion Developers can pre-compile an ASP.NET site with: –aspnet_compiler.exe command line tool –“Publish Website” menu option within VS 2005 Two choices when pre-compiling: –All code compiled and.aspx markup removed –All code compiled, but.aspx preserved for later html edits (note: this is new in Beta2 and now the default)

Application Pre-compilation

Session Summary ASP.NET V1.1 and V2.0 run side-by-side on same server –No need to migrate all apps in order to start using V2.0 Backwards compatibility a priority with new APIs and features –Please tell us in Beta2 when you find things that break VS 2005 auto upgrades existing web projects to use new project model –Provides significantly better flexibility for web projects –Need to be aware of a few implications of dynamic compilation model Things to-do today to prepare for ASP.NET V2.0: –Start making HTML markup XHTML compliant –Separate non-codebehind classes/enums into separate class files –Avoid class naming conflicts with new V2.0 features now where possible

© 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

APPENDIX

Demonstration Four Issue Tracker – Converting pages to use as a master page

Designing for ASP.NET 2.0 Rich data-binding to middle tier objects is now possible –Many Web applications require the use of clearly defined middle tiers –Traditionally has been awkward to use with data-binding ObjectDataSource supports two-way data binding to objects –Allows developers to write changes back to the database –Two-way functionality only supported on new ASP.NET 2.0 data controls

Designing for ASP.NET 2.0 Middle tier object design guidelines –Objects should be stateless Example: Need to be able to call select method one page hit, but process an update on postback. –Need a default parameter-less constructor –Expose methods for select, insert, update and delete functionality (static methods are preferred but not required) –Methods should accept zero or more parameters to carry out the appropriate operation

Designing for ASP.NET 2.0 Middle tier object design guidelines –Objects that use the following pattern will not be able to update/insert data via ObjectDataSource: MyType myObject = new MyType(); myObject.PropertyA = “foo”; myObject.PropertyB = “bar”; myObject.Update(); –Instead use: MyType myObject = new MyType(); myObject.PropertyA = “foo”; myObject.PropertyB = “bar”; MyType.Update(myObject);

ASP.NET 2.0 Runtime Designing for ASP.NET 2.0 should include designing for runtime improvements Design with caching in mind –New cache features covered in earlier presentations –Design “Everett” applications to take advantage of ASP.NET 2.0 cache improvements –User Control encapsulation will help! –Web sites with clean middle tiers can easily use Sql cache dependencies –Datasource controls have built-in support for Sql cache dependencies

ASP.NET 2.0 Runtime OLEDB is now supported in partial trust –1.1 applications using Microsoft ® Access always needed full trust –ADO.NET team enabled partially trusted callers in ASP.NET 2.0 –Hosters can now use for customers using Access

ASP.NET 2.0 Runtime Forms authentication support on querystrings –Forms auth ticket can be encrypted and automatically placed on the querystring –Enables forms auth for both desktop and mobile browsers –With extra coding, also enables passing authentication information across Web sites Enables a custom pseudo-”SSO” Remember that key material still needs to be synchronized

ASP.NET 2.0 Runtime Richer event model in Http pipeline –Most events now have a “PostXYZ” event PostAuthenticateRequest PostAuthorizeRequest Etc. –Allows more granular Http module authoring –Eliminates request ordering issues where certain modules must logically run before an event Example: PostAuthenticateRequest can be used for authorization logic prior to AuthorizeRequest

ASP.NET 2.0 Runtime Richer event model in Http pipeline –Do choose the appropriate event for the work your module performs –Don’t use Http modules as a “pseudo-handler” Use.ashx files or custom handlers –If your module sends response headers Hook both EndRequest and PreSendRequestHeaders Send response headers in the first event that is called. Ignore the second event firing.

ASP.NET 2.0 Runtime Synchronous page execution –Traditionally - work performed on pages runs synchronously –Ties up an ASP.NET worker thread for the duration of the request –1.1 pages are synchronous –performing async calls in page code did not help –Somewhat convoluted design pattern was necessary to truly handle async work in “Everett” pages

ASP.NET 2.0 Runtime ASP.NET 2.0 Asynchronous Pages –New page directive “Async” –Two event delegates need to be implemented in page code –Async processing occurs just before PreRender event Design Guideline –Isolate long-running tasks in their own object –Design pages to defer long-running tasks to the async event delegates

Demonstration Five Issue Tracker – Converting project list to an async page

ASP.NET 2.0 Runtime Request prioritization –New “requestPriority” attribute on –Can set per vdir using tags –Can group sets of pages into directories according to desired priority “Critical” pages will always be queued for execution –“High” priority pages execute before “Normal” priority pages –“Normal” is the default priority

ASP.NET 2.0 Runtime Buffered Uploads –Handles large file uploads –Large SOAP headers when calling.asmx pages –Large Http requests New attribute “requestLengthDiskThreshold” on –If request length exceeds limit (256Kb default), content is spooled to disk –Minimizes memory overhead for concurrent large requests

ASP.NET 2.0 Runtime Protected Configuration –Allows any configuration section in ASP.NET 2.0 to be encrypted –Built-in support for RSA and DPAPI Extensible support allows custom encryption with custom providers –A custom protected configuration provider does not necessarily need to “encrypt” anything Could instead load configuration information from an off-the-box location

ASP.NET 2.0 Runtime IIS6: requests can run through ASP.NET and “fall back out” to IIS –Enables ASP.NET authN/authZ for non-ASP.NET file extensions –Instead of the page handler running, the request is passed to DefaultHttpHandler Request is handed off to the ISAPI extension associated with the file type IIS5: ASP.NET has an optimized StaticFileHandler (.jpg,.htm, etc.) –Dynamic content (i.e..asp) not supported though

ASP.NET 2.0 Runtime Health Monitoring –Built-in support for logging various event information and errors to providers –Can store event information in different data stores with custom providers –ASP.NET 2.0 automatically logs errors to the event log Comprehensive information for tracking down problems on production servers where debug access is usually not available Look at Health Monitoring before writing a custom event infrastructure

Demonstration Six Health Monitoring – Event Log Entries

Providers Uses new Provider Design pattern –Pluggable Data Access Layer (DAL) –Pluggable Business Logic Layer (BLL) We are shipping Providers for various data stores: –SQL Server –AD/ADAM Provider model is extensible –Create and integrate new providers

New ASP.NET ASP.NET 2.0 “Building Block” APIs Role Manager Site Navigation Management Provider Model Design Pattern Providers Windows SQL Server AD/ADAM Database Caching ASP.NET 2.0 Developer Stack Membership Profile and Personalization

New ASP.NET ASP.NET 2.0 “Building Block” APIs Role Manager Site Navigation Management Provider Model Design Pattern Providers Windows SQL Server AD/ADAM Database Caching Custom public class OracleMembershipProvider : MembershipProvider {} public class As400MembershipProvider : MembershipProvider {} ASP.NET 2.0 Developer Stack Membership Profile and Personalization

Providers Can design for these APIs today –Follow method and property conventions depending on which feature you plan to use –Add your own custom behaviors Browse the provider specification on MSDN ® as well as ASP.NET 2.0 help files –Plan to implement classes as a provider –Easier to move a provider to ASP.NET 2.0 –Carry forward today’s investment

Demonstration Seven Issue Tracker – Custom Membership provider for handling login