Merge pull request #114 from FritzAndFriends/dev

Cleanup code

Author: csharpfritz

.editorconfig

@@ -12,3 +12,8 @@ csharp_style_var_for_built_in_types = true:error
 csharp_style_var_when_type_is_apparent = true:error
 csharp_style_var_elsewhere = true:error
 csharp_prefer_braces = true
+
+# Remove compiler warnings
+dotnet_diagnostic.CS0618.severity = none		## Obsolete warning
+dotnet_diagnostic.CS1591.severity = none		## XML Documentation warning
+dotnet_diagnostic.CS1574.severity = none		## XML Documentation reference warning

.gitignore

@@ -10,6 +10,7 @@
 *.sln.docstates
 *.ncrunchproject
 *.ncrunchsolution
+*.swp
 
 # Project XML documentation
 BlazorWebFormsComponents.xml
@@ -339,4 +340,4 @@ ASALocalRun/
 # macOS
 .DS_Store
 .AppleDouble
-.LSOverride
+.LSOverride

BlazorMeetsWebForms.sln

@@ -38,6 +38,12 @@ Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "SolutionInfo", "SolutionInf
 		version.json = version.json
 	EndProjectSection
 EndProject
+Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "watch", "watch", "{A4769DEE-1006-4D87-B20E-E875C556B3E8}"
+	ProjectSection(SolutionItems) = preProject
+		scripts\watch.csproj = scripts\watch.csproj
+		scripts\watchtest = scripts\watchtest
+	EndProjectSection
+EndProject
 Global
 	GlobalSection(SolutionConfigurationPlatforms) = preSolution
 		Debug|Any CPU = Debug|Any CPU

README.md

@@ -12,7 +12,7 @@ We believe that Web Forms applications that have been well maintained and provid
 
 This is not for everyone, not everyone needs to migrate their application.  They can continue being supported as Web Forms for a very long time (2029 EOL at the time of this writing) and the applications that are considered for migration to Blazor may be better suited with a complete re-write.  For those applications that need to be migrated, this library should help make that process simpler by providing components with the same names, markup, and functionality as previously available.
 
