ASP.NET 4.0 Hosting & ASP.NET 4.5 Hosting BLOG

BLOG about ASP.NET 4.5 Hosting, ASP.NET 4.0 Hosting and .NET 4.5 Framework and its Capabilities

ASP.NET Hosting :: Working with ASP.NET Cookies

clock January 31, 2012 09:53 by author Administrator

 

 

Introduction

Cookies are also known by many names, HTTP Cookie, Web Cookie, Browser Cookie, Session Cookie, etc. Cookies are one of several ways to store data about web site visitors during the time when web server and browser are not connected. Common use of cookies is to remember users between visits. Practically, cookie is a small text file sent by web server and saved by web browser on client machine.

Use of Cookies?

Cookies may be used for authentication, identification of a user session, user's preferences, shopping cart contents, or anything else that can be accomplished through storing text data. Cookies can also be used for travelling of data from one page to another.

Is Cookies Secured?

Well, this question has no specific answers in YES or NO. Cookies could be stolen by hackers to gain access to a victim's web account. Even cookies are not software and they cannot be programmed like normal executable applications. Cookies cannot carry viruses and cannot install malware on the host computer. However, they can be used by spyware to track user's browsing activities.

Using Cookies

Creating/Writing Cookies

There are many ways to create cookies, I am going to outline some of them below:

Way 1 (by using HttpCookies class)
//First Way
HttpCookie StudentCookies = new HttpCookie("StudentCookies");
StudentCookies.Value = TextBox1.Text;
StudentCookies.Expires = DateTime.Now.AddHours(1);
Response.Cookies.Add(StudentCookies);

Way 2 (by using Response directly)
//Second Way
Response.Cookies["StudentCookies"].Value = TextBox1.Text;
Response.Cookies["StudentCookies"].Expires = DateTime.Now.AddDays(1);


Way 3 (multiple values in same cookie)
//Writing Multiple values in single cookie
Response.Cookies["StudentCookies"]["RollNumber"] = TextBox1.Text;
Response.Cookies["StudentCookies"]["FirstName"] = "Abhimanyu";
Response.Cookies["StudentCookies"]["MiddleName"] = "Kumar";
Response.Cookies["StudentCookies"]["LastName"] = "Vatsa";
Response.Cookies["StudentCookies"]["TotalMarks"] = "499";
Response.Cookies["StudentCookies"].Expires = DateTime.Now.AddDays(1);


Reading/Getting Cookies

In the above code, I have used many ways to write or create cookies so I need to write here using all the above ways separately.

For Way 1
string roll = Request.Cookies["StudentCookies"].Value; //For First Way

For Way 2
string roll = Request.Cookies["StudentCookies"].Value;  //For Second Way

For Way 3
//For Multiple values in single cookie
string roll;
roll = Request.Cookies["StudentCookies"]["RollNumber"];
roll = roll + " " + Request.Cookies["StudentCookies"]["FirstName"];
roll = roll + " " + Request.Cookies["StudentCookies"]["MiddleName"];
roll = roll + " " + Request.Cookies["StudentCookies"]["LastName"];
roll = roll + " " + Request.Cookies["StudentCookies"]["TotalMarks"];
Label1.Text = roll;


Deleting Cookies

In the above code, I have used many ways to create or read cookies. Now look at the code given below which will delete cookies.

if (Request.Cookies["StudentCookies"] != null)
{
    Response.Cookies["StudentCookies"].Expires = DateTime.Now.AddDays(-1);    Response.Redirect("Result.aspx");  //to refresh the page
}


Understanding HttpCookie Class It contains a collection of all cookie values.

We do not need to use any extra namespaces for HttpCookies class (we already have used this in Way 1 above), because this class is derived from System.Web namespaces. HttpCookies class lets us work with cookies without using Response and Request objects (we have already used this in Way 2 and Way 3 above).

HttpCookie class has a list of some properties, let us outline them.

    * Domain: It contains the domain of the cookie.
    * Expires: It contains the expiration time of the cookie.
    * HasKeys: It contains True if the cookie has subkeys.
    * Name: It contains the name of the cookie.
    * Path: It contains the virtual path to submit with the cookie.
    * Secure: It contains True if the cookie is to be passed in a secure connection only.
    * Value: It contains the value of the cookie.
    * Values:

Limitations of Cookies

There are following limitations for cookies:
   1. Size of cookies is limited to 4096 bytes.
   2. Total 20 cookies can be used on a single website; if you exceed this browser will delete older cookies.
   3. End user can stop accepting cookies by browsers, so it is recommended to check the users’ state and prompt the user to enable cookies.

Sometimes, the end user disables the cookies on browser and sometimes browser has no such feature to accept cookies. In such cases, you need to check the users’ browser at the home page of website and display the appropriate message or redirect on appropriate page having such message to enable it first. The following code will check whether the users’ browser supports cookies or not. It will also detect if it is disabled too.

protected void Page_Load(object sender, EventArgs e)
{
    if (Request.Browser.Cookies)
    {
        //supports the cookies
    }
    else
    {
        //not supports the cookies
        //redirect user on specific page
        //for this or show messages
    }
}


It is always recommended not to store sensitive information in cookies

 

 

 



ASP.NET 4.0 Hosting :: The Reasons Application Pool Recycle

clock October 31, 2011 07:43 by author Administrator

If your ASP.NET application crashes, has an unhandled exception, hangs or otherwise becomes brain-dead, it will cause the application pool to recycle. Sometimes your application pool recycles for no obvious reason. This is usually a configuration issue or it may be caused by your app performing file system operations in the application directory. Many times developers incorrectly set up SqlConnections so that they aren't properly closed and returned to the connection pool, and this can also cause your AppPool to recycle unexpectedly. When your AppPool recycles, you can kiss your InProc Sessions - and everything else -- goodbye.

Application pool settings

Looking at the properties for the application pool in IIS, you'll see the settings for "on purpose" recycling. In IIS6 these are:

- Recycle worker processes (in minutes)
- Recycle worker process (in requests)
- Recycle worker processes at the following times
- Maximum virtual memory
- Maximum used memory

If you're running IIS5 or the IIS5 isolation mode you must look at the processModel element of machine.config. The properties you should pay attention to are:

- memoryLimit
- requestLimit
- timeout

In IIS 7.o, you have Fixed Interval or Fixed # Requests, or Specific Times for recycling. Also, there are Memory -based Maximums for Virtual and Private Memory, and additional items for Configurable and Runtime recycling events including "unhealthy ISAPI".

When an application pool recycles, HTTP.SYS holds onto the client connection in kernel mode while the user mode worker process recycles. After the process recycle, HTTP.SYS transparently routes the new requests to the new worker process. Consequently, the client never "loses all connectivity" to the server; the TCP connection is not lost -- only state is lost (Application, Session, Cache, etc.).

memoryLimit
The default value of memoryLimit is 60. This value is only useful if you have a small amount memory on a 32 bit machine. "60" means 60% of total system memory. So if you have 1 GB of memory your IIS worker process will automatically restart once it hits memory usage of 600 MB.

requestLimit
This setting is "infinite" by default, but if it is set to 8000 for example, then ASP.NET will launch a new worker process once it has handled 8000 requests.

timeout
The default timeout is "infinite". This is where you set the lifetime of the worker process. Once the timeout is reached ASP.NET launches a new worker process, so setting this to "00:30:00" would recycle your application every 30 minutes.

Other properties
Another property within the processModel element that will cause your application pool to recycle is responseDeadlockInterval. If you have a deadlock then that's your main "fix" that you need to worry about -- changing the responseDeadlockInterval setting won't do much to resolve the problem. You need to deal with the deadlock itself, find out why it's happening, and change your code.

File Change Notification

ASP.NET 2.0 depends on File Change Notifications (FCN) to see if the application has been updated, and depending on the magnitude of change the application pool will recycle. If you or your application are adding and removing directories to the application folder, then you will be restarting your application pool every time.

Altering the following files also causes an immediate restart of the application pool:
- web.config
- machine.config
- global.asax
- Any file in the /bin directory or subfolders

Updating .aspx files, etc. causing a recompile eventually triggers a restart of the application pool also. There is a property of the compilation element under system.web called numRecompilesBeforeAppRestart. The default value is 20, meaning that after 20 recompiles the application pool will recycle.

