NDOC in NAnt

<target name="CreateDocumentation" description="Will create documentation for Buidling Solution"> </target>

request queues ASP.NET

ASP.NET uses two request queues:
•The global queue, which is managed by the process that runs ASP.NET (Aspnet_wp). The global queue is configured in the Machine.config file by the property.
•The application queue, or virtual directory queue, which is managed by the HttpRuntime class. The HttpRuntime class provides run-time services for ASP.NET applications. There is one queue for each virtual directory. The application queue is configured in Machine.config by the property.
When either queue exceeds its default limit, the request is rejected with a 503 error (Service Unavailable).

WHY DOT NET application restarts.

Recreating the application domain and recompiling pages takes time, therefore unforeseen application restarts should be investigated. The application domain is unloaded when one of the following occurs:

Modification of machine.config, web.config, or global.asax.
Modification of the application's bin directory or its contents.
When the number of compilations (ASPX, ASCX, or ASAX) exceeds the limit specified by .
Modification of the physical path of a virtual directory.
Modification of the code-access security policy.
The Web service is restarted.

Locking down configuration settings/overriding configuration settings

In addition to specifying path information using the <location>tag, you can also specify security so that settings cannot be overridden by another configuration file further down the configuration hierarchy. To lock down a group of settings, you can specify an allowOverride attribute on the surrounding <location>tag and set it to false. The following code locks down impersonation settings for two different applications.
<configuration>
<location allowoverride="false" path="app1"><system.web><identity username="app1" impersonate="false" password="app1pw"></location>
<location allowoverride="false" path="app2"><system.web><identity username="app2" impersonate="false" password="app2pw"></SYSTEM.WEB></location>
</configuration>
allowdefinition is used to allow child to define tags

allowoverride is used to allow child to override tags

<location path="." inheritInChildApplications="false">

<system.web> ... </system.web></location>

overriding parent web.config

While the ability of applications and folders to inherit settings from parent web.config files is very convenient, it presents security implications. For example, the element can be used to store key/value pairs for runtime retrieval from your application. If this element is used to store values in the machine.config file, these values are available to any application on that machine. In a shared server environment, this could potentially expose information to others in undesirable ways.

Another security issue with both machine.config and web.config is how to prevent modification of inherited settings. For example, a server administrator might want to configure authentication settings globally in the machine.config file and prevent application developers from overriding these settings in their applications. This can be accomplished by using the element, setting its allowOverride attribute to False and optionally, setting the path attribute to an application path (if the locked-down settings are to apply only to a specific file or folder).

It is important to exercise caution when working with the machine.config file to avoid making changes if you are uncertain of their impact (particularly on other applications). Remember that machine.config contains configuration settings not only for all ASP.NET web applications for a given machine, but also for all .NET applications on that machine. Thus, changes to machine.config can have a broad impact. It's a good idea to back up the machine.config file before editing it, so that if your changes result in problems, you can always restore the previous copy. Another alternative is to place the machine.config file under a source code control system, such as Visual Source Safe, and require checkout of the file to make modifications. This provides the ability to roll back changes, as well as the additional ability to track who has made changes to the file.

Finally, your application is required to have a web.config file. If the default settings from machine.config (or a parent web.config) file serve your needs, then omitting this file will simplify your deployment and maintenance tasks. Only use web.config when you need to make changes to the default configuration provided by machine.config.

Probably the most common error that is encountered with web.config and machine.config relates to capitalization. Tags and elements within both these files are case sensitive. Tags and elements follow the naming convention referred to as camel-casing, in which the first letter of the first word of the element or attribute is lowercase, and the first letter of each subsequent word is uppercase. Attribute values are also case sensitive, but do not follow any particular naming convention.

Error handling/ error gathering code

Imports System.Data

Imports System.Data.SqlClientImports dataConnection

Partial Class ErrInfo Inherits System.Web.UI.Page

Public error_ID As String

Public errpath As String

Dim DatabaseObject As New dataConnection

