The basic idea is as follows: . . . → Read More: ASP.NET MVC 3 Hosting :: Async jQuery Progress Indicator for Long Running Tasks ASP.NET MVC 3]]> If you have long running (server side) tasks in your ASP.NET MVC 3 web application it could be reasonable to provide the user with information about the current progress of this task. In this blog post I will show how such a progress indicator could be implemented using jQuery and AJAX.

The basic idea is as follows: Two actions exists on the server side; one action starts the (long running) task in a new thread and returns a unique identifier (GUID in this example) to the client and the second action returns the current (percentaged) status for a specific task. 

For simplicity, in this example all (server side) functionality is implemented in the HomeController:

public class HomeController : Controller
{
  private static IDictionary<Guid, int> tasks = new Dictionary<Guid, int>();

  public ActionResult Progress(Guid id)
  {
    return Json(tasks.Keys.Contains(id) ? tasks[id] : 100);
  }
}

The HomeController uses a Dictionary to save the progresses of all tasks. The Start action adds a new entry to this dictionary (with progress 0) and starts a new Task that simulates the long running operation. It is important to understand that this (time-consuming) operation is running in a separate thread and server immediately returns a result to the client (the unique identifier of the task), i.e. there is no HTTP request that is open as long as the task runs. The Progress action just returns the progress for a given GUID that uniquely identifies a task. Both actions return a JSON-result to enable easily processing of the data on the client side.

The client side functionality is implemented in the Index.cshtml view:

<script type="text/javascript">

<div></div>

On the client side the jQuery function $.post() is used to

• first “call” the URL Home/Start to start a new task
• and then periodically pass the returned GUID to the URL Home/Progress to get the current progress.

To show some feedback to the user a <p> tag is created for each started task and periodically updated with the current progress.

Note: The approach shown above supports multiple parallel running tasks. You can click the “start” link while other task(s) are still running.

The code shown above is only exemplary. In a real-world project one should implement a robust error handling to support for example situations where the tasks are interrupted. Furthermore it could be reasonable to limit the number of parallel tasks one user could start, since long running tasks are often need much resources.

As developers, we like to be able to break our applications into reusable components. That makes development and maintenance much more manageable. Sometimes, however, it can have an impact on performance. The more . . . → Read More: ASP.NET 4.5 Hosting :: Streamlined Web Loading in the Visual Studio 2011]]> One of the features of Visual Studio 11 that I’m really looking forward to taking advantage of is CSS and JavaScript minification and bundling.

As developers, we like to be able to break our applications into reusable components. That makes development and maintenance much more manageable. Sometimes, however, it can have an impact on performance. The more CSS style sheets and JavaScript files you add to a page, the longer that page will take to download – and it’s not just a matter of the size of the files; the number itself is a problem. Http requests are expensive; the more you have, the slower your page is to load, even if the absolute size of the downloaded files is not very large.

Visual Studio 11 comes with two new features that make it more practical to break our JavaScript and CSS into multiple file. Bundling and minification give us a means of ‘componentizing’ our Web applications, without taking the performance hit of too many http requests. Bundling allows you to combine multiple files into a single larger file. Minification removes unnecessary white spaces to ensure that the new file is as small as possible. Taken together, the two techniques have a major impact on performance.

There are two versions of the functionality: the simple, automatic way; and the much more useful custom approach. In the simple version, the contents of folders are automatically bundled and minified if your <link> and <script> tags to point at the default directories and don’t specify individual files, thus:

<link href=”/Content/css” rel=”stylesheet” type=”text/css” />

That gets converted into html along these lines at runtime:

<link rel=”stylesheet” type=”text/css” href=“/Content/themes/base/css?v= UM624qf1uFt8dYtiIV9PCmYhsyeewBIwY4Ob0i8OdW81″ />

That’s fine as far as it goes, but is also rather limiting. You have to use default locations, and there’s no scope for having different bundles for different versions of your application.

The MVC4 template comes with a feature that’s designed to support this – ResolveBundleUrl():

<link href=”@System.Web.Optimization.BundleTable.Bundles.ResolveBundleUrl (“~/Content/css”)“ rel=”stylesheet” type=”text/css” />

Now we can define our own custom bundles. In my case, I can create two new sub-folders under the style and script paths, one for mobiles and one for the standard Web site:

Then I change the paths passed to ResolveBundleUrl() to point at my new folders….

<link href=”@System.Web.Optimization.BundleTable.Bundles.ResolveBundleUrl(“~/Content/site/css”)“ rel=”stylesheet” type=”text/css” />

<script src=”@System.Web.Optimization.BundleTable.Bundles.ResolveBundleUrl(“~/Scripts/site/js”)“></script>

and… it doesn’t work.

Although ResolveBundleUrl() supports adding non-default paths, you have to do a little more work and register your new paths in the application start event in the Global.asax before it can use those paths

This tells the system that we’re adding two bundles – one for .css files and one for .js, and that all the files in the specified directories should be part of the bundle. (You can also specify individual files if you need to control the loading order beyond the default settings, which first prioritize known libraries like jQuery, then load the files alphabetically).

One nice additional feature is that the bundles are cached on the browser using the generated path (e.g. css?v=UM624qf1uFt8dYtiIV9PCmYhsyeewBIwY4Ob0i8OdW81). This means that not only are they loaded faster the first time the user visits the site, they do not need to be downloaded again the next time. More significantly, if any of the files in the bundled folder changes, so does the generated path. That means your users will never be stuck with old versions of your style sheets or JavaScript files.

<authentication mode="Forms"> <forms loginUrl="~/Account/LogOn" timeout="2880" /> </authentication>

It is my preference for users to “Sign in” instead of “Log on” so I changed the web.config to the following and . . . → Read More: ASP.NET MVC Hosting :: Unauthenticated User Always Redirected to ~/Account/LogOn Despite Custom Sign In Url]]>

By default new ASP.NET MVC projects redirect any unauthenticated users who request resources that require authentication to the /Account/LogOn action. The log on page is defined in the web.config authentication section.

<authentication mode="Forms">
<forms loginUrl="~/Account/LogOn" timeout="2880" />
</authentication>

It is my preference for users to “Sign in” instead of “Log on” so I changed the web.config to the following and changed the action method name from LogOn to SignIn.

<authentication mode="Forms">
<forms loginUrl="~/Account/SignIn" timeout="2880" />
</authentication>

After the change I tried accessing a page that required the user to be authorized with and unauthorized user and to my surprise, the site redirected me to /Account/LogOn and I got a 404 error saying the the resource could not be found. It turns out this is a known issue with the ASP.NET MVC when the WebMatrix.Data.dll and WebMatrix.DataWeb.dll are added to the deployable assemblies collection. This issue can be fixed by adding the following key to the appSettings section of the web.config.

<appSettings>
...
<add key="loginUrl" value="~/Account/SignIn" />
</appSettings>

I presume this will be fixed in the next release of ASP.NET MVC as a bug has been logged on Microsoft Connect here.

MVC4 is really trying to break new ground in helping developers get to market more quickly and with a product that adheres to the emerging standards of today. A tough thing to ask of any technology, to be sure, but it’s making some decent strides in the right direction.

Already the tutorials and blogs posts are popping . . . → Read More: .NET MVC 4 Hosting :: New Things to Learn in ASP.NET MVC 4]]> Introduction

MVC4 is really trying to break new ground in helping developers get to market more quickly and with a product that adheres to the emerging standards of today. A tough thing to ask of any technology, to be sure, but it’s making some decent strides in the right direction.

Already the tutorials and blogs posts are popping up quicker than mushrooms on the midden heap. We highlight a few here that you definitely shouldn’t miss which deal with key upcoming features…

ASP.NET MVC  4 Hosting

If you are looking for a QUALITY, AFFORDABLE host that supports ASP.NET MVC 4 Hosting, you can take a look at ASPHostCentral.com

ASP.NET MVC 4 Overview – Part 2

Jon Galloway goes into some significant detail here about some of the changes coming our way in the new version. He talks about the new default templates that come out of the box and the reasoning behind them.

He also talks about the new adaptive rendering taking advantage of CSS media queries and the usage of the viewport meta tag to help improve the mobile user experience. Overall a solid post that will stand the test of time. Check it out…

ASP.NET MVC 4 Bundling and Minification

Bundling and Minification of assets have to be two of the most tedious things to setup on a new web project. In this excellent post, David Hayden goes through exactly what you need to do to make the process as seamless as possible in MVC4.

