Tag Archives: asp.net

ASP.NET MVC 5.1, ASP.NET Web API 2.1 and ASP.NET Web Pages 3.1

The NuGet packages for ASP.NET MVC 5.1, ASP.NET Web API 2.1 and ASP.NET Web Pages 3.1 are now live on the NuGet gallery!

You can install or update to the released NuGet packages for ASP.NET MVC 5.1, ASP.NET Web API 2.1 and ASP.NET Web Pages 3.1 using the NuGet Package Manager Console, like this:

  • Install-Package Microsoft.AspNet.Mvc -Version 5.1.0
  • Install-Package Microsoft.AspNet.WebApi -Version 5.1.0
  • Install-Package Microsoft.AspNet.WebPages -Version 3.1.0

Pre-requisites for this release

  • If you are using Visual Studio 2012, please download ASP.NET and Web Tools 2013.1 for Visual Studio 2012.
  • If you are using Visual Studio 2013, please download Visual Studio 2013 Update 1. This update is needed for editing ASP.NET MVC 5.1 Razor Views.

.NET Cache Solutions

If you’re developing an ASP.NET application, Web services or a high-performance computing (HPC) application, you’re likely to encounter major scalability issues as you try to scale and put more load on your application. With an ASP.NET application, bottlenecks occur in two data stores. The first is the application data that resides in the database, and the other is ASP.NET session state data that is typically stored in one of three modes (InProc, StateServer, or SqlServer) provided by Microsoft. All three have major scalability issues.

Web services typically do not use session state, but they do have scalability bottlenecks when it comes to application data. Just like ASP.NET applications, Web services can be hosted in IIS and deployed in a Web farm for scalability.

HPC applications that are designed to perform massive parallel processing also have scalability problems because the data store does not scale in the same manner. HPC (also called grid computing) has traditionally used Java, but as .NET gains market share, it is becoming more popular for HPC applications as well. HPC applications are deployed to hundreds and sometimes thousands of computers for parallel processing, and they often need to operate on large amounts of data and share intermediate results with other computers. HPC applications use a database or a shared file system as a data store, and both of these do not scale very well.

Distributed Caching

Caching is a well-known concept in both the hardware and software worlds. Traditionally, caching has been a stand-alone mechanism, but that is not workable anymore in most environments because applications now run on multiple servers and in multiple processes within each server.

In-memory distributed caching is a form of caching that allows the cache to span multiple servers so that it can grow in size and in transactional capacity. Distributed caching has become feasible now for a number of reasons. First, memory has become very cheap, and you can stuff computers with many gigabytes at throwaway prices. Second, network cards have become very fast, with 1Gbit now standard everywhere and 10Gbit gaining traction. Finally, unlike a database server, which usually requires a high-end machine, distributed caching works well on lower cost machines (like those used for Web servers), which allows you to add more machines easily.

Distributed caching is scalable because of the architecture it employs. It distributes its work across multiple servers but still gives you a logical view of a single cache. For application data, a distributed cache keeps a copy of a subset of the data in the database. This is meant to be a temporary store, which might mean hours, days or weeks. In a lot of situations, the data being used in an application does not need to be stored permanently. In ASP.NET, for example, session data is temporary and needed for maybe a few minutes to a few hours at most.

NCache vs. AppFabric

Feature Area

AppFabric

NCache

Performance & Scalability

Has performance and scalability issues that are due to WCF as the transport layer and lack of advanced performance optimizations features. Extremely fast and scalable due to a light-weight socket-level protocol for transport layer. And, many advanced performance optimization features provided to further speed things up.

Cache Elasticity
(High Availability)

No peer to peer architecture. Something resembling master/slave architecture employed. If some of the “lead nodes” or the configuration file server goes down, the entire cache could potentially go down. Highly elastic with 100% uptime. Peer to peer cluster architecture. Connection failover support, dynamic configuration, and “Hot Apply” feature.