Dim datareader As SqlDataReader
Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
Dim strSql As String Dim ex As Exception = dataConnection.LastError Dim ErrMsg, pageUrl, stack_info As String ErrMsg = dataConnection.LastError.InnerException.Message.ToString() pageUrl = dataConnection.lastURL.ToString stack_info = dataConnection.LastError.ToString ErrMsg = ErrMsg.Replace("'", "") ErrMsg = ErrMsg.Replace(".", "")
Dim errLine As String 'errLine = Mid(ex.ToString(), InStr(ex.ToString(), ":line") - 20, InStr(ex.ToString(), "at System") - InStr(ex.ToString(), ":line") + 20) errLine = Mid(ex.ToString(), ex.ToString().LastIndexOf(":line") + 6, 8) 'ex.ToString().LastIndexOf("at System") - ex.ToString().LastIndexOf(":line") + 20)
Dim pageArr As String() = pageUrl.Split(New [Char]() {"/"c})
Dim currDateTime As DateTime = DateTime.Now Dim errorDate As String
DatabaseObject.openDB() errorDate = currDateTime.ToString("dd/MMM/yy")
strSql = "INSERT INTO ERRORLOG VALUES ('" & dataConnection.lastURL & "','" & Request("aspxerrorpath").ToString & "','" & ErrMsg & "','" & errorDate & "')"
DatabaseObject.executeNonQuery(strSql) datareader = DatabaseObject.executeReader("SELECT IDENT_CURRENT('ERRORLOG') as error_id") If datareader.HasRows Then datareader.Read() error_ID = datareader("error_id").ToString End If
datareader.Close() datareader.Dispose()
DatabaseObject.closedb()
'send error mail to admin Dim body As String body = "

<table cellspacing="'3'" cellpadding="'3'" width="'90%'" align="'center'" border="'0'">" body += " Error Date: " & errorDate & "" body += " Error Time: " & Date.Now.ToString("HH:mm:ss tt") & "" body += " User Name: " & Session("userID") & "" body += " OS: " & Request.Browser.Platform & "" body += " Browser: " & Request.Browser.Browser & "" body += " Page: " & Request("aspxerrorpath").ToString & "" body += " URL: " & dataConnection.lastURL & "" body += " Line: " & errLine & "" body += " Error Details: " & ErrMsg & " " body += " Stack Information: " & stack_info & " " body += "</table>

"
Dim page_name As String = Request("aspxerrorpath").Substring(1) 'Response.Write(body & "
" & page_name) DatabaseObject.sendMail1(body, "admin@yoursite.com", "cc", "Error on file " & page_name) 'DatabaseObject.sendMail1(body, "admin@yoursite.com", "cc", "Error on ..") End Sub

End Class

add following in global.asax:

Sub Application_Error(ByVal sender As Object, ByVal e As EventArgs) ' Code that runs when an unhandled error occurs dataConnection.LastError = Server.GetLastError() dataConnection.lastURL = Request.Url().ToString End Sub

add following in web.config:

<customErrors mode="Off" defaultRedirect="ErrInfo.aspx">

Optimization Tips and Tricks for Telerik

Top 15 Optimization Tips and Tricks

