Friday, August 26, 2016PrintSubscribe
Deploying Web Site Factory Project to Azure

Microsoft Azure is composed of a collection of integrated cloud services. It enables easy storage of databases and deployment of web applications to the Internet, without having to deal with the hassle of infrastructure maintenance. When it comes time to offer your application to a larger number of users, your services can be scaled easily to fit your needs. Azure offers pay-as-you go services to scale up or down to match demand.

Let’s deploy a sample Northwind Web Site Factory project to Azure using Visual Studio 2015.

Start the app generator, click on the project name, and press “Develop” to open the project in Visual Studio.

Opening Northwind project in Visual Studio.

In the Solution Explorer (F4), right-click on the “WebSite” node and press “Publish Web App”.

Publishing a web app from Visual Studio.

In the list of publish targets, select “Microsoft Azure App Service”.

Publishing to Microsoft Azure App Service.

If you have not logged into your Microsoft account, enter your credentials in the login window that appears and proceed to log in.

In the App Service window, press “New..” to create a new resource group for your application.

Creating a new resource group for Azure.

Assign a Web App Name to this deployment. Next to App Service Plan, press “New…”.

Specifying a web app name and app service plan for the azure deployment.

Select an app service plan suitable for your deployment. Every tier provides different compute capabilities and features at different price points.

Please note that a dedicated (non-shared) app service plan must be selected in order for reports to be generated. The smallest available size that enables the use of reporting is “Basic – 1” (B1).

Configuring an app service plan for the web app.

Press “OK” to save the app service plan. Then, click “Create” to create the required Azure resources.

When the process is complete, the Publish screen will open with pre-filled values. Leave the values as default and press “Next” to configure settings.

The Publish configuration has been automatically populated.

Check the box next to “Remove additional files at destination”. This will ensure that the deployment directory will match the local directory.

Enabling removal of additional files at the destination.

Press “Publish” to deploy your application to the cloud. When publish is complete, the application will open in your default web browser.

Including Report Viewer DLLs

If Reporting is enabled in the web application, a server error will be displayed. ReportViewer DLLs must be included in the published app.

Open File Explorer by pressing Win+E, and navigate to


Open the folder for the version of Report Viewer required by your application. Applications using “.NET 4.6” require version 12.

Right-click on the DLL file and press “Copy”.

Creating a copy of the ReportViewer DLL.

In Visual Studio’s Solution Explorer, right-click on “WebSite” project node and press “Add | New Folder”.

Adding a new folder to the project.

Assign the name “bin” to the folder. Right-click on the new folder and press “Paste”.

Pasting Report Viewer DLL to the bin folder.

The DLL will copy into the “bin” folder.

Copy two more DLLs, found at these locations:

  1. C:\Windows\assembly\GAC_MSIL\Microsoft.ReportViewer.Common
  2. C:\Windows\assembly\GAC_MSIL\Microsoft.ReportViewer.ProcessingObjectModel

Next, re-publish the app by right-clicking on the “WebSite” node and pressing “Publish Web App”.

Publishing the web app with report viewer DLLs.a

Then, press “Publish” to initiate the process. Once complete, the app will open in your web browser and open the home page of your application running in the cloud.

Friday, September 12, 2014PrintSubscribe
Announcing Workflow Register

Workflows in Line-of-Business Applications

Workflow is a repeatable pattern of business activity.  Business applications mirror the real-world patterns through data collection performed in sequences of user-interface screens.

Software developers create hard-coded data structures and data entry forms based on the input from business users. A line-of-business application represents the current understanding of a business process by a development team.

A successful line-of-business application eventually evolves to match the requirements of business processes in organization. The dynamic nature of a business life-cycle will require constant tweaks and fine tuning even in a successful implementation.

Application customization and deployment are very expensive and frequently disruptive. Line-of-business applications must include built-in tools to allow changing application behavior without modifying the core application code.

Procedural Workflows

Many software packages include implementations of procedural workflows. Procedural Workflow allows non-developers to describe sequences of application operations with optional conditions and loops. Procedural workflows can be presented as visual workflow diagrams or text-based scripts. Procedural workflows offer a great tool that allows altering application behavior without changing the core application.

Complexity of procedural workflows grows exponentially when business users are trying to express various exceptions that exist in real-world business processes. Procedural workflows do not offer the means of limiting access to data.

State Machine Workflows

State Machine workflows are composed of rules triggered by the state of data, user identity, and time. Each rule defines a test that allows inspecting the state of data. If the test has passed, then the rule is “triggered”. The triggered rules affect application behavior. If there is no state test, then a rule is considered to be “triggered” by the mere fact of association with the current user identity.