Workaround for the sub-directory issue

If your application actually requires adding and removing sub-directories you can use linkd to create what's called a directory junction:

Create a directory you'd like to exclude from FCN, e.g. c:\inetpub\wwwroot\MyWebApp\MyFolder
Create a separate folder somewhere outside the wwwroot, e.g. c:\MyExcludedFolder
Use linkd to link the two: linkd c:\inetpub\wwwroot\MyWebApp\MyFolder c:\MyExcludedFolder
Now any changes made in the c:\inetpub\wwwroot\MyWebApp\MyFolder will now actually occur in c:\MyExcludedFolder so they will not be sensed by FCN.

Linkd only comes with the Windows XX Resource Kit, which is a pretty big download. But Mark Russinovitch has "junction" which could be even better:
http://www.microsoft.com/technet/sysinternals/FileAndDisk/Junction.mspx  

Is recycling the application pool good or bad?


If your app is coded properly, you shouldn't have to recycle the application pool. However, if you're dealing with a memory leak in your app and you need to buy time to fix it, then recycling the application pool could be a good idea. It's important to understand, though, that's not a "Fix" - it's just a "Band-Aid" until you find out what's causing the problem and fix your code. Unlike as with ASP.NET 1.1, in ASP.NET 2.0 if your app generates an unhandled exception the AppDomain will unload causing an application pool recycle. Consequently it is extremely important to ensure that your code is "best practices" and doesn't generate unhandled exceptions except under the most extreme and unusual conditions



Silverlight 5 Hosting with ASPHostCentral.com

clock October 18, 2011 10:31 by author Administrator

Microsoft Silverlight is a powerful tool for creating and delivering rich Internet applications and media experiences on the web. Silverlight 5 builds on the foundation of Silverlight 4 for building business applications and premium media experiences. Among other capabilities, the Silverlight 5 release candidate highlights dramatic video quality and performance improvements, and features that improve developer productivity.

The final Silverlight 5 release will be available in 2011. The following article is referenced from http://www.microsoft.com/silverlight/future/

Improved media support and rich UI capabilities

- Hardware Decode and presentation of H.264 improve performance for lower-power devices to render high-definition video using GPU support.
- TrickPlay allows video to be played at different speeds and supports fast-forward and rewind. At up to twice the speed, audio pitch correction allows users to watch videos while preserving a normal audio pitch.
- Improved power awareness prevents the screen saver from being shown while watching video and allows the computer to sleep when video is not active.
- Remote-control support allows users to control media playback.
- Digital rights management advancements allow seamless switching between DRM media sources.  

Building next-generation business applications

Silverlight 5 text (bottom) has improved clarity.
Fluid user interface enables smoother animation within the UI. Inter-Layout Transitions allow developers to specify animations to apply when elements are added, removed or re-ordered within a layout. This provides smoother user experiences when, for example, items are inserted into a list.

Text improvements make it possible to build rich magazine-style text layouts:

- Multicolumn text and linked text container allow text to flow around other elements.
- Tracking/leading set precisely how far apart each character is for full creative control.
- Text clarity is improved with Pixel Snapping.
- Text layout performance is significantly improved.
- OpenType support has been enhanced.

Printing:

- Support for Postscript vector printing enables users to create faster, higher-quality reports and documents, including the ability to create a virtual print view different from what is shown on the screen.

Controls:

- Added support for double-click and Combobox type ahead.

Model View ViewModel (MVVM) and Databinding enhancements allow more work to be done more easily via XAML:

- Debugging support now allows breakpoints to be set on a binding, so you can step through binding failures.
- Implicit DataTemplates allow templates to be created across an application to support a particular type by default.
- Ancestor RelativeSource allows, for example, a DataTemplate to bind to a property on the control that contains it.
- Binding in style setters allows bindings to be used within styles to reference other properties.
- The DataContextChanged event is being introduced. Markup extensions allow code to be run at XAML parse time for both properties and event handlers, enabling cutting-edge MVVM support.
- UpdateSourceTrigger allows immediate response to data entry, leveraging ViewModel functionality through databinding.
- Multiple Window support, enabling user to multi-task various functions within a common application.
- CustomTypeProvider, enabling post deployment configuration of product catalogs and other object definitions.
- CustomMarkupExtensions enabling better tooling and code optimization by extending XAML definitions to custom code.  