While we do a lot to help you optimize RadControls in your applications, the Telerik community also does a great job of sharing optimization tips and tricks. One of the best list of optimization tricks ever produced by the community has recently surfaced on the Telerik forums. Some of these ideas are specific to optimizing the RadControls, but many of them are great optimization techniques for ASP.NET in general. So without further ado, here are the "Top 15 Telerik Community Optimization Tips & Tricks" (in no particular order):
1.Make sure browser caching is enabled
Many RadControls must load a fair amount of JavaScript to enable all of the client-side goodness that we love in our modern web apps. To make sure this JavaScript is only downloaded once (instead of on every page request), make sure your users enable caching in their browsers.
2.Move ViewState off of the page
If you've got a lot of controls on your page and ViewState is enabled, chances are it is adding a lot of weight to the page. If turning ViewState off is not an option, you can greatly reduce the HTML sent to the client by moving ViewState off of the page and into Session (or some other server-side storage mechanism). For a good tutorial on this process, check out the following article: http://www.codeproject.com/aspnet/PersistentStatePage.asp.
3.Disable control ViewState
Similar to the previous trick, you can also set "EnableViewState" on each control to False and then manually manage the state on each page postback. Those of us that developed with classic ASP may recall some of the numerous ways this was accomplished before ASP.NET gave us ViewState. Manually managing control state can be time consuming, but it can help you keep your page HTML trim.
4.Use HTML Compression Tools
One of the easiest ways to reduce the HTML that you send to the client is to use an HTML compression tool. Compression tools can reduce the size of the HTML sent over the "tubes" for RadControls by up to 75%. Check out this forum thread for more details: http://www.telerik.com/community/forums/thread/b311D-tdkga.aspx.
5.Background Image Caching in IE
By default, IE will not cache background images. If you use any CSS in your application (which you do if you use RadControls with skins), this can lead to a lot of wasted downloads in IE. Fortunately, there is a way to "trick" IE into caching background images. Check out the details here: http://www.telerik.com/community/forums/thread/b311D-teckk.aspx.
6.Read the Documentation
This may sound like a worthless trick, but don't discount it until you've given it a try. Almost all RadControls have a dedicated "Speed Optimization" topic in their documentation that contains tips specific to each RadControl. Visit the RadControls documentation to find these tips. (Here is a link to RadGrid's optimization documentation to get you started.)
7.Use Http Analysis Tools
How can you solve a problem without seeing it first? Free tools like Fiddler (for IE) and FireBug (for FireFox) help you peel back the curtain on your page's performance and quickly find bottlenecks in your page HTML that need to be optimized.
8.Use 3rd Party Optimization Tools
Still looking for optimization techniques that don't require much work? There are several tools, like port80 and cacheright, that help automate the process of optimizing your page. These tools can help eliminate many of the caching problems that you'd otherwise have to deal with manually.
9.Use External Resources instead of EmbeddedResources
Embedded resources are generally very good and very helpful. They allow you do just deploy a control assembly and not deal with any additional files. When a page uses EmbeddedResources, though, resources are pulled from an assembly using a handler and querystring value (like WebResource.axd?d=HTLSHE...). Unfortunately, these long querystrings are adding bulk to the HTML you are sending to the client. One Telerik community member found that setting "UseEmbeddedResources" to False (and using external resources in the RadControls folder instead) reduced page size from 80 kB to about 50 kB simply due to the shorter resource paths. Your mileage may vary depending on the RadControls you're using.
10.Keep Control IDs Short
Whenever you have deeply nested controls, the ID of the parent control is always appended to child control IDs (if the parents implement INamingContainer). If you have long control IDs, you can cause a fair amount of extra HTML to be rendered to the page. For example, if we have a RadTreeView with ID "RadTreeView1" in ContentPlaceHolder with ID "ContentPlaceHolder1" (in a MasterPage), the resulting client ID of the TreeView is "ctl00_ContentPlaceHolder1_RadTreeView1". If we had used shorter server IDs, we could have trimmed this output to "ctl00_cph1_rtv1" and reduced the overall HTML sent to our page. This trick should always be weighed against making your code difficult to maintain due to cryptic control IDs.
11.Test Sites in IIS (not Cassini)
The web server built-in to Visual Studio is very convenient for development, but it is not a good place to test your site's performance. Cassini does not do any caching of web resources and it is generally slower than IIS. You should always test your site in IIS before deploying it to a PROD environment to make sure you know how it will really perform.
12.Use RamDisks in your Infrastructure
If you have control over your servers and are willing to make some hardware changes to improve performance, RamDisks may be worth checking out. By using RamDisks instead of traditional HDD for things like tempdb storage in SQL Server or HTTP decompression scratch storage, you can (supposedly) deliver performance 50x's normal hard drives. Check out this resource for more details: http://www.superspeed.com/ramdisk.php.
13.Use Incremental Page Fetch
It sounds more exciting than it is, but by using RadAjax and some crafty coding you can help your pages load faster. In essence, you delay loading all of the user controls needed by your page so that the page will initially load faster and then load the controls with RadAjax. For details on this process, check out this link: http://www.telerik.com/community/forums/thread/b311D-tkkce.aspx.
14.Remove Whitespace Characters
You may not realize it, but all of the whitespace characters our page contains to make it easy to read add HTML bulk. We definitely don't want to get rid of all of our page formatting at design time, though, so there are modules like this that remove the whitespace at runtime. By tapping-in to the page's render method, you can easily search for whitespace characters in your page and remove them to keep your pages trim. Warning: this method may cause problems if you use it with the new RadControls "Prometheus".
15.Don't use Label when Literal works
Perhaps one of the most overlooked ASP controls is the "asp:literal" control. There are many times when ASP.NET developers use Label or HyperLink when Literal would do the job and save HTML bulk. For example, if you use a Label like this:

will render:
Some test text

If you use a Literal like this:

will render:
Some test text

The literal will not render any unnecessary span tags and help you reduce HTML sent to the client.
So there you go. The top 15 optimization tips and tricks as suggested by the Telerik community. Special credit goes to Johan, andyk, Martin Bischoff, and Mike for collecting most of these ideas in the forums.

performance setting to achieve good grade in YSLOW

performance setting to achieve good grade in YSLOW

Dummy Credit Card Numbers for Testing

Dummy Credit Card Numbers for Testing
Here is a list of dummy credit card number that can be used while testing your applications involving credit card transactions:
Visa: 4111-1111-1111-1111
MasterCard: 5431-1111-1111-1111
Amex: 341-1111-1111-1111
Discover: 6011-6011-6011-6611
Credit Card Prefix Numbers:
Visa: 13 or 16 numbers starting with 4
MasterCard: 16 numbers starting with 5
Discover: 16 numbers starting with 6011
AMEX: 15 numbers starting with 34 or 37

check credit card /credit card verification

check credit card /credit card verification
http://www.braemoor.co.uk/software/creditcard.shtml