If you want it to be unprintable, you could stop newbie users from
printing directly from the page by putting:
<style type="text/css" media="print">
body { display: none }
</style>
Between the <head> tags.
Monday, April 28, 2008
Script to make Web page unprintable
Script to disable right click on a web page
Here is the script
<script LANGUAGE="JavaScript1.1">
<!-- Begin
function right(e) {
if (navigator.appName == 'Netscape' &&
(e.which == 3 || e.which == 2))
return false;
else if (navigator.appName == 'Microsoft Internet Explorer' &&
(event.button == 2 || event.button == 3)) {
alert("YOUR MESSAGE HERE");
return false;
}
return true;
}
document.onmousedown=right;
if (document.layers) window.captureEvents(Event.MOUSEDOWN);
window.onmousedown=right;
// End -->
</script>
Wednesday, April 23, 2008
Difference between TOP clause in SQL 2000 and SQL 2005
Generally TOP clause is used to perform SELECT on top n results. This feature of TOP is extended in SQL 2005 so that we can also use expression apart from int, bigint and percent to perform query and also extended to be used in UPDATE and DELETE statements.
In SQL 2000
syntax: select Top N [Percent]
EX:
select Top 10 * from TableName
or
select Top 10 Percent * from TableName
n specifies how many rows are returned. If PERCENT is not specified, n is the number of rows to return. If PERCENT is specified, n is the percentage of the result set rows to return
Drawbacks:
We could not parameterize.
It will work only for select statements.
If we want to restrict the number of rows affected by a select at runtime, or restrict the rows affected by an update or delete you had to explicitly describe the rows using a join or where clause, or you could cheat a bit by using ROWCOUNT, like this
set rowcount 10 delete from table where payratefieldname=1 set rowcount 0
It will work but the risk is if for some reason rowcount is not set to 0 then the other statements will also restricted to 10.
All these drawbacks are overcome in SQL 2005 by introducing Expression in syntax.
In SQL 2005
syntax: select Top (Expression) [Percent]
EX:
Is the numeric expression that specifies the number of rows to be returned. expression is implicitly converted to a float value if PERCENT is specified; otherwise, it is converted to bigint.
Ex:
select Top 10 * from TableName
or
select Top 10 Percent * from TableName
or we can set at runtime as
Declare @ int
SET @topNum = 10
select TOP (@topNum) * from
For select statements you must specify parentheses if you are passing a parameter, otherwise they are optional
Select Top (@topNum) * from TableName Select Top 10 * from TableName
When doing an update or delete, you have to use the parentheses in both cases:
Delete Top (@topNum) from employeesDelete Top (10) from TableName update Top (@topNum) TableName set fieldname = @fieldvalue update Top (10) from employees set fieldname = @fieldvalue This is nice tricky change introduced in SQL 2005
Detecting a Client's screen resolution and color depth in ASP.NET/Javascript
At times you might want to know how much screen real estate a user has before opening several new browser windows. You also might want to find out if they have a high-color display capable of showing a detailed color image. The following code shows how to learn the user's screen real estate and color depth. The total screen size includes unusable areas like the icon tray on Windows or the menubar on the Mac. The available screen size attributes subtract these system-reserved areas from the total screen size. For multi-screen systems, Internet Explorer will return the size of the monitor it is on, while Netscape returns the size of both monitors combined.
<HTML> <HEAD> <TITLE>Detecting the user's hardware</TITLE> </HEAD> <BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" ALINK="#6600FF" VLINK="#CC0000"> <SCRIPT LANGUAGE="JavaScript1.2" TYPE="text/javascript"> <!-- document.writeln("Total Screen size = ", screen.width, " x ", screen.height); document.writeln("<P>"); document.writeln("Available Screen size = ", screen.availWidth, " x ", screen.availHeight); document.writeln("<P>"); document.writeln("Color depth = ", screen.colorDepth); //--> </SCRIPT> </BODY> </HTML>Retrieving all Server Environment variable values
How to retrieve all Server Environment variables at one go. Just place
this code in .aspx page run it.
<div>
<table width="70%" align="center">
<tr bgcolor="#FF9900">
<td width="25%" align="center">
ServerVariable:
</td>
<td width="75%">
Value
</td>
</tr>
<% foreach(string Item in Request.ServerVariables){ %>
<tr>
<td width="25%">
<%= Item %>
</td>
<td width="75%">
<%=Request.ServerVariables[Item]%>
</td>
</tr>
<% } %>
</table>
</div>
Complete list of server environment variables
Following is the table containing a list of server environment variables.
Using:
VB: Request.ServerVariables("Variable")
C#: Request.ServerVariables["Variable"]
| Variable | Description |
|
| All HTTP headers sent by the client. |
|
| Retrieves all headers in raw form. The difference between |
|
| Retrieves the metabase path for the Application for the ISAPI DLL. |
|
| Retrieves the physical path corresponding to the metabase path. IIS converts the |
|
| The value entered in the client's authentication dialog. This variable is available only if Basic authentication is used. |
|
| The authentication method that the server uses to validate users when they attempt to access a protected script. |
|
| The name of the user as it is derived from the authorization header sent by the client, before the user name is mapped to a Windows account. This variable is no different from |
|
| Unique ID for client certificate, returned as a string. Can be used as a signature for the whole client certificate. |
|
| bit0 is set to 1 if the client certificate is present. bit1 is set to 1 if the cCertification authority of the client certificate is invalid (it is not in the list of recognized CAs on the server). |
|
| Issuer field of the client certificate (O=MS, OU=IAS, CN=user name, C= |
|
| Number of bits in Secure Sockets Layer connection key size. For example, 128. |
|
| Number of bits in server certificate private key. For example, 1024. |
|
| Serial number field of the client certificate. |
|
| Issuer field of the server certificate. |
|
| Subject field of the server certificate. |
|
| Subject field of the client certificate. |
|
| The length of the content as given by the client. |
|
| The data type of the content. Used with queries that have attached information, such as the HTTP queries GET, POST, and PUT. |
|
| The revision of the CGI specification used by the server. The format is CGI/revision. |
|
| The value stored in the header Note The server interprets any underscore (_) characters in |
|
| Returns the value of the Accept header. |
|
| Returns a string describing the language to use for displaying content. |
|
| Returns the cookie string that was included with the request. |
|
| Returns the name of the Web server. This may or may not be the same as |
|
| Returns a string that contains the URL of the page that referred the request to the current page using an HTML <A> tag. Note that the URL is the one that the user typed into the browser address bar, which may not include the name of a default document. If the page is redirected,
|
|
| Returns a string describing the browser that sent the request. |
|
| Returns ON if the request came in through secure channel (SSL) or it returns OFF if the request is for a non-secure channel. |
|
| Number of bits in Secure Sockets Layer connection key size. For example, 128. |
|
| Number of bits in server certificate private key. For example, 1024. |
|
| Issuer field of the server certificate. |
|
| Subject field of the server certificate. |
|
| The ID for the IIS instance in textual format. If the instance ID is 1, it appears as a string. You can use this variable to retrieve the ID of the Web-server instance (in the metabase) to which the request belongs. |
|
| The metabase path for the instance of IIS that responds to the request. |
|
| Returns the Server Address on which the request came in. This is important on multi-homed computers where there can be multiple IP addresses bound to the computer and you want to find out which address the request used. |
|
| The Windows account that the user is impersonating while connected to your Web server. Use |
|
| Extra path information as given by the client. You can access scripts by using their virtual path and the |
|
| A translated version of |
|
| Query information stored in the string following the question mark (?) in the HTTP request. |
|
| The IP address of the remote host making the request. |
|
| The name of the host making the request. If the server does not have this information, it will set |
|
| The name of the user as it is derived from the authorization header sent by the client, before the user name is mapped to a Windows account. If you have an authentication filter installed on your Web server that maps incoming users to accounts, use |
|
| The method used to make the request. For HTTP, this is GET, HEAD, POST, and so on. |
|
| A virtual path to the script being executed. This is used for self-referencing URLs. |
|
| The server's host name, DNS alias, or IP address as it would appear in self-referencing URLs. |
|
| The port number to which the request was sent. |
|
| A string that contains either 0 or 1. If the request is being handled on the secure port, then this will be 1. Otherwise, it will be 0. |
|
| The name and revision of the request information protocol. The format is protocol/revision. |
|
| The name and version of the server software that answers the request and runs the gateway. The format is name/version. |
|
| Gives the base portion of the URL. |
Thursday, April 17, 2008
What is the difference between Class and structure’s ?
Following are the key differences between them :-
√ Structure are value types and classes are reference types. So
structures use stack and classes use heap.
√ Structures members can not be declared as protected, but class members
can be. You can not do inheritance in structures.
√ Structures do not require constructors while classes require.
√ Objects created from classes are terminated using Garbage collector.
Structures are not destroyed using GC.
Difference between localization and globalization
Below are the definition’s which is taken from the Microsoft glossary.
Globalization: It is the process of developing a program core whose features and code design are not solely based on a single language or locale.
Localization: The process of adapting a program for a specific local market, which includes translating the user interface, resizing dialog boxes, customizing features (if necessary), and testing results to ensure that the program still works. You can visualize globalization as more of architecture decisions. While localization is adapting your content to local market. Localization phase occurs before globalization phase.
Namespaces during localization and globalization
There are two most important namespaces:-
√ System.Globalization - contains classes that define culture-related information, including the language, the country/region, the calendars in use, the format patterns for dates, currency and numbers, and the sort order for strings.
√ System.Resources - provides classes and interfaces that allow developers to create, store, and manage various culture-specific resources used in an application. With this namespace you can read a resource file and display it accordingly to the user’s culture.
Using Repeater inside a Repeater.
Simply instead of the following line
<asp:repeater id="childRepeater" runat="server" datasource='<%# ((DataRowView)Container.DataItem) .Row.GetChildRows("myrelation") %>' >Use below line.
<asp:repeater id="childRepeater" runat="server" datasource='<%# GetChildData(databinder.Eval(Container.DataItem,"PKID")) %>' >
and in code behind file write this following function
public function GetChildData(byval pkid as long) as datatable dim dt as datatable ' get your result in db by PKID or any other filteration return dt end function here is the example .... http://support.microsoft.com/default.aspx?scid=kb;en-us;306154
Coding Guidelines for C# .NET
1 Capitalization Styles
Pascal Casing
This convention capitalizes the first character of each word (as in SumSal).
Camel Casing
This convention capitalizes the first character of each word except the first character of the first word. E.g. sumSal.
3 Guidelines
3.1 Naming Conventions and Style
-
1. Use Pascal casing for type and method names
public class SomeClass
{
public SomeMethod(){}
}
Class names must be Nouns or Noun phrases.
Name methods with Verbs or Verb phrases.
2. Use camel casing for local variable names and method arguments
int number; someNumber
void MyMethod(int someNumber)
{
}
Try to avoid abbreviations in method arguments.
3. Name interfaces with I prefix
interface IMyInterface
{ .. }
Use Pascal Casing
Page 5 of 21
start the interface name with "I" and capitalize the letter following the "I"
4. Prefix private member variables with m_
public class SomeClass
{
private int m_Number;
}
Microsoft recommends against the m_ (and the straight _) even though they did both in their code.
Use camel case.
Ex: private int _someNumber
5. Suffix custom attributes classes with Attribute.
-
Follow class naming conventions, but add Attribute to the end of the name
Ex: SomeNumberAttribute
-
6. Suffix custom exception classes with Exception.
Follow class naming conventions, but add Exception to the end of the name
Ex: SomeNumberException
-
7. Name methods using verb-object pair, such as ShowDialog ()
-
8. Methods with return values should have a name describing the value returned, such
as GetObjectState().
-
9. Use descriptive variable names. Avoid one-character variable names, such as i or t. Use index or temp instead.
Counting variables are preferably called i, j, k, l, m, n when used in 'trivial'
counting loops, but try using meaningful names for variables used as counters
E.g. EmpCount
Use Pascal Casing.
-
10. All member variables should be declared at the top, with one line separating them
from the properties or methods
public class MyClass
{
int m_Number;
string m_Name;
public void SomeMethod1(){}
public void SomeMethod2(){}
Page 6 of 21
}
11. Declare a local variable as close as possible to its first use.
12. Use meaningful namespaces such as the product name, company name, etc.
Namespace names must be nouns or noun phrases.
Use Pascal Casing no underscores.
Use CompanyName.TechnologyName as root. If you don't have
a company, use your domain name or your own initials. Note that any acronyms of
three or more letters should be pascal case (Xml instead of XML) instead of all caps
Ex:.DotNetTraining.Xml
Use hierarchical names for namespaces with dots as separation points for namespaces that are related and can be grouped together. For example consider the following:
Database - Main namespace
Database.Records - Records namespace
Database.Tables - Table functions namespace
-
13. Avoid fully qualified type names. Use the using statement instead.
-
14. Avoid putting a using statement inside a namespace.
-
15. Group all framework namespaces together and put custom or third party namespaces beneath.
using System;
using System. Collections;
using System.ComponentModel;
using System.Data;
using MyCompany;
using MyControls;
-
16. A file name should reflect the class it contains.
-
17. Always place an open curly brace ({) in a new line.
-
18. With anonymous methods mimic the code layout of a regular method, aligned with the anonymous delegate declaration.
Follow class naming conventions, but add Delegate to the end of the name
-
a. Comply with placing an open curly brace in a new line
delegate void SomeDelegate(string str);
//Correct:
public void InvokeMethod()
Page 7 of 21
{
SomeDelegate del = delegate(string str)
{
MessageBox.Show(str);
}
del("Hello");
}
//Avoid
public void InvokeMethod()
{
SomeDelegate del = delegate(string str){MessageBox.Show(str);};
del("Hello");
}
Varaible/Paramater Type Prefix
-
Basic Type
Prefix
sbyte (System.Sbyte)
sbyt
byte (System.Byte)
byt
char (System.Char)
chr
short (System.Int16)
sh
ushort (System.UInt16)
ush
bool (System.Boolean)
b
int (System.Int32)
n
uint (System.UInt32)
un
long (System.Int64)
l
ulong (System.UInt64)
ul
decimal (System.Decimal)
dc
double (System.Double)
d
float (System.Single)
f
string (System.String)
s
DateTime
dt
TimeSpan
ts
object (System.Object)
o
-
3.2 Comments and Embedded Documentation
-
1. Each file shall contain a header block.
-
The header block must consist of a #region block containing the following copyright statement and the name of the file.
2. Use // for comments.
Page 8 of 21
-
3. Do not use blocks of //-------- or //********.
-
4. All comments shall be written in English.
-
5. Use XML tags for documenting types and members.
All public and protected types, methods, fields, events, delegates, etc. shall be documented using XML tags. Using these tags will allow IntelliSense to provide useful details while using the types. Also, automatic documentation generation tooling relies on these tags.
Section tags define the different sections within the type documentation.
-
Section Tags
Description
Location
<summary>
Short description
type or member
<remarks>
Describes preconditions and other additional information.
type or member
<param>
Describes the parameters of a method
method
<returns>
Describes the return value of a method
method
<exception>
Lists the exceptions that a method or property can throw
method, even or property
<value>
Describes the type of the data a property accepts and/or returns
property
<example>
Contains examples (code or text) related to a member or a type
type or member
<seealso>
Adds an entry to the See Also section
type or member
<overloads>
Provides a summary for multiple overloads of a method
first method in a
overload list.
SECTION TAGS DESCRIPTION LOCATION
Inline tags can be used within the section tags.
-
Inline Tags
Description
<see>
Creates a hyperlink to another member or type
<paramref>
Creates a checked reference to a parameter
Markup tags are used to apply special formatting to a part of a section. Page 9 of 21
-
Markup Tags
Description
<code>
Changes the indentation policy for code examples
<c>
Changes the font to a fixed-wide font (often used with the <code> tag)
<para>
Creates a new paragraph
<list>
Creates a bulleted list, numbered list, or a table.
<b>
Bold typeface
<i>
Italics typeface
Exception:
In an inheritance hierarchy, do not repeat the documentation but use the <see> tag to refer to the base class or interface member.
-
6. Use #region to group non-public members.
If a class contains a large number of members, attributes, and/or properties, put all non-public members in a region. Preferably, use separate regions to split-up the private, protected, and internal members, and a region to hide all fields. It is also allowed to use the #region construct for separating the smaller auxiliary classes from the main class.
Page 10 of 21
-
3.3 Coding Practices
-
1. Always use C# predefined types rather than the aliases in the System namespace.
-
For example:
object NOT Object
string NOT String
int NOT Int32
2. Avoid putting multiple classes in a single file.
3. A single file should only contribute types to a single namespace. Avoid having multiple namespaces in the same file.
4. Avoid files with more than 500 lines (excluding machine-generated code).
5. Lines should not exceed 80 characters.
6. Do not manually edit any machine-generated code.
7. If modifying machine-generated code, modify the format and style to match this
coding standard.
8. Avoid comments that explain the obvious.
9. Document only operational assumptions, algorithm insights etc.
10. Never hard-code a numeric value, always declare a constant instead.
11. Make only the most necessary types public, mark others as internal.
12. Always use zero-based arrays.
13. Avoid specifying a type for an enum (like long).
14. Never use goto unless in a switch statement fall-through.
15. Avoid function calls in Boolean conditional statements. Assign into local variables and check on them:
bool IsEverythingOK()
{…}
//Avoid:
if(IsEverythingOK())
{…}
//Instead:
bool ok = IsEverythingOK();
if(ok)
{…}
-
16. Only catch exceptions for which you have explicit handling.
Page 11 of 21
-
17. Avoid error code as methods return values.
-
18. Do not use the new inheritance qualifier. Use override instead.
-
19. Minimize code in application assemblies (EXE client assemblies), use class libraries instead to contain business logic.
-
20. Never hardcode strings that will be presented to end-users. Use resources instead.
-
21. Never hardcode strings that might change based on deployment such as connection strings.
-
22. Never use unsafe code unless when using interop.
-
23. Avoid multiple Main() methods in a single assembly.
-
24. Never assume a type supports an interface. Defensively query for that interface.
SomeType obj1;
IMyInterface obj2;
/* Some code to initialize obj1, then: */
obj2 = obj1 as IMyInterface;
if(obj2 != null)
{
obj2.Method1();
}
else
{
//Handle error in expected interface
}
25. Do not provide public or protected member variables. Use properties instead.
-
26. Do not provide public event member variables. Use event assessors instead.
public class MySource
{
MyDelegate m_NumberChangedEvent;
public event MyDelegate NumberChangedEvent
{
add
{
m_NumberChangedEvent + = value;
}
remove
{
m_NumberChangedEvent - = value;
}
}
}
Page 12 of 21
-
27. Avoid events as interface members.
-
28. Avoid abstract methods, use interfaces instead.
-
29. Always mark public and protected methods as virtual in a non-sealed class.
-
30. When building a long string, use StringBuilder, not string.
-
31. Always use a curly brace scope in an if statement, even if it conditions a single statement.
-
32. Always provide a static constructor when providing static member variables.
-
33. Avoid code that relies on an assembly running from a particular location.
-
34. Do not use late-binding invocation when early-binding is possible.
-
35. Avoid using the trinary conditional operator.
-
36. Use the EventsHelper class to publish events defensively.
-
37. Use application logging and tracing.
-
38. Do not use the base word to access base class members unless you wish to resolve a conflict with a subclasses member of the same name or when invoking a base class Constructor.
-
4 Object Lifecycle
-
1. Declare and initialize variables close to where they are used.
-
2. If possible, initialize variables at the point of declaration.
-
If you use field initialization then instance fields will be initialized before the instance constructor is called. Likewise, static fields are initialized when the static constructor is called. Notice that the compiler will always initialize any uninitialized reference variable to zero.
3. Declare each variable in a separate declaration statement.
4. Use a const field to define constant values.
Making it const ensures that memory is allocated for that item only once.
private const int maxUsers = 100;
Exception
If the value of a constant field must be calculated at run-time (in the static constructor), use a static read only field instead.
-
5. Set a reference field to null to tell the Garbage Collector that the object is no longer needed.
Setting reference fields to null may improve memory usage because the object involved will be unreferenced from that point on, allowing the Garbage Collector
Page 13 of 21
to clean-up the object much earlier. Please note that this recommendation should not be followed for a variable that is about to go out of scope.
6. Avoid implementing a destructor.
The use of destructors in C# is demoted since it introduces a severe performance penalty due to way the Garbage Collector works. It is also a bad design pattern to clean up any resources in the destructor since you cannot predict a which time the destructor is called (in other words, it is non-deterministic).
Notice that C# destructors are not really destructors as in C++. They are just a C# compiler feature to represent CLR Finalizers.
7. If a destructor is needed, also use GC.SuppressFinalize.
If a destructor is needed to verify that a user has called certain cleanup methods such as Close() on a IpcPeer object, call GC.SuppressFinalize in the Close() method. This ensures that the destructor is ignored if the user is properly using the class.
8. Implement IDisposable if a class uses unmanaged or expensive resources.
If a class uses unmanaged resources such as objects returned by C/C++ DLLs, or expensive resources that must be disposed of as soon as possible, you must implement the IDisposable interface to allow class users to explicitly release such resources.
9. Do not access any reference type members in the destructor.
When the destructor is called by the Garbage Collector, it is very possible that some or all of the objects referenced by class members are already garbage collected, so dereferencing those objects may cause exceptions to be thrown. Only value type members can be accessed (since they live on the stack).
-
4.1 Control Flow
-
1. Do not change a loop variable inside a for loop block.
-
Updating the loop variable within the loop body is generally considered confusing, even more so if the loop variable is modified in more than one place.
2. Update loop variables close to where the loop condition is specified.
This makes understanding the loop much easier.
All flow control primitives (if, else, while, for, do, switch) shall be followed by a block, even if it is empty.
Please note that this also avoids possible confusion in statements of the form:
if (b1) if (b2) Foo(); else Bar(); // which ‘if’ goes with the ‘else’?
-
3. All switch statements shall have a default label as the last case label.
Page 14 of 21
A comment such as “no action” is recommended where this is the explicit intention. If the default case should be unreachable, an assertion to this effect is recommended.
4. Avoid multiple or conditional return statements.
One entry, one exit is a sound principle and keeps control flow simple. However, if some cases, such as when preconditions are checked, it may be good practice to exit a method immediately when a certain precondition is not met.
5. Do not make explicit comparisons to true or false.
It is usually bad style to compare a bool-type expression to true or false.
Example:
while (condition == false) // wrong; bad style
while (condition != true) // also wrong
while (booleanCondition) // OK
6. Do not access a modified object more than once in an expression.
The evaluation order of sub-expressions within an expression is defined in C#, in contrast to C or C++, but such code is hard to understand.
Example:
v[i] = ++c; // right
v[i] = ++i; // wrong: is v[i] or v[++i] being assigned to?
i = i + 1; // right
i = ++i + 1; // wrong and useless; i += 2 would be clearer
7. Do not use selection statements (if, switch) instead of a simple assignment or initialization.
Express your intentions directly. For example, rather than
bool pos;
if (val > 0)
{
pos = true;
}
else
{
pos = false;
}
or (slightly better)
bool pos = (val > 0) ? true : false;
write
Page 15 of 21
bool pos;
pos = (val > 0); // single assignment
or even better
bool pos = (val > 0); // initialization
-
4.2 Object Oriented Programming
-
1. Declare all fields (data members) private.
-
2. Explicitly define a protected constructor on an abstract base class.
-
3. Selection statements (if-else and switch) should be used when the control flow depends on an object’s value; dynamic binding should be used when the control flow depends on the object’s type. This is a general OO principle. Please note that it is usually a design error to write a selection statement that queries the type of an object (keywords typeof, is).
-
Exception:
Using a selection statement to determine if some object implements one or more optional interfaces is a valid construct though.
4. All variants of an overloaded method shall be used for the same purpose and have similar behavior.
-
4.3 Use C# to describe pre-conditions post-conditions, exceptions, and class invariants.
-
1. It shall be possible to use a reference to an object of a derived class wherever a reference to that object’s base class object is used.
-
2. Do not modify the value of any of the operands in the implementation of an overloaded operator.
-
3. Use a struct when value semantics are desired. More precisely, a struct should be considered for types that meet any of the following criteria:
-
� Act like primitive types.
-
� Have an instance size fewer than .16 bytes.
-
� Are immutable.
-
� Value semantics are desirable.
-
� Remember that a struct cannot be derived from.
-
4. Allow properties to be set in any order.
-
Properties should be stateless with respect to other properties, i.e. there should not be an observable difference between first setting property A and then B and its reverse.
Page 16 of 21
-
5. Use a property rather than a method when the member is a logical data member.
-
6. Use a method rather than a property when this is more appropriate.
In some cases a method is better than a property:
-
� The operation is a conversion, such as Object.ToString.
-
� The operation is expensive enough that you want to communicate to the user that they should consider caching the result.
-
� Obtaining a property value using the get accessor would have observable side effect.
-
� Calling the member twice in succession produces different results.
-
� The order of execution is important
-
� The member is static but returns a value that can be changed.
-
� The member returns a copy of an internal array or other reference type.
-
� Only a set accessor would be supplied. Write-only properties tend to be confusing.
-
7. Do not create a constructor that does not yield a fully initialized object.
-
8. Always check the result of an as operation.
If you use as to obtain a certain interface reference from an object, always ensure that this operation does not return null. Failure to do so may cause a NullReferenceException at a later stage if the object did not implement that interface.
-
4.4 Exceptions
Name exceptions with the “Exception” suffix.
Use Pascal Casing
Consider naming exceptions using nouns or noun phrases
-
1. Only throw exceptions in exceptional situations.
Do not throw exceptions in situations that are normal or expected (e.g. end-of-file). Use return values or status enumerations instead. In general, try to design classes that do not throw exceptions in the normal flow of control. However, do throw exceptions that a user is not allowed to catch when a situation occurs that may indicate a design error in the way your class is used.
2. Do not throw exceptions from inside destructors.
When you call an exception from inside a destructor, the CLR will stop executing the destructor, and pass the exception to the base class destructor (if any). If there is no base class, then the destructor is discarded.
3. Only re-throw exceptions when you want to specialize the exception.
Page 17 of 21
Only catch and re-throw exceptions if you want to add additional information and/or change the type of the exception into a more specific exception. In the latter case, set the InnerException property of the new exception to the caught exception.
4. List the explicit exceptions a method or property can throw.
Describe the recoverable exceptions using the <exception> tag.
Explicit exceptions are the ones that a method or property explicitly throws from its implementation and which users are allowed to catch. Exceptions thrown by .NET framework classes and methods used by this implementation do not have to be listed here.
5. Always log that an exception is thrown.
Logging ensures that if the caller catches your exception and discards it, traces of this exception can be recovered at a later stage.
6. Allow callers to prevent exceptions by providing a method or property that returns the object’s state.
For example, consider a communication layer that will throw an InvalidOperationException when an attempt is made to call Send () when no connection is available. To allow preventing such a situation, provide a property such as Connected to allow the caller to determine if a connection is available before attempting an operation.
7. Use standard exceptions.
8. Throw informational exceptions.
When you instantiate a new exception, set its Message property to a descriptive message that will help the caller to diagnose the problem
9. Throw the most specific exception possible.
10. Do not throw an exception from inside an exception constructor.
Throwing an exception from inside an exception’s constructor will stop the construction of the exception being built, and hence, preventing the exception from getting thrown. The other exception is thrown, but this can be confusing to the user of the class or method concerned.
-
4.5 Delegates & Events
-
1. Do not make assumptions on the object’s state after raising an event.
-
Prepare for any changes to the current object’s state while executing an event handler. The event handler may have called other methods or properties that changed the object’s state (e.g. it may have disposed objects referenced through a field).
Page 18 of 21
-
2. Raise events through a protected virtual method.
If a derived class wants to intercept an event, it can override such a virtual method, do its own work, and then decide whether or not to call the base class version. Since the derived class may decide not to call the base class method, ensure that it does not do any work required for the base class to function properly. Name this method OnEventName, where EventName should be replaced with the name of the event.
3. Use the sender/arguments signature for event handlers.
The goal of this recommendation is to have a consistent signature for all event handlers. In general, the event handler’s signature should look like this public delegate void MyEventHandler(object sender, EventArgs arguments)
Using the base class as the sender type allows derived classes to reuse the same event handler. The same applies to the arguments parameter. It is recommended to derive from the .NET Framework’ s EventArgs class and add your own event data. Using such a class prevents cluttering the event handler’ signature, allows extending the event data without breaking any existing users, and can accommodate multiple return values (instead of using reference fields). Moreover, all event data should be exposed through properties, because that allows for verification and preventing access to data that is not always valid in all occurrences of a certain event.
4. Implement add/remove accessors if the number of handlers for an event must be limited.
If you implement the add and remove accessors of an event, then the CLR will call those accessors when an event handler is added or removed. This allows limiting the number of allowed event handlers, or to check for certain preconditions.
Consider providing property-changed events.
Consider providing events that are raised when certain properties are changed. Such an event should be named
PropertyChanged, where Property should be replaced with the name of the property with which this event is associated.
5. Consider an interface instead of a delegate.
If you provide a method as the target for a delegate, the compiler will only ensure that the method signature matches the delegate’s signature.
This means that if you have two classes providing a delegate with the same signature and the same name, and each class has a method as a target for that delegate, it is possible to provide the method of the first class as a target for the
Page 19 of 21
delegate in the other class, even though they might not be related at all. Therefore, it is sometimes better to use interfaces. The compiler will ensure that you cannot accidentally provide a class implementing a certain interface to a method that accepts another interface that happens to have the same name.
-
5 Framework Specific Guidelines
-
5.1 Data Access
-
1. Always use type-safe data sets. Avoid raw ADO.NET.
-
2. Always use transactions when accessing a database.
-
3. Always use transaction isolation level set to Serializable.
-
a. Requires management decision to use anything else.
-
4. Do not use the Server Explorer to drop connections on windows forms, ASP.NET forms or web services. Doing so couples the presentation tier to the data tier.
-
5. Avoid SQL Server authentication.
-
a. Use Windows authentication instead.
-
6. Run components accessing SQL Server under separate identity from that of the calling client.
-
7. Always warp your stored procedures in a high level, type safe class. Only that class invokes the stored procedures.
-
8. Avoid putting any logic inside a stored procedure.
-
a. If there is an IF inside a stored procedure, you are doing something wrong.
-
-
5.2 ASP.NET and Web Services
-
1. Avoid putting code in ASPX files of ASP.NET. All code should be in the code behind class.
-
2. Code in code behind class of ASP.NET should call other components rather than contain direct business logic.
-
3. In both ASP.NET pages and web services, wrap a session variables in a local property. Only that property is allowed to access the session variable, and the rest of the code uses the property, not the session variable.
-
4. In transactional pages or web services, always store session in SQL server.
-
5. Strive to provide interfaces for web services
-
6. Always provide namespace and service description for web services.
-
7. Always provide a description for web methods.
-
Page 20 of 21
-
8. When adding a web service reference, provide meaningful name for the location.
-
9. Always modify client-side web service wrapper class to support cookies.
-
a. You have no way of knowing whether the service uses Session state or not.
-
5.3 Serialization
-
1. Always mark non-sealed classes as Serializable.
-
2. Always mark un-serializable member variables as non serializable.
-
3. Always mark delegates on a serialized class as non-serializable fields:
-
[Serializable]
public class MyClass
{
[field:NonSerialized]
public event MyDelegate Delegate;
}
-
5.4 Remoting
-
1. Prefer administrative configuration to programmatic configuration.
-
2. Always implement IDisposable on a single call objects.
-
3. Always prefer TCP channel and binary format when using remoting.
-
a. Unless a firewall is present.
-
4. Always provide a null lease for a singleton object.
-
public class MySingleton : MarshalByRefObject
{
public override object InitializeLifetimeService()
{
return null;
}
}
5. Always provide a sponsor for a client-activated object. Sponsor should return initial lease timed.
6. Always unregistered a sponsor on client application shutdown.
7. Always put remote objects in class libraries.
8. Avoid using SoapSuds.
9. Avoid hosting in IIS.
10. Avoid using uni-directional channels.
Page 21 of 21
-
11. Always elevate type filtering to full on both client and host to allow callbacks.
Host Config file:
<channels>
<channel ref="tcp" port="8005">
<serverProviders>
<formatter ref="soap" typeFilterLevel="Full"/>
<formatter ref="binary" typeFilterLevel="Full"/>
</serverProviders>
</channel>
<channel ref="http" port="8006">
<serverProviders>
<formatter ref="soap" typeFilterLevel="Full"/>
<formatter ref="binary" typeFilterLevel="Full"/>
</serverProviders>
</channel>
</channels>
Client Config file:
<channels>
<channel ref="tcp" port="0">
<serverProviders>
<formatter ref="soap" typeFilterLevel="Full"/>
<formatter ref="binary" typeFilterLevel="Full"/>
</serverProviders>
</channel>
</channels>
Subscribe to:
Posts (Atom)