Silverlight 5 performance improvements

- Reduced network latency by using a background thread for networking.
- XAML parser improvements that speed up startup and runtime performance.
- Support for 64-bit operating systems.
- Reduced network latency by using a background thread for networking.
 
Graphics improvements

- Graphics Processing Unit (GPU) accelerated 3-D application programming interface (API) provides rich graphics on the Web for building advanced data visualizations and rich user experience (UI).
- Immediate mode graphics API allows direct rendering to the GPU.
- Hardware acceleration is enabled in windowless mode with Internet Explorer 9.

Silverlight 5 extends features of the "Trusted Application" model

Silverlight 5 extends features of the ‘Trusted Application’ model to the browser for the first time. These features, when enabled via a group policy registry key and an application certificate, mean users won’t need to leave the browser to perform complex tasks:

- Host HTML content as a web browser control within the Silverlight application. HTML pages, such as help content or e-mail, can be integrated within the application.
- Read and write files to the user’s My Documents folder, making it easier to find media files or create local copies of reports.
- Launch Microsoft Office and other desktop programs. Users can open Microsoft Outlook and create an e-mail message, or send a report to Microsoft Word utilizing the power of Microsoft Office.
- Access devices and other system capabilities by calling into application COM components. Users can access a USB security card reader or a bar-code scanner.
- Enjoy full keyboard support in full screen, which enables richer kiosk and media viewing applications. - - Call existing unmanaged code directly from within Silverlight with PInvoke.

Tools improvements

- Microsoft Visual Studio profiling support including CPU, memory, and thread contention



ASPHostCentral.com - The Importance of having a UNIQUE IP Address on your Website!

clock October 14, 2011 08:07 by author Administrator

What is an IP address?

An IP address is a set of 4 numbers assigned to each device on a computer network. When we apply this definition for the internet, the IP address can be considered a numerical representation of a website address. For example, the domain google.com would go to the IP address 73.14.213.99.

How do IP addresses work?

When you type in a domain name on your browser, your browser will first match that domain name to an IP address. Then, it will access the server at that IP address.

Why would you want a unique IP address for your website?

Websites that have unique IP addresses are more stable and more reliable.

Disadvantages of sharing an IP address:
Sharing an IP address = Higher chance of website outage

Most web hosting providers nowadays cram thousands of websites onto one server. And because IP addresses are in short supply, they will often have all of the websites that are on a server share one IP address. This practice is quite dangerous as it will jeopardize the stability and functionality of each website on the server.

If your website is sharing an IP address with 1,000 other websites on a server and one of those websites becomes blocked or blacklisted, all 1,000 of those websites, including yours, would be blocked or blacklisted as well.

Advantages of having a unique IP address:
Having a unique IP address = Increased stability and reliability for your website.

By having your own unique IP address, your website would be unaffected by the other websites that are on the same server. If a website on your server gets its IP address blocked or blacklisted, it would not affect your website since it's not sharing the same IP address.

In other words, when you have a unique IP address, your website is unaffected by the other websites that are on the server.

The internet is running out of space

The current IPv4 address pool is almost completely used up.

It was announced in early 2011 that the last batch of IP addresses have been allocated. This last batch of IP addresses will probably be used up towards the end of 2011. The current IPv4 address system has about 4.3 billion addresses. With a growing pool of internet users and internet-connected devices, 4.3 billion IP addresses are not enough to meet today's demand.

Fortunately, researchers have designed a new IP address system - IPv6. This new system has 360 undecillion IP addresses and has been available since 1999. But, it seems like the transition is slow, and we'll be stuck with IPv4 for a while. Here's why:

- Transitioning 4.3 billion IP addresses over to the new IPv6 system will take quite some time.
- Existing equipment will need to be upgraded in order to support the new IPv6 address system.
- Not many Internet Service providers (ISP) support IPv6. This means that if your ISP doesn't support IPv6, then you won't be able to access websites hosted with IPv6 addresses.
- Currently, IPv4 addresses are accessible through all ISP's, whereas IPv6 addresses are not.
With that said, the value of the existing IPv4 addresses are likely going to shoot up before IPv6 comes into play. So, make sure you get your IPv4 address before they run out!



