sasi's space

Exception Management

·        Do not use exceptions to control application flow.

·        Use validation code to avoid unnecessary exceptions.

·        Use the finally block to ensure resources are released.

·        Replace Visual Basic .NET On Error Goto code with exception handling.

·        Do not catch exceptions that you cannot handle.

·        Be aware that rethrowing is expensive.

·        Preserve as much diagnostic information as possible in your exception handlers.

·        Use performance monitor to monitor common language runtime (CLR) exceptions.

Iterating and Looping

·        Avoid repetitive field or property access.

·        Optimize or avoid expensive operations within loops.

·        Copy frequently called code into the loop.

·        Consider replacing recursion with looping.

·        Use for instead of foreach in performance-critical code paths.

String Operations

·        Avoid inefficient string concatenation.

·        Use + when the number of appends is known.

·        Use StringBuilder when the number of appends is unknown.

·        Treat StringBuilder as an accumulator.

·        Use the overloaded Compare method for case-insensitive string comparisons.

Arrays

·        Prefer arrays to collections unless you need functionality.

·        Use strongly typed arrays.

·        Use jagged arrays instead of multidimensional arrays.

Collections

·        Analyze your requirements before choosing the collection type.

·        Initialize collections to the right size when you can.

·        Consider enumerating overhead.

·        Prefer to implement IEnumerable with optimistic concurrency.

·        Consider boxing overhead.

·        Consider for instead of foreach.

·        Implement strongly typed collections to prevent casting overhead.

·        Be efficient with data in collections.

Reflection and Late Binding

·        Prefer early binding and explicit types rather than reflection.

·        Avoid late binding.

·        Avoid using System.Object in performance critical code paths.

·        Enable Option Explicit and Option Strict in Visual Basic.NET.

Code Access Security

·        Consider SuppressUnmanagedCodeSecurity for performance-critical, trusted scenarios.

·        Prefer declarative demands rather than imperative demands.

·        Consider using link demands rather than full demands for performance - critical, trusted scenarios.

Working Set Considerations

·        Load only the assemblies you need.

·        Consider assemblies that are being loaded as side effects.

·        Reduce the number of application domains, and/or make assemblies shared assemblies.

·        Reduce the number of threads.

Native Image Generator (Ngen.exe)

·        Scenarios where startup time is paramount should consider Ngen.exe for their startup

·        path.

·        Scenarios that will benefit from the ability to share assemblies should adopt Ngen.exe.

·        Scenarios with limited or no sharing should not use Ngen.exe.

·        Do not use Ngen.exe for ASP.NET version 1.0 and 1.1.

·        Consider Ngen.exe for ASP.NET version 2.0.

·        Measure performance with and without Ngen.exe.

·        Regenerate your image when you ship new versions.

·        Choose an appropriate base address.

Many thanks to Bijoy Singhal  - Bijoy.Singhal@microsoft.com

Many thanks to Bijoy Singhal  - Bijoy.Singhal@microsoft.com

Client Java Script is one of the most important things in web development but not the best and easiest to develop. Building of bigger and more complicated scripts, especially using DOM model or form field values can cause a lot of frustration and head pain. Moreover, JavaScript debugging is not easy and obvious as should be. But there is a hope.

One of less known features of Visual Studio 2005 is Script Explorer, hidden in Debug menu where appears only when the debugger is running. This great tool allows easily debug JavaScripts.

Before start, we should ensure that client script debugging is not disabled in IE as it is by default. Suitable options are located on Advanced tab of Internet Options where both script debugging checkboxes should be unchecked.

We can come back to Script Explorer. As it was written before, it appears only while the debugger is working. So after starting project we can go do Debug->Windows where should be Script Explorer. Sometimes, don’t know why, it doesn’t so in this case we have to find it manually. Staying in debug mode right click on tool bar and go into Customize. Then select Debug in Categories on the left side of window and find Script Explorer on the right. Just drag it to Debugging toolbar.

After opening Script Explorer panel we will se the tree of active JavaScripts. At the first level are scripts that are imported from external sources or embedded in the page. There are also auto-generated scripts like postback scripts as well. By double-clicking on the selected script it will open in the main window.

At this moment, we can debug it in well known way using breakpoints, steps, Watch and QuickWatch, just like in the server side, including context variable browsing.

We can debug it through immediate window also as shown below.

Breakpoints can also be set up in external *.js files before project will be loaded. Then, after loading project, the breakpoint will be activated by debugger. Note, that it is only possible to *.js files not for scripts embedded in pages. These scripts are available for debugging only after loading page. 

Source : Ziemowit – developerfusion.co.uk

Encrypting Configuration Sections using aspnet_regiis.exe

The .NET Framework includes a variety of command line tools in the $WINDOWS$\Microsoft.NET\Framework\version\ folder. In the Using SQL Cache Dependencies tutorial, for Instance, we looked at using the aspnet_regsql.exe command line tool to add the infrastructure necessary for SQL cache dependencies. Another useful command line tool in this folder is the ASP.NET IIS Registration tool (aspnet_regiis.exe). As its name implies, the ASP.NET IIS Registration tool is primarily used to register an ASP.NET 2.0 application with Microsoft’s professional grade Web server, IIS. In addition to its IISrelated features, the ASP.NET IIS Registration tool can also be used to encrypt or decrypt specified configuration sections in Web.config. The following statement shows the general syntax used to encrypt a configuration section with the aspnet_regiis.exe command line tool:

aspnet_regiis.exe ­pef section physical_directory ­prov provider

Section is the configuration section to encrypt (like “connectionStrings”), the physical_directory is the full, physical path to the web application’s root directory, and provider is the name of the protected configuration provider to use (such as “DataProtectionConfigurationProvider”). Alternatively, if the web application is registered in IIS you can enter the virtual path instead of the physical path using the following syntax:

aspnet_regiis.exe ­pe section ­app virtual_directory ­prov provider

The following aspnet_regiis.exe example encrypts the <connectionStrings> section using the DPAPI provider with a machinelevel

key: aspnet_regiis.exe ­pef "connectionStrings" "C:\Websites\ASPNET_Data_Tutorial_73_CS"

­prov “DataProtectionConfigurationProvider"

Similarly, the aspnet_regiis.exe command line tool can be used to decrypt configuration sections. Instead of using the ­pef switch, use ­pdf (or instead of ­pe, use ­pd). Also, note that the provider name is not necessary when decrypting.

aspnet_regiis.exe ­pdf section physical_directory­

or ­ aspnet_regiis.exe ­pd section ­app virtual_directory

Note: Since we are using the DPAPI provider, which uses keys specific to the computer, you must run aspnet_regiis.exe from the same machine from which the web pages are being served. For example, if you run this command line program from your local development machine and then upload the encrypted Web.config file to the production server, the production server will not be able to decrypt the connection string information since it was encrypted using keys specific to your development machine. The RSA provider does not have this limitation as it is possible to export the RSA keys to another machine. authentication, however, the authentication credentials are hardcoded from the web server to the database server in plaintext.