Don’t make the mistake of leaving this to the end of the project. You’ll have deployment nightmares you didn’t dream of and you’ll be kicking yourself for not smoothing out the wrinkles. Do it early, and you’ll thank yourself everyday for that small mercy…

Micro ORM Data Mapping with PetaPoco and ASP.NET MVC 4

Getting tired of working with the verbosity of Entity Framework classes and mapping? Well, you’re not the only one, and in this quality post, Greg Arroyo takes us for a lap around the track using PetaPoco as your Micro ORM in MVC4.

Micro ORMs really are here to stay, and in some ways, more broadly applicable to web applications of today where everyone is trying to keep things more simple. If you haven’t tried one yet, take this opportunity to get clued up on these fantastic tools.

ASP.NET MVC 4 Web API Routes and ApiController

Once again David Hayden masterfully takes us through a key piece of architecture that is going to be very important to anyone who will be working with MVC4. He details what seems to be a very slick piece of integration work between the new Web API framework and MVC4, and he throws in some OData queries for good measure.

It’s short and sweet, and just enough to get you going, and whet your appetite for how to architect your solutions around your own APIs, allowing for more decoupled designs with less possible points of failure.

Getting started on your first Single Page Application

As with the introduction of any new method now encompassed in a technology, it’s best to start with what comes straight from the horse’s mouth. This Walkthrough put together by Brad Severtson gives you a great introduction, and leaves the mind boggling as to the possibilities.

If you’ve ever wanted to build your own Gmail and specifically wanted to do it with MVC, then go ahead, knock yourself out! (no pun intended)..

These are the list of differences which I came across while working on ASPand ASP.NET projects.

Background

I have seen many articles on Internet where in I came across the differences of ASP.NET and ASP. These articles are jumbled across the websites. I have compiled all those and published this article to give better understanding on the differences . . . → Read More: ASP.NET Hosting :: What is the Difference Between ASP.NET and ASP]]> Introduction

These are the list of differences which I came across while working on ASPand ASP.NET projects.

Background

I have seen many articles on Internet where in I came across the differences of ASP.NET and ASP. These articles are jumbled across the websites. I have compiled all those and published this article to give better understanding on the differences of both.

Description

Process Isolation

ASP is run under the inetinfo.exe(IIS) process space and hence susceptible to application crashes as a result the IIS needs to be stopped or restarted. ASP is related to the process isolation setting in IIS.

But, ASP.Net

The ASP.NET worker process is a distinct worker process, aspnet_wp.exe, separate from inetinfo.exe ( IIS process), and the process model in ASP.NET is unrelated to process isolation settings in IIS.

Note :- IIS is still the entry point to a ASP.NET application

Non-MS Platform Support

Classical ASP had no mechanism of running itself on non- Microsoft technology platforms like the ‘The Apache Web Server’

But, ASP.NET

ASP.NET could be run on non-Microsoft Platforms also. Cassini is a sample Web server produced by Microsoft which, among other projects, has been used to host ASP.NET with Apache.

Multi Language Support in WebPage

In ASP only two languages were available for scripting VBScript and Jscript/Javascript.

But in ASP.NET

We are no longer constrained to the two scripting languages available in traditional ASP: Any fully compliant .NET language can now be used with ASP.NET, including C# and VB.NET.