ASP.NET Hosting :: How to send email via .NET Application

clock October 10, 2011 11:16 by author Administrator

 

.NET 2.0 has included System.Net.Mail code namespace for supporting email programming with .NET

Following is the code snippets for how to send mail from .NET application

 




ASPHostCentral.com - Steps in Changing Web Hosting Providers

clock October 4, 2011 09:45 by author Administrator

There are many reasons why individuals or companies want to change to a new web hosting company. It could be as simple as not enough storage space or bandwidth, or it could be due to its customer service, or lack thereof.

Easier said than done? Changing to a new web hosting company may sound like a daunting task, but it doesn't have to be that complex - there are just a few things to keep in mind.

1. Keep your web hosting account with your existing host open

It is recommend that you keep your existing web hosting account active until you have completed the transition steps (ie. new account setup, file transfer, email creation and setup, DNS modification and propagation).This will ensure that your website and domain email accounts will be running during the transition.

2. Choose a suitable new web hosting provider

Considerations include:

a) Type of OS (Windows vs. Linux) - it depends on the technologies your website requires. For example, if your website requires ASP, MSSQL, MSACCESS or other Microsoft-specific technologies, then you will need to find a Windows-platform web hosting plan.

b) Bandwidth and disk space requirements

3. Make a backup copy of your existing website: download old account files

Ideally, files should be downloaded in the same tree structure in which you want to upload it later. Also look for any file or chmod permissions that you might to set on any folder or file. This is a fairly easy task and can easily be accomplished by FTP.

However, some free web hosting providers do not offer FTP access. This is especially true if you're currently using a free Flash/drag-and-drop website creation service (ie. Weebly.com, WIX.com).

If this is the case, you will not be able to download your existing web files and will have to re-create your new web files. You should check to see if your new web hosting provider offers a free website creator.

To avoid running into the same problem in the future, make sure your new web hosting provider offers FTP access.

4. Setup new (same) email addresses

To ensure that emails are properly received, it is important to keep the same email addresses, including email aliases and forwarders.

5. DNS changes and propagation

Once you have uploaded your web files to the new web hosting server and re-created your email accounts, you can go ahead and make the necessary domain name server (DNS) changes.

DNS is usually obtained once you have signed up with the new web hosting provider. You will need to replace your existing DNS settings with the new one - this is usually done via your domain management panel (your domain registrar).

The new DNS will take anywhere between 24-48 hours to propagate, therefore the old web host is responsible for website and email in the meantime. This is why cancelling the old service should be the very last thing to do.

6. Cancel your old account.

Once your new account has been activated and your website and email services at your new web hosting provider are up and running, you can proceed to have your old account cancelled.



If you need assistance in migrating your website to a new host, you can contact ASPHostCentral.com. We offer migration assistance FREE of CHARGE

 



ASP.NET 4.0 Hosting :: SOLVING an error message: “Unrecognized attribute targetFramework”

clock September 22, 2011 07:32 by author Administrator

I recently upgraded from Visual Web Developer 2008 to Visual Web Developer 2010 and have run into an issue, I started seeing a configuration error. In two cases I had been working on web applications in Visual Web developer 2010.


Case 1 appeared after I had opened an existing application and when prompted, do I want to configure the site for use with ASP.NET 4.0, I must have said yes.

Case 2 came when I created a new application and my system is setup to use Framework ASP.NET 4.0

In both situations I got the following error <compilation debug="true" targetFramework="4.0" /> pointing to my web.config file. I like working in Visual Web Developer 2010, but my hosting server is not yet setup for .Net Framework 4.0, so I needed to find out how to down-grade from 4.0 to 3.5 framework.



The following is what I did to change the target Framework from ASP.NET 4.0 to ASP.NET 3.5.

1) Ensure IIS and the ASP.NET properties are configured for Framework 2.0. Note: Framework 3.5 will not show up in the list of installed options due to the fact that framework 3.5 is an extension of 2.0 and not a stand alone release


 2) Configure you web application to use target Framework 4.0 by right clicking your website in the solution explorer >> Property Pages >> Build >> Change "Target Framework" to .NET Framework 3.5.