Cache Topologies

Local cache, partitioned cache, and limited partitioned-replicated cache. Async replication not supported and due to this operations slow down. Rich options. Local, Mirrored, Replicated, Partitioned, Partition-Replica, and Client Caches. Highly dynamic and intelligent replication provided without compromising performance or scalability.

WAN Replication

No support for it. Supports WAN replication using following bridge topologies: Active-passive, active-active, one-active & multiple passive, and 3 or more active sites. No performance drop.

Cache Administration

Very basic cache admin GUI tool. No dedicated cache monitoring tool. Only PerfMon counters provided for monitoring. PowerShell based Cmdlets provided. Very powerful GUI tools. NCache Manager for cache admin, and NCache Monitor for cache monitoring. PerfMon counters, and command line tools provided.

Security & Encryption

No encryption provided for data in the cache. Authentication/authorization provided. Powerful 3DES/256AES data encryption in the cache provided as a config option.
Active Directory/LDAP authentication and authorization provided.

Object Caching Features

CRUD operations and locking provided. Limited support for expirations. And, no streaming API provided. CRUD operations, locking, versioning, and much more.
Absolute & sliding expirations provided. Streaming API provided.

Managing Data Relationships

No support for it. Key based Cache Dependency allows you to handle one-to-one, one-to-many, and many-to-many relationships in the cache automatically.

Synchronization with
Data Sources

No support for it. SqlDependency, OracleDependency, DbDependency, & CLR Stored Procedures for database synchronization. File based and Custom dependency for non-relational data sources.

Runtime Data Sharing

Very limited support. Publish/subscribe events not supported. Continuous Query not provided. Only item level and cache. Powerful publish/subscribe event supported. Continuous Query, .NET/Java portable binary data, and more. Use NCache for publisher/consumer data sharing between .NET/.NET or .NET/Java apps.

Search Cache (SQL-Like)

No support for it. Object Query Language (OQL) and LINQ. Search cache on object attributes, Tags, and Named Tags with SQL-like query.

Data Grouping

No support for Group/Subgroup or Named Tags. Only Tags are supported. Group/sub-group, Tags, and Named Tags. Group, fetch, update, and manipulate data intelligently.

Read-thru & Write-thru

Supports Read-thru and Write-behind only. No Write-through supported. Multiple Read-thru, Write-thru, Write-behind. Use cache to fetch data from your database and simplify your apps. Also auto-reload cached items when expired or when database synchronization needed.

Cache Size Mgmt

Only LRU evictions supported. LRU, LFU, and Priority evictions. You can designate cached items to not be evicted with priority eviction.

ASP.NET Support

Basic ASP.NET Session State support. Session replication has performance and scalability issues. ASP.NET ViewState support is very basic. ASP.NET Output Cache supported. Powerful ASP.NET Session State, ASP.NET View State, ASP.NET Output Cache. Replication for sessions, view state, and page output. Link view state with sessions for auto expiry and much more.

Third Party Integrations

No official support for NHibernate, Entity Framework, and EntLib Caching Application Block. NHibernate Second Level Cache,
Entity Framework Cache,
EntLib Caching Block.
Extra features provided for all of these. Use all of these without any programming.

Windows Azure Cache

Windows Azure Cache Service (Preview) is a distributed, in-memory, scalable solution that enables you to build highly scalable and responsive applications by providing super-fast access to data.

Windows Azure Cache Service (Preview) includes the following features:

  • Pre-built ASP.NET providers for session state and page output caching, enabling acceleration of web applications without having to modify application code.
  • Caches any serializable managed object – for example: CLR objects, rows, XML, binary data.
  • Consistent development model across both Windows Azure and Windows Server AppFabric.

Cache Service (Preview) gives you access to a secure, dedicated cache that is managed by Microsoft. A cache created using the Cache Service (Preview) is accessible from applications within Windows Azure running on Azure Web Sites, Web & Worker Roles and Virtual Machines.

