dotNet

Migration of desktop applications to the web using Visual WebGui

The following is the first part of a 3 parts series of articles ppublished on VisualWebGui website describing the various available migration options of desktop/smart client applications to the web using Visual WebGui migration tool.

In order to discuss the migration process of legacy desktop applications to the web, we should first agree on 3 different types of desktop applications:

  1. WinForms based desktop application (C#/VB.NET). The UI layer is coded using .NET languages – the business can be .NET, COM+ or any other interop.
  2. VB 6.0 based applications. The UI layer is coded with VB 6.0.
  3. Other desktop or smart client technologies (C++ MFC/ATL, Delphi, Java etc). Any other smart client technology based applications.

WinForms based desktop applications to Web
Background
Normally, without Visual WebGui the migration process of a WinForms desktop application to the web will require a full re-engineering of the UI layer to fit the web architecture and capabilities.

If we take WinForms migration to ASP.NET for example using any AJAX 3rd party controls in order to provide a rich UI experience, we will have to consider:

  • Entirely new API.
  • Entirely new update approach.
  • Entirely new look & feel – or work hard to customize the UI to look the same.
  • Lighten the amount of data transferred to the client and presented at any given time to avoid severe latency.
  • Compromise on features list due to the web limitations.
  • Handling security holes created as a result of opening services consumed by client side AJAX and transferring business logics to the client.

Visual WebGui SDK is fully integrated with Visual Studio and provides the exact same API and set of tools/capabilities which are provided out-of-the-box with WinForms 1.0 and 2.0. This fact enables the native capability of simply copying any existing WinForms source code to a VWG project and providing a fully functional equivalent web application.

The Process
The basic 3 steps of migration (view a walkthrough tutorial):

  1. Open a new Visual WebGui application.
  2. Copy the code from your WinForms project into this new web application.
  3. Replace any reference to WinForms API namespace (“System.Windows.Forms”) within the code to Visual WebGui API reference (“Gizmox.WebGUI.Forms”).

Any standard WinForms application which is using the 58 WinForms out-of-the-box controls will then compile and execute as a plain web application.

The outcome of this short process is an ASP.NET based solution in terms of deployment and runtime and has the following properties:

  • Deployment is copy & paste equivalent to an ASP.NET web site.
  • Server infrastructure requires an IIS and .NET CLR only.
  • The application can be consumed from any plain browser - no installation is made on the client.
  • Minor static and cached footprint on the client ~200kb of plain JS and HTML code due to the Empty Client concept.
  • Support for multiple presentation layers with the same code base (DHTML/Silverlight or Smart Client).
  • Maintain a single layer of code – no need to write or maintain JavaScript, HTML and services.
  • Highly secured due to the Empty Client concept.

Considerations & Exceptions
There are 3 major setbacks you might have on the process which you can quantify in advance and estimate the amount of work that has to be done in order to migrate your application:

  1. Minor differences between the VWG API and WinForms which are mainly caused by architecture differences.
  2. The amount of 3rd party controls that are used in your application. This section describes a situation of using some non-WinForms out-of-the-box controls (for example Infragistics or DevExpress controls etc). In those cases you can select the most suitable solution from the following 3 options:
    • Choose a similar control from the WinForms out-of-the-box, adjust your code to use it and then perform the migration process.
    • Select an equivalent 3rd party ASP.NET control (Infragistics, Telerik, DevExpress etc.) which provides the same functionality, wrap it by a click of a button in VWG and adjust your code to use it.
    • Write your own VWG custom control which will perfectly suit your needs and then adjust your code after the migration process to use this control.
  3. Adjustments of a single user desktop application to a multiuser web environment. This section summarizes some of the major issues of transforming a single user application to a multiuser application sharing the same CPU, Memory space and other resources.
    • Thread safety – since a WinForms application can contain static members which are accessible to a single user, you should now consider one of the following:
      • Replacing those static members to a synchronized multi-thread safe data structures.
      • Lock critical read/write sections to protect concurrent multi user access.
      • Remove the statics and find instance or DB based solutions.
    • Memory load – in a desktop application, there might be places when the original consideration of the amount of memory in use was based on the assumption that the executing machine is local. therefore, many items are loaded to memory simultaneously without limitation.

Now, on a shared memory environment, when the server does the heavy lifting, the amount of memory consumed by each user will set the number of concurrent users that can be served by each server.

The following steps are recommended:

  • Consider loading items to memory on demand (keep only the headers and the identifiers in memory).
  • Remove any large objects read to memory – for example, don’t save binary objects to memory, instead write the binary to the response stream directly to the client.
  • Prefer DB based paging on entire prefaces and memory based paging. Visual WebGui provides mechanisms to enable it easily.

Summery
Migration of any WinForms application to the web using Visual WebGui has the following advantages:

  1. In 3 simple steps you will be able to get very close to a working web application.
  2. The effort you have to make in order to accomplish a fully functional web application is measurable.
  3. The application can keep using the existing BL and DL layers, and only the UI is either migrated automatically or adjusted.

Click to read the remaining articles:
VB 6.0 to Web
Smart Client and other Technologies to Web

or to view the tutorial:
How to Migrate WinForms to the Web

Visual WebGui 6.2.2 SDK Released

The 6.2.2 release provides compatibility to MS Silverlight RC0/RTW, and now supports development & deployment of web applications with the latest Silverlight technology. As stated before, Microsoft has released Silverlight 2 with weak backwards compatibility to previous Silverlight versions, which resulted in some presentation issues with the Silverlight layer that are now solved.

The new release also includes the Visual WebGui WinForms-like designer allowing simple and cost-effective Web development, and the new ASP.NET Control wrapper wizard introduced earlier this month.

Version 6.2.2 provides further stabilization to 6.2 which brought new standards in developer experience. for more information please read the official announcement.

The new Visual WebGui SDK is now available for download.

Full Silverlight compatibility with the upcoming VWG 6.2.2

Hi,

As announced before on Visual WebGui.com, the 6.2.2 release which is expected to be released later this week will provide compatibility to MS Silverlight RC0/RTW.

As you probably know, Microsoft recently released a new version of Silverlight which provides almost no compatibility backwards to older Silverlight versions. This means that all the released VWG Silverlight applications will not work with this new MS Silverlight version.

Furthermore, Microsoft triggered an automatic update mechanism inside Internet Explorer to have the Silverlight ActiveX update without asking. As a result, all computers with MS Silverlight client installed on it have the new version, unless the user manually removed it.

Since Microsoft released this incompatible version, our Silverlight development team has been working very hard on modifying Visual WebGui to get in line with those changes and support the new MS version once again. We were also promised by Microsoft director in Silverlight group that this was the last back compatibility breaking.

Learn more about developing Silverlight Applications with Visual WebGui

The new Visual Studio integration demonstrated on Webcast

On Nov 24 at 9am PT, Visual WebGui will be presenting another Webcast as part of the MSDN Webcast series:
Integrating Visual WebGui into Visual Studio Simplifies Development and Saves Time and Money

In this webcast, we will demonstrate the new integration, usability & compatibility features introduced with version 6.2.

Attend this webcast to learn how the Visual WebGui platform increases productivity when developing AJAX DHTML and Microsoft Silverlight applications, saving time and money. And learn about Visual WebGui's complete integration into the Microsoft Visual Studio development system, a consolidated installation process, and the opportunity to use Microsoft Visual Studio Express Editions for software evaluation and trials.

Register online

Visual WebGui 6.2.1 SDK released

I would like to share with you the release announcement of Visual WebGui 6.2.1 SDK made last week by Gizmox.
The Visual Webgui SDK now incorporates both the DHTML and the Silverlight and enables to work with both .NET 2.0 and 3.5 on the same machine. In addition, the new release includes the new wrapper feature announced earlier.

Version 6.2 presented some important enhancements mainly to the developer experience as it introduced a complete integration into Visual Studio, a consolidated installation process and compatibility with Visual Studio Express edition and DharpDevelop.

Here is a more detailed about this version description:

New feature Summary
ASP.NET Control Wrapper wizard Asp.Net Wrapper wizard added to Visual WebGui infrastructure.
This wizard enhances Visual WebGui abilities and allows you to use any ASP.NET thirdparty control that you have and add it to you Visual WebGui application as an out ofthe box control. Making Visual WebGui applications even richer than before.

Issue Summary
VWG-2721 Tabbing between controls bug solved
VWG-3097 Problems with Flow Layout Panel bug solved
VWG-3140 Integration package and source control problems solved
VWG-3189 Installation prerequisites warnings & errors issues fixed
VWG-3143 DateTimePicker in Time Format with ShowUpDown set to true AM/PM problem fixed
VWG-2363 TextBoxValidation IntegerMaskValidator fixed and dosent allows non-numeric characters
VWG-3139 Now you can install 2.0 and 3.5 at the same time
VWG-3178 Unnecessary padding was removed from bottom RibbonBarGroup
VWG-3130 EnterKeydown event Problem was fixed and is now fired
VWG-2460 TreeView events issues solved
VWG-3077 DataGridView border fixed
VWG-2699 Anchor in HtmlBox fix
VWG-3078 Session state serialization under IIS fixed
VWG-3076 Charting in catalog fixed
VWG-3033 Theme registration in VS2005 solved
VWG-3061 Problem with controls events in FlowLayoutPanel solved

The Visual WebGui framework is available as a free download here

Wrap any ASP.NET control with Visual WebGui

Visual WebGui is about to release an ASP.NET Control Wrapper which will be included in the upcoming SDK release.

The ASP.NET Control Wrapper enables the adaptation of any ASP.NET component to a VWG control, whether bought from a third party such as Infragistics, Telerik, DevExpress, etc, or created independently. This will surely increase the richness of your control library by utilizing any available ASP.NET control.

The new wrapping feature is not only useful but also simple to use. In a few quick steps the desired control is "wrapped" and ready to use in a VWG project by dragging & dropping it.

The VWG development team is working extremely hard these days in order to make it into the next Visual WebGui release which is expected in the next few days.
Stay tuned for more detailes as it is released on www.VisualWebGui.com.

The 'Empty Client' AJAX Approach

The new 'empty client' approach lead by Visual WebGui to AJAX is set to offer fundamental, infrastructure solutions to the three major setbacks of AJAX listed bellow. This approach shifts all processing, including UI logic to server, much like the old Main Frame paradigm did, and leaves the web client empty.

The first setback of traditional AJAX is the complexity in creating AJAX application for enterprise's scenarios which is time consuming and therefore brings doubtful ROI. The second setback is that there is a lack of AJAX technologies that can support high level data centric enterprise applications. The last but not least in importance, is security concerns as AJAX is known to raise real security concerns which enterprise applications with sensitive data cannot tolerate.

If the client is empty, everything is processed on the server. This concept enables highly productive, desktop development methodologies for web development as well as allowing complex applications running responsively on the network. Finally, since there is no data, no logic and no open services on the client, this approach presents a highly secured alternative to conventional client-side AJAX.

You can read more about the design time and runtime advantages of the 'empty client' AJAX on VisualWebGui.com

Develop Web with WinForms

Visual WebGui is an innovative framework for developing data intensive web applications based on its revolutionary 'empty client' platform.

The VWG framework empowers developers to build & deploy AJAX / Silverlight applications atop its platform using WinForms desktop methodologies and still allowing full flexibility, scalability, performance, security or complexity.

While conventional AJAX requires developers to program using a number of different client-side and server-side languages in multi level architecture, the 'empty client' platform enables the use of a single model with one layer. This allows developers to focus on what they want to achieve rather than on how to do so.

The reason is because the 'empty client' approach could supply well known desktop methodologies for web development. This leads to a much simpler design patterns and lets developers design highly interactive, data rich applications with basically the same productivity of designing desktop applications by dragging and dropping controls.

In addition, it is possible to provide pre-defined application blocks with the 'empty client' approach as most of the processing is done on the server. This drives up even more the efficiency and productivity of developing AJAX and enables the customization and extension of .NET components.

The Next Great Language

Tagged:  

Actually, the title should be "The Next Great Mid-Level Language", but doesn't sound quite as snappy...

There has been a lot of talk in the last year or two about Java losing ground to newer languages and about which language is going to replace Java as the dominant language going into the next decade. Various factions from the Ruby and Scala camps have weighed in on the debate in earnest, leaving even some die-hard Java programmers wondering if they should be learning a new language (and soon). After all the smoke clears, what should the reasonable person conclude? Is it time to move on?

Streaming Server Side Proxy in .NET

If you want to get XML data from a different domain you will need to use a server side proxy. While you could use JSON to get around this there are times when a JSON feed may not be available and a proxy must be used.

In the past I have written posts about creating such a proxy, however all of the example code was is PHP. Well, if you are a .NET developer then you are in luck, because the CodeProject has posted a tutorial on creating a Server Side Proxy in .NET.

Below is an excerpt from the post.

A Basic Proxy Such a content proxy is also available in my open source Ajax Web Portal Dropthings.com. You can see from its code from CodePlex how such a proxy is implemented. The following is a very simple synchronous, non-streaming, blocking Proxy:

[WebMethod]
[ScriptMethod(UseHttpGet=true)]

public string GetString(string url)
{
        using (WebClient client = new WebClient())
        {
            string response = client.DownloadString(url);
            return response;
        }
    }
}   
 