T



ASP.NET 4 Hosting :: The Difference between Response.Redirect and Response.RedirectPermanent

clock September 20, 2011 07:46 by author Administrator

In ASP.NET 4.0 there are new features that enable developer to make SEO friendly websites very easily. And if you google out, you will find plenty of article which explain this feature. But I am more interested in Response.RedirectPermanent. As the name suggest it is used to redirect permanently moved resources to new location. And most of all articles on the net just explain this with some example. But how can we visualize that whether resource is redirected permanently or not. So here is the answer for that. I have used FireBug to examine the same


Whenever we redirect with Response.Redirect, we can see following activity in FireBug console



As we can see that page which issues Response.Redirect its response status code 302(Found) which means requested url(default.aspx) is found but it is temporarily moved to about.aspx. More information on HTTP status code can be found here.

Now whenever we redirect with Response.RedirectPermanent, we can see following activity in FireBug console



As we can see that page which issues Response.RedirectPermanent its response status code 301(Moved Permanently) which means requested url(default.aspx) is moved Permanently to about.aspx. 301 status code is used by search engine crawler to update search index to new moved information.

I hope information provided here would be more helpful to distinguish between Response.Redirect and Response.RedirectPermanent



ASP.NET Hosting :: Things to AVOID in JSON serialization

clock September 13, 2011 06:59 by author Administrator

If you’ve spent much time working with the .NET platform, ASP.NET’s simple, convention-based approach to exposing JSON endpoints seems just about too good to be true. After years of fiddling with manual settings in XML configuration files, it’s understandable to assume that working with JSON in ASP.NET would require a similar rigmarole, yet it does not.

Unfortunately, this unexpected ease-of-use isn’t obvious if you don’t already know about it, which has led some developers to build needlessly complicated solutions to problems that don’t actually exist. In this post, I want to point out a few ways not to approach JSON in ASP.NET and then show you a couple examples of leveraging the frame work to do it “right”.

A couple examples of what NOT to do

To show you exactly what I’m talking about, let’s start by looking at a few concrete examples of ways that you should not handle sending and receiving JSON in your ASP.NET services.

For all the examples, we’re going to be trying to send and/or receive instances of this Person class:

public class Person
{
  public string FirstName { get; set; }
  public string LastName { get; set; }
}

Once you progress beyond simple scalar types, sending objects (and collections of them) back and forth is a pretty logical next step, and that’s also the point where this manual serialization trouble seems to begin. So, working with this simple Person class should serve as a realistic example, without being overly complex.

Manual serialization, using JavaScriptSerializer

The most common variant of this mistake that I’ve seen is using JavaScriptSerializer to manually build a JSON string and then returning that string as the result of a service method. For example, if you didn’t know better, you might do this to return an instance of the Person class:

[ScriptService]
public class PersonService : WebService
{
  [WebMethod]
  public string GetDave()
  {
    Person dave = new Person();
 
    dave.FirstName = Dave;
    dave.LastName = Ward;
 
    JavaScriptSerializer jss = new JavaScriptSerializer();
 
    // Results in {"FirstName":"Dave","LastName":"Ward"}
    string json = jss.Serialize<Person>(dave);
 
    return json;
  }
}

This may look sensible enough on the surface. After all, the json variable does end up containing a nicely serialized JSON string, which seems to be what we want. However, you should not do this.

What actually happens

Part of the beauty of using ASP.NET’s JSON-enabled services is that you rarely have to think much about the translation between JSON on the client-side and .NET objects on the server-side. When requested with the proper incantations, ASP.NET automatically JSON serializes your service methods’ responses, even if their result is an object or collection of objects.

Unfortunately, that automatic translation also makes it easy to end up with doubly-serialized responses if you aren’t aware that ASP.NET is already handling the serialization for you, which is exactly what would happen in the preceding example. The end result is that the Person object is serialized twice before it gets back to the browser – once as part of the method’s imperative code and then a second time by convention.

In other words, it’s understandable to expect the previous code example would return this response:

{"FirstName":"Dave","LastName":"Ward"}

But, what it actually returns is this:

// All the quotes in the manually generated JSON must be escaped in 
//  the second pass, hence all the backslashes.
{"d":"{\"FirstName\":\"Dave\",\"LastName\":\"Ward\"}"}

What a mess. That’s probably not what you had in mind, is it?

Using DataContractJsonSerializer or Json.NET is no better

This may seem obvious, but I want to point out that using a different manual serialization tool, like WCF’s DataContractJsonSerializer or Json.NET, in place of JavaScriptSerializer above does not remedy the underlying problem. I only mention it because I’ve seen those variations of the mistake floating around too.

If anything, in the case of DataContractJsonSerializer, it’s even worse. DCJS’ handling of Dictionary collections and Enums makes life unnecessarily tedious at times, and the code to manually invoke it is even more verbose than that for JavaScriptSerializer.

The impact this mistake has on the client-side

If it weren’t bad enough to add extra computational overhead on the server-side, cruft up the response with escaping backslashes, and increase the size of the JSON payload over the wire, this mistake carries a penalty on the client-side too.

Most JavaScript frameworks automatically deserialize JSON responses, but (rightfully) only expect one level of JSON serialization. That means that the standard functionality provided by most libraries will only unwrap one level of the doubly serialized stack of JSON produced by the previous example.

So, even after the response comes back and your framework has deserialized it once, you’ll still need to deserialize it a second time to finally extract a usable JavaScript object if you’ve made the mistake of manually serializing. For example, this is code you might see to mitigate that in jQuery:

$.ajax({
  type: 'POST',
  dataType: 'json',
  contentType: 'application/json',
  url: 'PersonService.asmx/GetDave',
  data: '{}',
  success: function(response) {
    // At this point, response is a *string* containing the
    //  manually generated JSON, and must be deserialized again.
 
    var person;
 
    // This is a very common way of handling
    //  the second round of JSON deserialization:
    person = eval('(' + response + ')');
 
    // You'll also see this approach, which
    //  uses browser-native JSON handling:
    person = JSON.parse(response);
 
    // Using a framework's built-in helper 
    //  method is another common fix:
    person = $.parseJSON(person);
  }
});

Regardless of which approach is used, if you see code like this running after the framework has already processed a response, it’s a pretty good indication that something is wrong. Not only is this more complicated and verbose than it needs to be, but it adds additional overhead on the client-side for absolutely no valid reason.

Flipping the script (and the JSON)

Redundant JSON serialization on responses is definitely one of the most common variations of this problem I’ve seen, but the inverse of that mistake also seems to be an alluring pitfall. Far too often, I’ve seen service methods that accept a single JSON string as their input parameter and then manually parse several intended inputs from that.

Something like this to accept a Person object form the client-side and save it on the server-side, for example:

[ScriptService]
public class PersonService : WebService
{
  [WebMethod]
  public void SavePerson(string PersonToSave)
  {
    JavaScriptSerializer jss = new JavaScriptSerializer();
 
    Person p = jss.Deserialize<Person>(PersonToSave);
 
    p.Save();
  }
}

Just as ASP.NET automatically JSON serializes responses on its JSON-friendly services, it also expects that the input parameters will be in JSON format and automatically deserializes those on the way in. So, in reverse order, the approach above makes a mistake similar to the ones shown earlier.

To make this work, we’d need to pass in JSON that looks something like this, obfuscating the actually desired input parameters inside a single, doubly-serialized string parameter.

{"PersonToSave":"{\"FirstName\":\"Dave\",\"LastName\":\"Ward\"}"}

Through the convenience of JSON.stringify(), it’s not even terribly hard to stumble onto a process for cobbling that double-JSON structure together on the client-side and making this approach work. I strongly recommend against it though. Even if the double-JSON didn’t carry extra overhead in several aspects, having a single input parameter of type string on this method is misleading. A year from now, will anyone realize what type of parameter that method accepts without looking down into the manual parsing code? Probably not.

Doing it right

Briefly, here are what I suggest as better ways to handle passing our Person object in and out of ASP.NET services.

Returning an object