Cache Service (Preview) is available in three tiers:

  • Basic – Cache in sizes from 128MB to 1GB
  • Standard – Cache in sizes from 1GB to 10GB
  • Premium – Cache in sizes from 5GB to 150GB

Cookies in ASP.NET

A cookie is a small bit of text that accompanies requests and pages as they go between the Web server and browser. The cookie contains information the Web application can read whenever the user visits the site.

Cookies are associated with a Web site, not with a specific page, so the browser and server will exchange cookie information no matter what page the user requests from your site. As the user visits different sites, each site might send a cookie to the user’s browser as well; the browser stores all the cookies separately.

Cookies provide a means in Web applications to store user-specific information. For example, when a user visits your site, you can use cookies to store user preferences or other information. When the user visits your Web site another time, the application can retrieve the information it stored earlier.

Cookie Limitations

Most browsers support cookies of up to 4096 bytes(4K). Because of this small limit, cookies are best used to store small amounts of data, or better yet, an identifier such as a user ID. The user ID can then be used to identify the user and read user information from a database or other data store. (See the section "Cookies and Security" below for information about security implications of storing user information.)

Browsers also impose limitations on how many cookies your site can store on the user’s computer. Most browsers allow only 20 cookies per site; if you try to store more, the oldest cookies are discarded. Some browsers also put an absolute limit, usually 300, on the number of cookies they will accept from all sites combined.

A cookie limitation that you might encounter is that users can set their browser to refuse cookies. If you define a P3P privacy policy and place it in the root of your Web site, more browsers will accept cookies from your site. However, you might have to avoid cookies altogether and use a different mechanism to store user-specific information. A common method for storing user information is session state, but session state depends on cookies, as explained later in the section "Cookies and Session State."

Controlling Cookie Scope

By default, all cookies for a site are stored together on the client, and all cookies are sent to the server with any request to that site. In other words, every page in a site gets all of the cookies for that site. However, you can set the scope of cookies in two ways:

  • Limit the scope of cookies to a folder on the server, which allows you to limit cookies to an application on the site.

  • Set scope to a domain, which allows you to specify which subdomains in a domain can access a cookie.

HttpCookie appCookie = new HttpCookie("AppCookie");
appCookie.Value = "written " + DateTime.Now.ToString();
appCookie.Expires = DateTime.Now.AddDays(1);
appCookie.Path = "/Application1";
Response.Cookies.Add(appCookie);
Changing a Cookie’s Expiration Date

The browser is responsible for managing cookies, and the cookie’s expiration time and date help the browser manage its store of cookies. Therefore, although you can read the name and value of a cookie, you cannot read the cookie’s expiration date and time. When the browser sends cookie information to the server, the browser does not include the expiration information. (The cookie’s Expires property always returns a date-time value of zero.) If you are concerned about the expiration date of a cookie, you must reset it, which is covered in the "Modifying and Deleting Cookies" section.

Cookies and Session State

When a user navigates to your site, the server establishes a unique session for that user that lasts for the duration of the user’s visit. For each session, ASP.NET maintains session state information where applications can store user-specific information. For more information, see ASP.NET Session State Overview topic.

ASP.NET must track a session ID for each user so that it can map the user to session state information on the server. By default, ASP.NET uses a non-persistent cookie to store the session state. However, if a user has disabled cookies on the browser, session state information cannot be stored in a cookie.

ASP.NET offers an alternative in the form of cookieless sessions. You can configure your application to store session IDs not in a cookie, but in the URLs of pages in your site. If your application relies on session state, you might consider configuring it to use cookieless sessions. However, under some limited circumstances, if the user shares the URL with someone else—perhaps to send the URL to a colleague while the user’s session is still active—then both users can end up sharing the same session, with unpredictable results. For more information on configuring your application to use cookieless sessions, see the ASP.NET State Management Overview topic.