Migrating from
[Link] 1.1 to
[Link] 2.0
David Webster
EMEA Technical Team Microsoft
Email: davidjw@[Link]
Agenda
• Migrating from [Link] 1.X to [Link] 2.0
• Visual Studio 2003 to Visual Studio 2005
Conversion
Migrating from [Link] 1.X
to [Link] 2.0
[Link] 1.X to [Link] 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
[Link] 1.X to [Link] 2.0
• [Link] 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 [Link] v1.1 applications should run fine using [Link]
v2.0
– But always test application prior to deployment to verify
Issue Tracker – V1.1
Issue Tracker – V1.1 version running on top of
[Link] 2.0
[Link] 1.X to [Link] 2.0
• It is possible to upgrade parts of a site to [Link] V2.0 while
leaving the rest of it to run under [Link] V1.1
– [Link] on V2.0 and [Link] on V1.1
– [Link] on V2.0 and [Link] on V1.1
• Forms Authentication can work across both [Link] versions
– To enable in [Link] 2.0 you must explicitly set decryption attribute in the
machineKey section to 3DES
• [Link] 2.0 encryption default of AES is not compatible with 1.1
• Tickets issued in 1.1 are then consumable by [Link] 2.0
• Tickets issued by [Link] 2.0 are then consumable by 1.1 app
Sharing forms authentication tickets
[Link] 1.X to [Link] 2.0
• New [Link] reserved directory names (App_)
– New naming convention for protecting directories
– Avoid naming directories with this prefix
• [Link] 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
[Link] 1.X to [Link] 2.0
• XHTML compliance switch
– XHTML compliant markup is now emitted by default
– Good for standards compliance, but can break some UI
• <xhtml11Conformance
enableLegacyRendering=“true” />
– [Link] 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
[Link] 1.X to [Link] 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
[Link] 1.X to [Link] 2.0
• Well known client-side script files are now
encapsulated as resources
– .js files are now referenced like: [Link]?
a=s&r=[Link]
– Hand-editing [Link] file will no longer
work
– Use the expanded client-side scripting support in
[Link] 2.0 for enabling common client-scripting
scenarios instead
[Link] 1.X to [Link] 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. [Link] 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
– [Link] 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:
– [Link] 1.1 page definition
• <%@ page codeBehind=“[Link]” inherits=“WebForm1” %>
– [Link] 1.1 code-behind class definition
• public class WebForm1 : [Link]
– [Link] 2.0 page definition
• <%@ page codeFile=“[Link]” inherits=“WebForm1” %>
– [Link] 2.0 code-behind class definition
• public partial class WebForm1 : [Link]
[Link] 2.0 Code-behind
File containing code Class that the page-gen
behind inherits from
class definition
[Link]
<%@ Page codefile=“[Link]” inherits=“Default”
[Link]
public partial class Default : [Link]
Class is ‘partial’ and is combined Base class. Can be defined by user. The
to an auto-generated partial required ancestor base class is
class [Link]
Dynamic Compile
MyClass Default Default [Link]
Auto- Auto- Partial class
generated generated defined in
page class partial codefile
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 [Link] 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 <% @Reference VirtualPath=“[Link]” %> page
directive
• MyControl ctl = (MyControl) [Link](“[Link]”);
• Note: This is not needed if you don’t explicitly cast control
Visual Studio Conversion
• New dynamic compilation model implications:
– Code that calls [Link](“SomeType”) will fail if
referencing classes in other code-behind files or in
files deployed in App_Code
– Instead, use:
[Link]
• The [Link] BuildManager has extra logic to “look” at all
[Link] related assemblies
• VS 2005 project migration wizard will update code that
does this
Type Resolution
Visual Studio Conversion
• Developers can pre-compile an [Link] 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
• [Link] 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 [Link] 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
APPENDIX
Issue Tracker – Converting pages to use as a
Demonstration Four
master page
Designing for [Link] 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 [Link] 2.0
data controls
Designing for [Link] 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 [Link] 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();
[Link] = “foo”;
[Link] = “bar”;
[Link]();
– Instead use:
MyType myObject = new MyType();
[Link] = “foo”;
[Link] = “bar”;
[Link](myObject);
[Link] 2.0 Runtime
• Designing for [Link] 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 [Link]
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
[Link] 2.0 Runtime
• OLEDB is now supported in partial trust
– 1.1 applications using Microsoft® Access always needed full
trust
– [Link] team enabled partially trusted callers in [Link] 2.0
– Hosters can now use <trust
level=“Medium” /> for customers using Access
[Link] 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
[Link] 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
[Link] 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.
[Link] 2.0 Runtime
• Synchronous page execution
– Traditionally - work performed on pages runs synchronously
– Ties up an [Link] 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
[Link] 2.0 Runtime
• [Link] 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
Issue Tracker – Converting project list to an async
Demonstration Five
page
[Link] 2.0 Runtime
• Request prioritization
– New “requestPriority” attribute on <httpRuntime>
– Can set per vdir using <location> 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
[Link] 2.0 Runtime
• Buffered Uploads
– Handles large file uploads
– Large SOAP headers when calling .asmx pages
– Large Http requests
• New attribute “requestLengthDiskThreshold” on
<httpRuntime>
– If request length exceeds limit (256Kb default), content is
spooled to disk
– Minimizes memory overhead for concurrent large requests
[Link] 2.0 Runtime
• Protected Configuration
– Allows any configuration section in [Link] 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
[Link] 2.0 Runtime
• IIS6: requests can run through [Link] and “fall back
out” to IIS
– Enables [Link] authN/authZ for [Link] 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: [Link] has an optimized StaticFileHandler
(.jpg, .htm, etc.)
– Dynamic content (i.e. .asp) not supported though
[Link] 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
– [Link] 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
[Link] 2.0 Developer Stack
ew [Link] [Link] 2.0 “Building Block” APIs
Profile and
Membership Role Manager
Personalization
Database
Site Management
Caching
Navigation
Provider Model Design Pattern
Providers
Windows SQL Server AD/ADAM
[Link] 2.0 Developer Stack
ew [Link] [Link] 2.0 “Building Block” APIs
Profile and
Membership Role Manager
Personalization
Database
Site Management
Caching
Navigation
Provider Model Design Pattern
Providers
Windows SQL Server AD/ADAM Custom
public class OracleMembershipProvider : MembershipProvider
{}
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
[Link] 2.0 help files
– Plan to implement classes as a provider
– Easier to move a provider to [Link] 2.0
– Carry forward today’s investment
Issue Tracker – Custom Membership provider for
Demonstration Seven
handling login