Returning a .NET object from ASP.NET services is incredibly easy. If you let go and just trust the service to handle JSON translation for you, “it just works”:

[ScriptService]
public class PersonService : WebService
{
  [WebMethod]
  public Person GetDave()
  {
    Person dave = new Person();
 
    dave.FirstName = Dave;
    dave.LastName = Ward;
 
    // So easy!
    return dave;
  }
}

As long as you call that service method through a ScriptManager’s service proxy or using the correct parameters when using a library like jQuery, ASP.NET will automatically serialize the Person object and return it as raw, unencumbered JSON.

Accepting an object from the client-side

Accepting a Person object from the client-side works identically, in reverse. ASP.NET does a great job of matching JSON-serialized request parameters to .NET’s types, collections, and even your own custom objects.

For example this is how you could accept a Person object, which would even then allow you to call that object’s custom methods:

[ScriptService]
public class PersonService : WebService
{
  [WebMethod]
  public void SavePerson(Person PersonToSave)
  {
    // No, really, that's it (assuming Person has a Save() method).
    PersonToSave.Save();
  }
}

 



ASP.NET 4 Hosting :: Main Differences of Custom Control and User Control

clock August 23, 2011 07:57 by author Administrator

If you are thinking to build a control and apply the same to more than one place, you can take two kinds of approaches. Either you can create an User control inheriting from UserControl and adding a XAML for your control or use CustomControl to write yourself. Either one of them you choose they have their own pros and cons. Here in this post I will define what are the differences between the two approaches so that you can choose either one of them based on your requirement.

Before we start lets define both the terms:

UserControl : A usercontrolis a reusable chunk of user interface that is built up as a composition of other UIElement in the same style the main UI is built. In other words, a user control is just like a normal application block that can be used as Reusable component, and can be defined both using XAML and code together. It gives you a fresh UI canvas where you can define your custom reusable component that can be used widely in the application. In WPF, UserControl acts as a base class for any reusable component, but if you are looking for inheriting some other base, you can look into this.

Limitation of UserControl :

1. Appearance of an UserControl cannot be changed using a Template. Even though it has a property for Template, but it is of no use, as you cannot change the appearance of UserControl through this property.

2. UserControl is derived from ContentControl, thus if you change the Content of an usercontrol the entire UI will be replaced with that content.

3. As UserControl has both XAML and code behind. But as XAML can be used only once for entire inheritance hierarchy, you cannot use XAML for any class that inherits from your userControl. This is actually because Application.LoadComponent loads up the XAML once and is incompatible with inheritance. Thus when loading the XAML, the IComponentConnector interface is used to hook events and fields from XAML, hence you cannot replace XAML from your base class.

Custom Control: A customcontrol is a User interface element that has a distinct behaviour. A CustomControl is just a class that has one default appearance defined in Generic.xaml style which can be replaced by Template and Style at runtime but the behaviour you define for the control remains the same. So choose a CustomControl only when you need a certain kind of behaviour which is not there with the existing controls you have.

Note: Please don’t create a new custom control just to change the UI appearance as you can do this with any control available using custom Template

Limitation :

1. You have to define each behaviour for your control using Code. So it is hard way of achieving a behaviour.

2. Generic style is needed to be defined with your custom control to ensure that your control has a default look and feel.

Hence, based on your own requirement, if you are looking for a new behaviour which is different from existing userinterfaces available with WPF, you go for a Custom Control. A customControl can be styled and templated and best suited for a situation when you are building a Control Library.

On the contrary, a UserControl gives you an easy way to define reusable chunk of XAML which can be reused widely in your application and when you don’t need to use it as a Control Library.

I hope this gives you a brief idea on the differences between the two.

Happy Coding.



ASP.NET 4.0 & ASP.NET 4.5 Hosting

 

ASPHostCentral is a premier web hosting company where you will find low cost and reliable web hosting. We have supported the latest ASP.NET 4.5 hosting and ASP.NET MVC 4 hosting. We have supported the latest SQL Server 2012 Hosting and Windows Server 2012 Hosting too!

 

Calendar

<<  March 2024  >>
MoTuWeThFrSaSu
26272829123
45678910
11121314151617
18192021222324
25262728293031
1234567

View posts in large calendar

Sign in