A state-driven rule effects a specific type of application functionality. For example, a rule with Allow type can define a filter that reduces a set of records to a smaller subset based on user identity. If the rule is “triggered”, then the filter is applied to any SQL statement reading data from the application database.  A rule with Transform type may remove data modification actions from a data entry form. If the rule is triggered, then the end user will not be able to Edit, Delete, Import or create New data records.

A large collection of rules affecting application behavior can be developed. Developers organize related rules in groups. Groups of rules are associated with users and optional schedules. Association of end users with rule groups and scheduling can be outsourced to application administrators.

The standard end user experience is defined by the implementation of line-of-business application. The rules of the state machine workflow will alter user experience based on user identity, time, and state of data.

State-based rules hide the complexity of the real-world business processes by breaking them down into small and manageable bits of functionality. State-based rules are great when it comes to implementing real-world exception. A state-based rule can define data filters, user interface alterations, business rule injection, and much more.

Adaptive Line-of-Business Apps

For the past few years we have worked on an integrated solution that will enable declarative state-machine workflows in the generated applications out-of-the-box. The goal is to enable adaptive customization of live apps without making changes to the code that require re-deployment.

We have identified the following customization requirements that must be available in a live application:

  1. Ability to define Allow/Deny filtering rules that can be applied to any data retrieved by application.
  2. Ability to create customization rules applied to XML definition of a data controller.
  3. Ability to replace an entire data controller with a substitute.
  4. Ability to create “content” and “data” pages in a live app.

Several prototypes have been developed but appeared too complex to operate.

Meanwhile developers working with Code On Time had an option to implement requirements (1), (2), and (3) on their own:

  1. Dynamic Access Control Rules -
  2. Data Controller Virtualization -
  3. Substitution of controllers -

Requirement (4) can be satisfied in SharePoint Factory and DotNetNuke Factory Projects. Both products are content management systems that allow creating pages at runtime.

This year we have finally arrived to a solution that will become integrated in the apps created as Azure Factory, Mobile Factory, Web App Factory, or Web Site Factory projects.

The solution will be rolled into a single feature called “Workflow Register”.

It will include an integrated Content Management System (CMS) as a core component of generated apps. CMS will allow creating dynamic “data” and “content” pages at runtime.

“Data” pages will include markup that uses “data-“ attributes to define data views. For example, master-detail page at is defined as follows:

<div data-flow="NewRow">
    <div id="view1" data-controller="Categories" data-view="grid1" data-show-in-summary="true"></div>
<div data-flow="NewRow" style="padding-top: 8px">
    <div data-activator="Tab|Products">
        <div id="view2" data-controller="Products" data-view="grid1" 
            data-filter-source="view1" data-filter-fields="CategoryID" 
            data-page-size="5" data-auto-hide="container" data-show-modal-forms="true"></div>

“Content” pages may contain arbitrary HTML.

Here is the screen shot of a “content” page based on popular Bootstrap framework, which will be integrated in the Code On Time release due out at the end of September 2014.


If workflow Register is enabled in a project, then the app generator will install a custom database schema to the primary database. The tables will have “ease_” prefix. The schema includes tables to support the following features:

  • Workflows - specifies Allow, Deny, Transform, Define rules that are applied to various application components, such as pages, menu items, controllers, etc.
  • Content Management System – provides storage for dynamic content, such as pages and menu items.
  • Register - global registry that associates user identity references (user IDs and roles) with workflows and optional schedules.
  • Permissions – a collection of  workflow rules associated with users.


The purpose of workflow Register is to enable management of various permissions by application administrators at runtime.

All users will have access to the Register entries associated with their user ID. Only administrators will have access to all entries in the Register.

Entries created by administrators have “Approved” status.  Users will also be able to assign workflows to themselves. Such entries will be created with “Pending” status. Only “Approved” workflow register entries will be taken into account by the application framework.

A person assigning a workflow to a user or role does not need to know the details of workflow implementation. An entry in Register may read:

Workflow Human Resources is assigned to John Doe on Tuesday, Wednesday, and Thursday starting on November 15, 2014 and ending on February 1, 2015.

User John Doe will have have access to human resources pages on the specified dates. The workflow may allow or deny access to data records exposed on the pages.

Developers will be able to create workflow rules that delegate management of Register entries to the users other than administrators.

Workflow Register comes with pre-defined data controllers and management pages exposed through “Register” menu option in generated apps.