Note :- (C# and VB.Net are both server Side languages.)

Interpretation Vs Compilation

In ASP, ASP engine executes server-side code, which is always through an interpreter (JScript or VBScript). When a traditional ASP page is requested, the text of that page is parsed linearly. All content that is not server-side script is rendered as is back to the response. All server-side script in the page is first run through the appropriate interpreter (JScript or VBScript), the output of which is then rendered back to the response. This architecture affects the efficiency of page rendering in several ways. First, interpreting the server-side script on the fly.As a side effect, one common optimization for ASP applications is to
move a lot of server-side script into precompiled COM components to improve response times. A second efficiency concern is that intermingling server-side evaluation blocks with static HTML is less efficient than evaluating a single server-side script block, because the interpreter has to be invoked over and over again. Thus, to improve efficiency of rendering, many ASP developers resort to large blocks of server-side script, replacing static HTML elements with Response.Write() invocations instead. Finally, this ASP model actually allows different blocks of script within a page to be written in different script languages. While this may be appealing in some ways, it also degrades performance by requiring that a particular page load both scripting engines to
process a request, which takes more time and memory than using just one language.

But in ASP.NET,

In contrast, ASP.NET pages are always compiled into .NET classes housed within assemblies. This class includes all of the server-side code and the static HTML, so once a page is accessed for the first time (or any page within a particular directory is accessed), subsequent rendering of that page is serviced by executing compiled code. This eliminates all the inefficiencies of the scripting model of traditional ASP. There is no longer any performance difference between compiled components and server-side code embedded within a page they are now both compiled components. There is also no performance difference between interspersing server-side code blocks among static HTML elements, and writing large blocks of server-side code and using
Response.Write() for static HTML content. Also, because the .aspx file is parsed into a single code file and compiled, it is not possible to use multiple server-side languages within a single .aspx file.

Debugging benefits

In classic ASP it was very difficult for us to debug the application. ASP developers had time to debug application due to limited support due to the interpreted model.

But in ASP.NET In addition to improved performance over the interpreted model, pages that are compiled into classes can be debugged using the same debugging tools available to desktop applications or component developers. Errors with pages are generated as compiler errors, and there is a good chance that most errors will be found at compilation time instead of runtime, because VB.NET and C# are both strongly typed languages. Plus, all the tools available to the .NET developer are applicable to the .aspx developer.

Server-Side code placement Web Page

class=docText>Especially if you are using ASP pages it is possible to include executable code outside the scope of a function within a script block marked as runat=server, and , it is possible to define a function within a pair of server-side script tags.

But in ASP.NET,

In ASP.NET it is no longer possible to include executable code outside the scope of a function within a script block marked as runat=server, and conversely, it is no longer possible to define a function within a pair of server-side script tags.

Note also that the generated class definition provides a default constructor for you, and if you try to define your own default constructor within your page, it will cause a compiler error. This can be somewhat frustrating if you are trying to properly initialize elements of your class (such as filling up our array of values or subscribing to events).
Fortunately, an alternative technique gives you more complete control over the class definition while separating the layout from the page logic. This technique is called code-behind.

Deployment Strategies

In traditional ASP applications, components used by pages and deployed in this fashion were notoriously difficult to update or replace. Whenever the application was up and running, it held a reference to the component file so to replace that file, you had to shut down IIS (temporarily taking your Web server offline), replace the file, and restart IIS.

But in ASP.NET,

The goals of ASP.NET was to eliminate the need to stop the running Web application whenever components of that application need to be updated or replaced that is, updating an application should be as simple as using xcopy to replace the components on the Web server with the new updated versions. To achieve this xcopy deployment capability, the designers of ASP.NET had to ensure two things: first, that the running application not hold a reference to the component file and second, that whenever the component file was replaced with a new version, that new version was picked up with any subsequent requests made to the application. Both of these goals are achieved by using the shadow copy mechanism provided by the Common Language Runtime (CLR).

Shadow copying of assemblies is something you can configure when you create a new application domain in .NET. The AppDomainSetup class (used to initialize an AppDomain) exposes a Boolean property called ShadowCopyFiles and a string property called CachePath, and the AppDomain class exposes a method called SetShadowCopyPath() to enable shadow copying for a particular application domain. The Boolean property turns the mechanism on for a particular application domain, the CachePath specifies the base directory where the shadowed copies should be placed, and the SetShadowCopyPath() method specifies which directories should have shadow copying enabled.

ASP.NET creates a distinct application domain for each application it hosts in its worker process and for each application domain, it enables shadow copying of all assemblies referenced in the /bin directory. Instead of loading assemblies directly from the /bin directory, the assembly loader physically copies the referenced assembly to a separate directory (also indicated in the configuration settings for that application domain) and loads it from there. This mechanism also keeps track of where the assembly came from, so if a new version of that assembly is ever placed in the original /bin directory, it will be recopied into the Noteshadow” directory and newly referenced from there.

In addition to shadow copying of assemblies, ASP.NET needs the ability to create and load assemblies on the fly. The first time an .aspx page is referenced, as we have seen, it is compiled into an assembly and loaded by ASP.NET. What we haven’t seen is where those assemblies are located once they are compiled. Application domains also support the concept of a “dynamic directory” specified through the DynamicBase property of the AppDomainSetup class, which is a directory designed for dynamically generated assemblies that can then be referenced by the assembly loader. ASP.NET sets the dynamic directory of each application it houses to a subdirectory under the system Temporary ASP.NET Files directory with the name of the virtual directory of that application.

One consequence of both dynamic assembly generation and shadow copying is that many assemblies are copied during the lifetime of an ASP.NET application. The assemblies that are no longer being referenced should be cleaned up so that disk space usage doesn’t become a limiting factor in application growth. In ASP.NET shadow copied assemblies are removed as soon as possible after a new version of that assembly is copied, and dynamically generated assemblies that are no longer used are cleaned up the next time the ASP.NET worker process is bounced and the particular application associated with the dynamic assemblies is run again. In general, this means that you shouldn’t have to worry about unused assemblies generated by ASP.NET wasting space on your machine for very long.

New Page Directives

In ASP you must place all directives on the first line of a page within the same delimiting block. For example:

But in ASP.NET, you are now required to place the Language directive with a Page directive, as follows:

You can have as many lines of directives as you need. Directives may be located anywhere in your .apsx file but standard practice is to place them at the beginning of the file. Several new directives have been added in ASP.NET. I encourage you to look these up in the ASP.NET documentation to see how they may benefit your application.

Threading Issues

The threading model of COM object created using VB within a web-based application is STA. ASP worker thread resides in its own STA and hence the compatability is fine in this case with a little performance hit.

But in ASP.NET,

The ASP.NET threading model is the Multiple Threaded Apartment (MTA). What this means is that components that you are using that were created for the Single Threaded Apartment (STA) will no longer perform or function reliably without taking some extra precautions in ASP.NET. This includes, but is not limited to, all COM components that have been created using Visual Basic 6.0 and earlier versions. You will be glad to hear that you can still use these STA components without having to change any code. What you need to do is include the compatibility attribute aspcompat=true in a <%@Page> tag on the ASP.NET page. For example, <%@Page aspcompat=true Language=VB%>. Using this attribute will force your page to execute in STA mode, thus ensuring your component will continue to function correctly. If you attempt to use an STA component without specifying this tag, the run time will throw an exception. Setting this attribute to true will also allow your page to call COM+ 1.0 components that require access to the unmanaged ASP built-in objects. These are accessible via the ObjectContext object. If you set this tag to true, your performance will degrade slightly. I suggest doing this only if you absolutely need to.

Validation & Browser scripting capabilities

• ASP has no inbuilt facility for Validation of controls.i.e, checking whether a textbox is left blank or not or a combo is selected or not or if a phone number does not fit a particular pattern for a area and many such examples.

• The user had to write the client side Javascript code for all these kind of validations.

• Client and server side validation both were the headache of the of the developer.

• Javascript code to fit a particular Browser was also the developer’s burden. He had to write specific code so that it could fit a set of browsers. It took lot of the developers time.

But in ASP.NET,

In built validation controls are provided which are as easy to implement and the developer has to worry the least.

The features provided by ASP.NET validation controls is :-

• Browser Independent coding :- Developer does not have to worry about the browser how the controls would render to.

• Client-Side or Server-Side :- The Validation Controls manage the code checking if the client side code is disabled the validation is done on the server side.

Rich Validation set :- There are 6 types of validation which cater to the needs of the validation requirements:

• RequiredFieldValidation Control – Requires that the control not be left blank.

• CompareValidator Control – Used to compare Data in Two Controls

• RangeValidator Control – Used to check for Range validation.(also supports various data Type – Date , string etc..)

• RegularExpressionValidator Control – Used to check the complicated patterns in the user input.

• CustomValidator Control- The final control we have included in ASP.NET is one that adds great flexibility to our validation abilities. We have a custom validator where we get to write out own functions and pass the control value to this function.

This control also provides Client side and server side validation of which the Server side validation could be a different function altogether.

• Validation Summary – The validation summary control will collect all the error messages of all the non-valid controls and put them in a tidy list. The list can be either shown on the web page (as shown in the example above) or with a popup box

Conclusion

This article targets to the developers who have directly started working on ASP.Net and also for the web developers who have migrated from ASP to ASP.Net. This article is at the draft level and might need additions which I intend to do.I welcome suggestion or criticism!! I would request to add as much feedback to this article post as possible. I would keep this post updated.