-[Strategies for your migration and steps ahead](docs/Migration/README.md) are available as part of this repository.
+[Get started with your migration, steps ahead, and strategy documentation](docs/Migration/readme.md) for various controls and tools used are available.
 
 Portions of the [original .NET Framework](https://github.com/microsoft/referencesource) are contributed to this project under their MIT license.
 
@@ -52,9 +52,10 @@ We will NOT be converting any DataSource objects, Wizard components, skins or th
 
 ## Utility Features
 
-There are a handful of features that augment the ASP<span></span>.NET development experience that are made available as part of this project in order to support migration efforts.  These features include:
+There are a handful of features that augment the ASP<span></span>.NET development experience that are made available as part of this project in order to support migration efforts.  Importantly, these features are NOT implemented the same way that they are in Web Forms, but rather have the same API and behave in a proper Blazor fashion.  These features include:
 
   - [DataBinder](docs/Databinder.md)
+  - [ViewState](docs/ViewState.md)
 
 ## Compiling the project
 

docs/Migration/Custom-Controls.md

@@ -0,0 +1,3 @@
+# Custom Controls Migration Strategy
+
+>> Content to come!

docs/Migration/MasterPages.md

@@ -0,0 +1,3 @@
+# MasterPages
+
+>> Content to come!

docs/Migration/NET-Standard.md

@@ -0,0 +1,26 @@
+# .NET Standard to the Rescue
+
+.NET Standard is the definition of a contract, a series of APIs, that all .NET frameworks must implement to be considered a .NET framework.  .NET Framework, .NET Core, Xamarin, and Mono all implement various .NET Standard versions (or specifications) and this now becomes a vehicle for you to build your class libraries to be re-usable across various version of .NET.
+
+>> Needs links to the .NET Standard specifications and repository on GitHub
+
+Class libraries can be built and target different version specifications of .NET Standard.  You can target _ANY_ version of .NET Standard and gain compatibility across .NET Framework and .NET Core, but we recommend you target at least _.NET Standard 2.0_
+
+>> Add image showing compatibility table of .NET Standard
+
+## Implications
+
+For your existing Web Forms applications, unless you are executing unsafe code or p-invoking methods, you should be able to migrate much of your application's business logic to a .NET Standard targeting class library.  This has several benefits:
+
+1. You can migrate your business logic to the .NET Standard class library project, reference that project, and continue to use that logic in your ASP<span></span>.NET Web Forms application.
+1. Your new .NET Standard class library project can be _DIRECTLY_ referenced by your migrated ASP<span></span>.NET Core / Server-side Blazor application
+1. Your business logic code is now isolated from your presentation code, and should be more testable.  Write some unit tests to verify that your business logic is behaving properly.
+1. If you'd like to write a mobile application to work with your web application, you can re-use your .NET Standard project with the Xamarin frameworks.
+
+## Sample 1: Update an existing class library
+
+The first sample demonstrates updating a simple class library to .NET Standard.  In this model, we're assuming that you already have your business logic code properly separated from your user-interface and managed inside a class-library project that targets .NET Framework 4.5.  You can find the source and directions for this sample in the [samples/netstandard-1](samples/netstandard-1) folder.
+
+## Sample 2: Refactoring Business Logic
+
+The second sample shows how to take an existing ASP<span></span>.NET application and refactor our some business logic as a .NET Standard project.  You can find the source and directions for this sample in the [samples/netstandard-2](samples/netstandard-2) folder.

docs/Migration/README.md renamed to docs/Migration/Strategies.md

@@ -4,6 +4,10 @@ Migration from ASP<span></span>.NET Web Forms to Blazor is not simple and this r
 
 We, the maintainers of this project, believe that with a little ingenuity the markup from a Web Forms application can be copied over with minimal changes and function similarly to its original purpose.  We believe that well formatted and maintained code in Web Forms should be easily migrated.  Applications that are a significant mix of C# and markup will have a more difficult time going through this process.
 
+## Readiness Planning
+
+Migrating an application to Blazor is not a trivial process and it would be great to have some indication ahead of time how much work is needed and what steps you need to take to prepare to migrate.  Check our migration [readiness document](../migration_readiness.md) to help determine how much work will be needed for your application to begin the process.
+
 ## Known Required Changes
 
 There are several changes that are going to need to be made to the markup in your ASPX and ASCX files in order to get them working.  Some of these are obvious changes, and some are considerations necessary for the razor templating and Blazor rendering engine.
@@ -26,23 +30,45 @@ Components are the building blocks for Blazor, just as controls were in Web Form
 
 ### MasterPages are no more
 
-The concept of a MasterPage does not exist in Blazor.  Instead, your ASPX pages will be loaded inside of a host page.  You can compose a razor component that hosts other *converted ASPX pages* but your pages cannot dictate their parent container.  See the MasterPage strategy below for more details.
+The concept of a MasterPage does not exist in Blazor.  Instead, your ASPX pages will be loaded inside of a host page.  You can compose a razor component that hosts other *converted ASPX pages* but your pages cannot dictate their parent container.  See the [MasterPage strategy](MasterPages.md) below for more details.
 
 ### Page Directive Changes
 
+### No <%#: DataBinding expressions 
+
+Databinding expressions in Web Forms let you evaluate the content of the elements and format them appropriately for presentation.  For editor controls, it also allows you to setup a 2-way binding so that you can receive values entered into the same variable bound to the control.
+
+In Blazor, for repeater-style components, just format the variable using context, Item, and simple formatting like this:
+
+```csharp
+@Item.ShipDate.ToString("D")
+```
+
+For editor components, simply `@bind` the variable to the component.  This will give you two-way data-binding and the ability to handle changes in the editor component AS it changes.
+
+```html
+<input type="text" name="foo" @bind="bar" />
+```
+
 ### No Namespaces, No Tag-Prefixes 
 
-Namespaces and tag-prefixes are gone.  You can do a Find and Replace on asp: and remove those from your markup.
+Namespaces and tag-prefixes are gone.  You can do a Find and Replace on `asp:` and remove those from your markup.
+
+### Redirect Color to WebColor
+
+This change should **NOT** require any coding modifications.  In Web Forms, you could refer to `System.Drawing.Color` objects when setting `BackColor`, `BorderColor`, and `ForeColor` to name a few properties.  You could _ALSO_ freely use HTML hex-color notation freely in these fields.  
+The `System.Drawing.Color` object does not have a converter that allows you to convert between these two formats, so we wrapped the object and made `BlazorWebFormsComponents.WebColor` that performs the same task and allows the interchange of `System.Drawing.Color` object with HTML hex notation.
 
 ## Strategies
 
 - A simple initial site migration
 - Intertwined code
 - [DataBinder](Databinder.md)
 - Model-Binding
-- .NET Standard to the rescue!
+- [.NET Standard to the rescue!](NET-Standard.md)
 - Other considerations
-  - MasterPage
+  - [MasterPage](MasterPages.md)
     - Rearchitecting Web Application Layout
   - UserControls
     - The simple conversion
+  - [Custom Controls](Custom-Controls.md)

docs/Migration/User-Controls.md

@@ -0,0 +1,3 @@
+# User Controls
+
+>> Content to come

docs/Migration/migration_readiness.md

@@ -0,0 +1,42 @@
+# Web Forms Application Migration Readiness
+
+This document is intended as a primer for prospective teams to review in preparation for migrating their Web Forms applications to Server-Side Blazor.  We believe the migration is a multi-step process and this application review and preparation is the first step in migrating / rewriting an application using Blazor.
+
+## Definitions
+
+Throughout this document, we will refer to several framework and technology terms.  This section will clarify those terms.
+
+- **Web Forms**
+  - The ASP<span></span>.NET user-interface technology that started with the release in 2002 and is typically identified by applications with web pages that have a `.ASPX` file-extension
+- **MVC**
+  - Model-View-Controller architecture introduced in 2009 as an alternative user-interface framework for ASP<span></span>.NET developers.  A project structure that uses the MVC framework typically has 3 or 4 folders in it named `Areas`, `Models`, `Views`, `Controllers`
+- **Razor Views**
+  - The template technology uses by modern ASP<span></span>.NET MVC and ASP<span></span>.NET Core applications.  Typically, these files are found in the `Views` folder and have a `.cshtml` file-extension
+
+## High-Level Requirements
+
+- ASPX in-line Visual Basic not supported on Razor components in .NET Core
+  - Convert to C# or move out to a class library
+- No data source controls on ASPX pages
+- Business logic needs to be convertible to .NET Core
+- Class libraries referenced need to be convertible to .NET Standard
+- No 3rd party control libraries that don't have a shim for conversion (none available at the time of this writing)
+
+## Application architecture suggestions
+
+- Prefer model-binding techniques over handling Form life-cycle events like `Init`, `Load`, `PreRender`, and `Unload`
+  - These event-handlers do not exist and function the same way in Blazor.  Avoid acting outside of the `Load` event.  The actions you are taking in `Load` can be executed at the conclusion of the `Initialize` event in Blazor
+- Use a repository pattern with interfaces declared for the repositories
+  - Inject the concrete implementation of the data access technology.  It _MAY_ change to HTTP access at some point in the future
+- Minimal code embedded in ASPX files - this code will need to be updated to work with the components, where they were using full-featured controls.
+- No calls through the control hierarchy.  E.g. `FindControl()`
+- Any hybrid applications that contains both MVC and Web Forms user interface content will take some extra work to be converted, as the MVC components will need to be converted to ASP<span></span>.NET Core
+- `System.Confuguration.ConfigurationManager` access will need to be rewritten to use `Microsoft.Extensions.Configuration.IConfiguration` objects that are injected
+  - Push configuration access to a repository class object that can be migrated to the new Configuration model in .NET Core
+- `HttpContext.Current` access will need to be reevaluated.  Direct `HttpContext` access should be avoided in Blazor
+- Custom components will need to be rewritten
+- User controls `.ASCX` files should be converted to Blazor components
+- HttpHandlers and HttpModules will need to be rewritten as ASP<span></span>.NET Core middleware
+- MasterPages can be converted to Layout components
+- Mobile device detection is not available as part of Blazor.  `Site.mobile.master` will not be directly used by the framework.
+  - Instead of using an alternate rendering strategy for mobile, we recommend you embrace an adaptive rendering strategy to ensure that mobile device visitors to your application get a good experience