Although it shows the general principle, but it's no where close to a real proxy because:

  • It's a synchronous proxy and thus not scalable. Every call to this
    web method causes the ASP.NET thread to wait until the call to the
    external URL completes.
  • It's non streaming. It first downloads the entire
    content on the server, storing it in a string and then uploading that
    entire content to the browser. If you pass MSDN feed URL,
    it will download that gigantic 220 KB RSS XML on the server and store
    it on a 220 KB long string (actually double the size as .NET strings
    are all Unicode string) and then write 220 KB to ASP.NET Response
    buffer, consuming another 220 KB UTF8 byte array in memory. Then that
    220 KB will be passed to IIS in chunks so that it can transmit it to
    the browser.
  • It does not produce proper response header to cache the response on the server. Nor does it deliver important headers like Content-Type from the source.
  • If external URL is providing gzipped content, it decompresses
    the content into a string representation and thus wastes server memory.
  • It does not cache the content on the server. So, repeated
    call to the same external URL within the same second or minute will
    download content from the external URL and thus waste bandwidth on your
    server.

So, we need an asynchronous streaming proxy that transmits
the content to the browser while it downloads from the external domain
server. So, it will download bytes from external URL in small chunks
and immediately transmit that to the browser. As a result, browser will
see a continuous transmission of bytes right after calling the web
service. There will be no delay while the content is fully downloaded
on the server.

You can read the full tutorial here.

This post not only shows you haw to make a basic server side proxy, but also shows you how to make it streaming. If you are a .NET developer looking to make a server side proxy, I recommend this post.

Syndicate content