Workflows are collections of rules defined by application developers. A developer can create a set of pre-defined workflows as a part of application at design time.  New workflow rules can be created and existing ones can be customized at runtime as needed.

Rules may affect application behavior in multiple ways. For example:

  • A filter that allows or denies access to data can be specified
  • New pages can be made available to end users
  • Data controller actions defined in the application can be dynamically altered at runtime.
  • New SQL, JavaScript, and Email business rules can be introduced in data controllers.

The rule definition system if very simple and exceptionally extensible to fit the most demanding customization requirements.

Content Management System

Content management system allows populating an application with new “content” and “data” pages.

CMS may also store images, style sheets, JavaScript, and any other files or documents.

Application workflows determine access to the content. Content may be publicly available or limited to specific individuals or groups of users.


Permissions are collections of  workflow rules matched to a user identity.

Permissions are evaluated by application framework when users access various applications resources. Application framework matches workflow Register entries with the user identity and resource type. Matched workflow rules are automatically engaged by application framework.

For example, if “Allow” rule defines a filter limiting visibility of customer records, then the filter is included in SELECT statements executed by the framework when application tries to read a list of customers.

If a workflow assignment has an associated schedule, then permission engagement will be time-sensitive.

Permissions are created by application framework on-demand directly from the workflow Register entries. Permissions are refreshed when associated workflows are changed.


We are planning to release various components of Workflow Register with each upcoming release.

The upcoming release due out by the end of month in September will include several elements of Workflow Register:

  • Support for content pages.
  • Support for declarative data pages.
  • Integrated Bootstrap framework to allow creation of compelling responsive content pages.
  • One-to-One entities support in data controllers. This particular feature is introduced to support “ease_” database tables.

Our production schedule indicates that Workflow Register will become available in November of 2014 or a sooner.

Wednesday, June 18, 2014PrintSubscribe
Deployment: Overview

The application generator launches a web browser when the app is generated and when developers select the Browse button in the Project Designer. Simultaneously, an instance of IIS Express is started with instructions to serve requests to the folder with the source code of the generated app. The launched browser is navigating to the URL served by that instance of IIS Express.

Web app with Touch UI served by IIS Express in Internet Explorer on the development machine.

IIS Express is the development version of Internet Information Services (IIS), a component of Microsoft Windows operating system designed to host web sites and applications.

If you want to try your app on other computers or mobile devices, then you will have to deploy the app to a production version of IIS. IIS Express does not allow serving remote requests from external devices.

IIS is a built-in component of Microsoft Windows 7, 8, and Microsoft Windows Server 2008, 2012.

This is how your app will look on remote devices once you have deployed it to IIS.

Map view of an app with Touch UI rendered in iPhone 5S.     Context menu of an app with Touch UI rendered in iPhone 5S.

Responsive grid view of an app with Touch UI rendered in iPad Air.

Complex master-detail page of an app with Touch UI rendered in iPad Air.

In order to prepare a machine for web hosting, a full installation of IIS must be performed. In addition, the host must have the correct version of ASP.NET (and optionally Report Viewer) installed, HTTP firewall port must be opened, and the web app must be configured as an IIS application.

Local Deployment

The easiest way to deploy your app is on your own development machine which typically runs Windows 7 or 8. This will allow you to test the app on mobile devices and allow coworkers on the same network to see it as well. You can also do this at home, in a café, or an airplane if you enable a Wi-Fi Hotspot on your laptop.


  1. Install Prerequisites for Windows 7 / Windows 8
  2. Copy App to Server
  3. Install Report Viewer 2012 (Optional)
  4. Configuring App in IIS
  5. Opening Firewall Ports
  6. Accessing the Web App

Dedicated Server Deployment

The traditional method of app deployment requires a dedicated web server. You can purchase your own server or acquire a hosted virtual machine. The examples used for the next few articles will be using Microsoft Azure Virtual Machines (VMs) hosted in Microsoft data centers around the world. Anyone in the world will have access to your production app, provided that they know the URL.


  1. Acquire a server (such as Windows Azure VM)
  2. Install Prerequisites for Windows Server 2008 / Windows Server 2012
  3. Copy App to Server
  4. Install Report Viewer 2012 (Optional)
  5. Configuring App in IIS
  6. Accessing the Web App

App Service Deployment

Microsoft Azure offers a convenient way to package and publish apps without configuration of dedicated servers called an App Service. Code On Time web apps can be deployed as an app service directly from Visual Studio.