We have separated the unit tests, one for each project, for several reasons:

• It provides a clear separation of concerns and allows each component to be individually tested
• The different libraries can be used on other projects with confidence as there are a set of tests around them

For common library project, project name should include the company prefix and solution name, this is so other internal solution can include the common library's project. This will help debugging and development processes.

For project documents, we should also add them into solution for later reference, and different document types will be put in different folder, e.g. Mockup files will be in Northwind\Documents\Mockup\

An ideal way is to create "sub-solution folders" for the solution items, the common ones are "References" and "Setup". This feature is only available in Visual Studio 2005. This will make your solution items look neat and in order. Look at the screenshot below, now it makes sense, we know that the _Instructions.txt contains the instructions of what to do when creating a setup.exe.

So, always set Option Strict On right from the beginning of the development.

Before you do this, you should first back up the entire VBWizards directory. If you make a mistake, then the templates will not load in the VS environment. You need to be able to restore the default templates if your updates cause problems.

To configure each template to default Option Strict to On rather than Off, load each .vbproj template with VB source code into an editor like Notepad and then change the XML that defines the template. For example, to do this for the Windows Application template, load the file: Windows Application\Templates\1033\WindowsApplication.vbproj

Technically, you do not have to add the Option Explicit directive, because this is the default for VB; but I like to do it for consistency. Next, you must save the file and close Notepad. Now, if you load a new Windows Application project in the VS environment and examine Project Properties, you will see that Option Strict has been turned on by default.

In order for this setting to take effect for all project types, you must update each of the corresponding .vbproj templates. After making the changes on your system, you will need to deploy the new templates to each of your developers' machines in order for their new projects to derive from the updated templates.

However, sometimes we don't do this because of too much work. In some scenarios, such as Wrappers around the COM code, and Outlook stuff with object model, there is going to be lots of work to fix all the type-checking errors. Actually it is necessary to use Object type as parameters or variables when you deal with COM components.

This is because IntelliSense lists will be harder to use and navigate with too many imports. For example if in VB.NET, Microsoft.VisualBasic would be a good item to have in the imports list, because it will be used in most areas of your application.

To remove all the default imports, load Project Property page and select Common properties - Imports.

The Import statement makes it easier to access methods of classes by eliminating the need to explicitly type the fully qualified reference names. Aliases let you assign a friendlier name to just one part of a namespace.

For example, the carriage return-line feed sequence that causes a single piece of text to be displayed on multiple lines is part of the ControlChars class in the Microsoft.VisualBasic namespace. To use this constant in a program without an alias, you would need to type the following code:

    MsgBox("Some text" & Microsoft.VisualBasic.ControlChars.crlf _
    & "Some more text")

Imports statements must always be the first lines immediately following any Option statements in a module. The following code fragment shows how to import and assign an alias to the Microsoft.VisualBasic.ControlChars namespace:

Imports CtrlChrs=Microsoft.VisualBasic.ControlChars

MsgBox("Some text" & CtrlChrs.crlf & "Some more text")

If an Imports statement does not include an alias name, elements defined within the imported namespace can be used in the module without qualification. If the alias name is specified, it must be used as a qualifier for names contained within that namespace.

In the following extract of a sample Web.config file you can see the problem. The local machine "HIPPO" has, of course, another WebServiceURL than the Webserver "SEAL". So you have to keep two versions of the Web.config file, one when working on "HIPPO" and one when working on "SEAL".

<add key="SEAL_WebServiceURL"
    value="http://host.something.com:80/SomeDirectory/Filename.asmx"/> 
    <add key="HIPPO_WebServiceURL"
    value="http://name:80/SomeDirectory/Filename.asmx"/>

There is a better solution:

Public Shared Function GetWebConfigString(ByVal StringName As String) As String
Dim strReturn As String = ""
Dim strComputerName As String = System.Net.Dns.GetHostName
Try
strReturn = ConfigurationSettings.AppSettings( strComputerName.ToUpper _
+ "_"+ StringName)
Catch
strReturn = ConfigurationSettings.AppSettings(StringName)
End Try
Return strReturn
End Function

This class simply adds the name of the Computer on which it is running on to the WebConfigString. In the former example, this would be "HIPPO_" or "SEAL_".

Instead of using the WebConfigString directly you can now transform it using this function. With the help of this code, you always get the right value for the WebConfigString, no matter on which machine the application runs and you don't have to care about synchronizing the Web.config file any more.

System.IO

contains all the classes that deal with inputs and outputs. As a general rule of thumb your assemblies should be named as follows:

<CompanyName>.<ComponentName> (e.g. SSW.Framework)

This allows a developer to know who developed the assembly and give the developer a general idea of what the assembly can be used for.

Things that do not belong in the designer:

• Connections
• Commands
• DataAdapters

However, and DataAdapter objects should not be dragged onto forms, as they belong in the business tier. Strongly typed DataSet objects should be in the designer as they are simply passed to the business layer. Avoid writing code for properties that can be set in the designer.

• Scenario #1: Images that are part of the content of a specific page eg. a picture used only on one page
• Scenario #2:Images that are shared across on user controls which are shared across different pages in a site eg. a shared logo used across the site (commonly in user controls, or master pages)

Each of these situations requires a different referencing method.

Option #1:Absolute Paths (Root-Relative Paths)
Often developers reference all images by using an absolute path (prefixing the path with a slash, which refers to the root of the site), as shown below.

<img src="/Images/spacer.gif" height="1" width="1">

This has the advantage that <img> tags can easily be copied between pages, however it should not be used in either situation, because it requires that the website have its own site IIS and be placed in the root (not just an application), or that the entire site be in a subfolder on the production web server. For example, the following combinations of URLs are possible with this approach:

As shown above, this approach makes the URLs on the staging server hard to remember, or increases the length of URLs on the production web server.

Verdict for Scenario #1:

Verdict for Scenario #2:

Option #2:Relative Paths
Images that are part of the content of a page should be referenced using relative paths, e.g.

<img src="../Images/spacer.gif" height="1" width="1">

However, this approach is not possible with images on user controls, because the relative paths will map to the wrong location if the user control is in a different folder to the page.

Verdict for Scenario #1:

Verdict for Scenario #2:

Option #3:Application-Relative Paths
In order to simplify URLs, ASP.NET introduced a new feature, application relative paths. By placing a tilde (~) in front of a path, a URL can refer to the root of a site, not just the root of the web server. However, this only works on Server Controls (controls with a runat="server" attribute).

To use this feature, you need either use ASP.NET Server controls or HTML Server controls, as shown below.

 <asp:Image ID="spacerImage" ImageUrl="~/Images/spacer.gif" Runat="server" />
<img id="spacerImage" src="~/Images/spacer.gif" originalAttribute="src" originalPath=""~/Images/spacer.gif"" runat="server">

Using an HTML Server control creates less overhead than an ASP.NET Server control, but the control does not dynamically adapt its rendering to the user's browser, or provide such a rich set of server-side features.

Verdict for Scenario #1:

Verdict for Scenario #2:

Note:A variation on this approach involves calling the Page.ResolveUrl method with inline code to place the correct path in a non-server tag.

 <img src='<%# originalAttribute="src" originalPath="'<%#" Page.ResolveUrl("~/Images/spacer.gif") %>'>

This approach is not recommended, because the data binding will create overhead and affect caching of the page. The inline code is also ugly and does not get compiled, making it easy to accidentally introduce syntax errors.

Avoid:

• InputBox
• ControlArray
• ADO support in Microsoft.VisualBasic.Compatibility.Data
• Environment functions
• Font conversions

Corresponding with Microsoft's release of their application blocks, we've also started to build components and share them across projects.

Sharing a binary file with SourceSafe isn't a breeze to do, and here are the steps you need to take. It can be a bit daunting at first.

As the component developer, there are four steps:

1. In Visual Studio.NET, Switch to release build
   Figure: Switch to release configuration
2. In your project properties, make sure the release configuration goes to the bin\Release? folder. While you are here, also make sure XML docs are generated. Use the same name as your dll but change the extension to .xml (eg. for SSW.Framework.Configuration.dll -> add SSW.Framework.Configuration.xml)
   Figure: Project properties

   Note: The following examples are considered being used for C#. Visual Basic, by default, does not have \bin\Release and \bin\Debug which which means that the debug and release builds will overwrite each other unless the default settings are changed to match C# (recommended). VB does not support XML comments either, please wait for the next release of Visual Studio (Whidbey).

   Figure: Force change to match C#
3. If this is the first time, include/check-in the release directory into your SourceSafe
   Figure: Include the bin\Release directory into source safe
4. Make sure everythings checked-in properly. When you build new versions, switch to Release?mode and checkout the release dlls, overwrite them, and when you check them back in they will be the new dll shared by other applications.

5. If the component is part of a set of components, located in a solution, with some dependency between them. You need to check out ALL the bin\Release folders for all projects in that solution and do a build. Then check in all of them. This will ensure dependencies between these components don't conflict with projects that reference this component set.

   In other words, a set of components such as SSW.Framework.WindowsUI.xxx, increment versions AS A WHOLE. One component in this set changes will cause the whole set to re-establish internal references with each other.

When you face a bug, there are 2 types of emails you can send:

1. Dan, I get this error calling your Registration.dll? or
2. Dan, I get this error calling your Registration.dll and I have investigated it. As per our conversation, I have changed this xxx to this xxx.

The 2nd option is preferable.

• If there are no bugs then reference the assembly, and
• If there are bugs in the project (or any project it references [See note below]) then reference the project.

Since most applications have bugs, therefore most of the time you should be using the second option.

If it is a well tested component and it is not changing constantly, then use the first option.

1. Add the project to solution (if it is not in the solution). Figure: Add existing project
2. Select the "References" folder of the project you want to add references to, right click and select "Add Reference...".
   Figure: Add reference
3. Select the projects to add as references and click OK. Figure: Select the projects to add as references

Note: We have run into a situation where we reference a stable project A, and an unstable project B. Project A references project B. Each time project B is built, project A needs to be rebuilt.

Now, if we reference stable project A by dll, and unstable project B by project according to this standard, then we might face referencing issues, where Project A will look for another version of Project B ?the one it is built to, rather than the current build, which will cause Project A to fail.

To overcome this issue, we then reference by project rather than by assembly, even though Project A is a stable project. This will mitigate any referencing errors.

As the component user, there are six steps, but you only need to do them once:

1. First, we need to get the folder and add it to our project, so in SourceSafe, right click your project and create a subfolder using the Create Project (yes, it is very silly name) menu. Figure: Create 'folder' in Visual Source Safe

   Name it References

   Figure: 'References' folder
2. Share the dll from the directory, so if I want SSW.Framework.Configuration, I go to $/ssw/SSWFramework/Configuration/bin/Release/
   I select both the dll and the dll.xml files, right-click and drag them into my $/ssw/zzRefs/References/ folder that I just created in step 1. Figure: Select the dlls that I want to use Figure: Right drag, and select "Share"
3. Still in SourceSafe, select the References folder, run get latest?to copy the latest version onto your working directory.
   Figure: Get Latest from Visual Source Safe VSS may ask you if you want to create the folder, if it doesnt exist. Yes, we do.
4. Back in VS.NET, select the project and click the show-all files button in the solution explorer, include the References folder into the project (or get-latest if its already there)
   Figure: Include the files into the current project
5. IMPORTANT! If the files are checked-out to you when you include them into your project, you MUST un-do checkout immediately.
   You should never check in these files, they are for get-latest only.
   Figure: Undo Checkout, when VS.NET checked them out for you...
6. Add Reference?in VS.NET, browse to the References?subfolder and use the dll there.
7. IMPORTANT! You need to keep your 'References' folder, and not check the files directly into your bin directory. Otherwise when you 'get latest', you won't be able to get the latest shared component.

All done. In the future, whenever you do get-latest?on the project, the any updated dlls should come down and be linked the next time you compile. Also, if anyone checks out your project from Source Safe, they will have the project linked and ready to go.

connection.ConnectionString = "
Provider=SQLOLEDB;
Data Source=server_name_or_address; Initial Catalog=database_name;
User ID=username; Password=password; ";

   connection.Open();

connection.ConnectionString = ConfigurationManager.Items["ConnectionString"];

 connection.Open();

<asp:TreeView ID="TreeView1" runat="server" DataSourceID="siteMapDataSource"
ImageSet="Faq" SkipLinkText =""> 
<ParentNodeStyle Font-Bold="False" /> 
<HoverNodeStyle Font-Underline="True" ForeColor="Purple" />   
<SelectedNodeStyle Font-Underline="True" HorizontalPadding="0px"
VerticalPadding="0px" /> 
<NodeStyle Font-Names="Tahoma" Font-Size="8pt" ForeColor="DarkBlue"
HorizontalPadding="5px" NodeSpacing="0px" VerticalPadding="0px" />
</asp:TreeView>
<asp:SiteMapDataSource ID="siteMapDataSource"  runat="server" />                    

<asp:Xml ID="Xml1" runat="server" DocumentSource="~/Web.xml"
TransformSource="~/Style.xsl"></asp:Xml> 

1. App.Config/Web.Config is the default .NET settings file, including any settings for the Microsoft Application Blocks (eg. the Exception Management Block and the Configuration Management Block). These are for settings that dont change from within the application. In addition, System.Configuration classes dont allow writing to this file.
2. ToolsOptions.Config (an SSW standard) is the file to hold the users own settings, that are users can change in the Tools - Options.
   Eg. ConnectionString, EmailTo, EmailCC
   Note: We read and write to this using Microsoft Configuration Application Block. If we don't use this Block we would store it as a plain XML file and read and write to it using System.XML classes. The idea is that if something does go wrong when you are writing to this file, at least the App.Config would not be affected. Also, this separates our settings (which are few) from the App.Config (which usually has a lot of stuff that we really dont want a user to stuff around with).
3. UserSession.Config (an SSW standard). These are for additional setting files that the user cannot change.
   e.g. FormLocation, LastReportSelected
   Note: This file is over writable (say during a re-installation) and it will not affect the user if the file is deleted.                                                                        

WSE has been outdated and replaced by WCF and has provided its own set of attributes that can be plugged into any Web Service application.

1. Security
   Implementation of security at the message layer security has several policies that can suite any environment including:
   1. Windows Token
   2. UserName Token
   3. Kerbose Token
   4. X.509 Certificate Token
   At SSW we implement UserName Token using the standard login screen that prompts for a Username and a Password, which then gets passed into the SOAP header (at message level) for authorization.
   This requires SSL which provides a secure tunnel from client to server.
   However, message layer securtiy does not provide authentication security, so it does not stop the ability for a determined hacker to try user name / password attempts forever. Custom Policies setup at Application Level can to prevent brute force.
2. Performance
   Indigo has got the smarts to negotiate to the most performant serialization and transport protocol that either side of the WS conversation can accommodate, so it will have the best performance having "all-things-being-equal". You can configure the web services SSL session simply in the web.config file.
   After having Configure an SSL certificate (in the LocalMachine store of the server), the following lines are required in the web.config:

<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
<system.serviceModel>
<services>
<service type="WCFService" name="WCFService"
behaviorConfiguration="ServiceBehaviour">
<endpoint contract="IWCFService" binding="wsHttpBinding"
bindingConfiguration="WSHttpBinding_IWCFServiceBinding"/>
</service>
</services>
<bindings>
<wsHttpBinding>
<binding name="WSHttpBinding_IWCFServiceBinding" >
<security mode="Message">
<message clientCredentialType="UserName" />
</security>
</binding>
</wsHttpBinding>
</bindings>
<behaviors>
<behavior name="ServiceBehaviour" returnUnknownExceptionsAsFaults="true" >
<serviceCredentials>
<serviceCertificate findValue="CN=SSW" storeLocation="LocalMachine"             
storeName="My" x509FindType="FindBySubjectDistinguishedName"/>
    </serviceCredentials>
    </behavior>
    </behaviors>
    </system.serviceModel>
    </configuration>     

  try


  {

 
     cnn.Open();


     adapter.Fill(dataset);


  }


  catch (SQLException ex)


  {


     MessageBox.Show(ex.Message);


  }


  finally


  {


     //I'm in the finally block so that I always get called even if the fill fails.


     cnn.Close();


  }

Bad code - The connection code is not needed

  try


  {


     adapter.Fill(dataset);

 
  }


  catch (SQLException ex)


  {


     MessageBox.Show(ex.Message);


  }

Good code - letting the adapter worry about the connection.

The developers who prefer the first (more explicit) code example give the following reasons:

• Explicit Behaviour is always better. Code maintainability. Explicit code is more understandable than implicit code. Don't make your other developers have to look up the fact that data adapters automatically maintain the state of your connection for them.
• Consistency (or a lack of) - not all Framework classes are documented to behave like this. For example, the IDBCommand.ExecuteNonQuery() will throw an exception if the connection isn't open (it might be an interface method, but interface exceptions are documented as a strong guideline for all implementers to follow). The SqlCommand help doesn't mention anything further about this fact, but considering it's an inherited class, it would be fair to expect it to behave the same way. A number of the other methods don't make mention of connection state, making it difficult to know which basket to put your eggs into...
• Developer Awareness - it's healthy for the developer to be aware that they have a resource that needs to be handled properly. If they learn that they don't need to open and close connections here, then when they move onto using other resource types where this isn't the case then many errors may be produced. For example, when using file resources, the developer is likely to need to pass and open stream and needs to remember to close any such streams properly before leaving the function.
• Efficiency (sort of) - In a lot of code it will often populate more than one object at a time so that if I only open the connection once, execute multiple fills or commands, then close, then it'll be more clear about what the intent of the developer. If we left it to the framework, it's likely that the connection will be opened and closed multiple times; which despite it being really cheap to open out of the connection pool it will be slightly (itty bitty bit) more efficient but I think the explicit commands will demonstrate more clearly the intention of the developer.

Bottom line - I wont be swayed - but it is a controversial one. People who agree with me include:

• Ken Getz
• Paul Sheriff
• Bill Vaughan
• George Doubinski

People who don't:

• Chris Kinsman
• Richard Campbell
• Paul Reynolds

Microsoft's online guide to Improving ADO.NET performance to see their opinion and other tips.

One final note: This argument is a waste of time.... With code generators developing most of the Data Access layer of the application, the errors, if any, will be long gone and the developer is presented with higher level of abstraction that allows him/her to concentrate on more important things rather than mucking around with connections. Particularly considering that, when we start using the Provider model from Whidbey, it won't even be clear whether you're talking to SQL Server or to an XML file.

                        // C# 

                        try


                        {


                            cnn.Open();


                            cmd.ExecuteReader();


                        }


                        catch (SQLException ex)


                        {


                            MessageBox.Show(ex.Message);


                            cnn.Close();


                        }



 
                        'VB.NET 

                        Try


                            cnn.Open()


                            cmd.ExecuteReader()


                        Catch (ex as SQLException)


                            MessageBox.Show(ex.Message)


                            cnn.Close()


                        End Try

Bad code - Connection is not closed in the finally.

                        // C#
 
                        try


                        {


                            cnn.Open();


                            cmd.ExecuteReader();

 
                        }


                        catch (SQLException ex)


                        {


                            MessageBox.Show(ex.Message);


                        }


                        finally


                        {


                            cnn.Close();


                        }


                        ' VB.NET 

                        Try


                            cnn.Open()


                            cmd.ExecuteReader()

 
                        Catch (ex as SQLException)


                            MessageBox.Show(ex.Message)


                        Finally


                            cnn.Close()


                        End Try
                        

Good code - The cnn.open is in a Try and the cnn.Close is in a finally

// C#  
try  
{  
    cnn.Open();  
    cmd.ExecuteReader();  
}
catch  
{  }
finally  
{  
    cnn.Close();
}      

Bad code - Meaningless Catch block

// C#
try
{
    cnn.Open();
    cmd.ExecuteReader();
}
catch (SQLException ex)
{
    MessageBox.Show(ex.Message); 
}
finally
{
    cnn.Close();
}

Good code - Meaningful Catch block

The only exception should be - classes that collectively forms one atomic unit of reuse should live in one file. For example:

class MyClass

 
{


        ...


}




class MyClassAEventArgs


{


        ...


}




class MyClassBEventArgs


{


        ...


}




class MyClassAException


{


        ...


}




class MyClassBException


{


        ...


}

Bad example - 1 project, 1 file.

1. Use SqlCommand with an SQL INSERT statement and parameters:

   public void SQLInsert(string customerID, string companyName, string contactName)
   {
       SqlConnection sqlcon = new SqlConnection();
       sqlcon.ConnectionString = "Persist Security Info=False; 
                  Integrated Security=SSPI;database=northwindJV;
                  server=(local);Connect Timeout=5";
       SqlCommand sqlcmd = new SqlCommand();
       sqlcmd.CommandText = "INSERT Customers(CustomerID, CompanyName, 
                   ContactName) VALUES(@CustomerID, @CompanyName, @ContactName)";
       sqlcmd.Connection = sqlcon;
       sqlcmd.Parameters.Add("@CustomerID", customerID);
       sqlcmd.Parameters.Add("@CompanyName", companyName);
       sqlcmd.Parameters.Add("@ContactName", contactName);
       
       ... // for all columns
       
        try
       {
           sqlcon.Open();
           MessageBox.Show("The number of records updated was: " 
           + sqlcmd.ExecuteNonQuery().ToString());
       }
       finally
      {
           sqlcon.Close();
      }
   }

        Figure: Inserting rows using INSERT

   This approach has two problems - the SQL is inline in the code, and if the database schema is changed, INSERT statement will have to be manually updated.

2. Use SqlCommand and a stored procedure on the SQL Server:

   public void SPInsert(string firstName, string surname)
   {
           SqlConnection sqlcon = new SqlConnection();
           sqlcon.ConnectionString = "Persist Security Info=False;Integrated Security=SSPI; database=northwind;server=mySQLServer;Connect Timeout=30";
           SqlCommand sqlcmd = new SqlCommand();
           sqlcmd.CommandText = "proc_InsertCustomer";
           sqlcmd.CommandType = CommandType.StoredProcedure;
           sqlcmd.Connection = sqlcon;
           sqlcmd.Parameters.Add("@firstName", firstName);
           sqlcmd.Parameters.Add("@surname", surname);
           ... // for all columns
           try
           {
                   sqlcon.Open();
                   sqlcmd.ExecuteNonQuery();
           }
           finally
           {
                   sqlcon.Close();
           }
   }

        Figure: Inserting rows using SqlCommand and a stored procedure on the SQL Server

   This method is better because the SQL is not mixed up with the code (it is in a stored procedure), but it will still break if the database schema is changed, and the all of the parameters to the stored procedure have to be added manually.

3. Use DataAdapter with SQL INSERT statement, then use DataApdater.Update (strongly-typed-dataset)

   public void DASQLInsert(string firstName, string surname)
   {
           SqlConnection sqlcon = new SqlConnection();
           sqlcon.ConnectionString = "Persist Security Info=False; Integrated Security=SSPI; database=northwind; server=mySQLServer;Connect Timeout=30";
           SqlCommand sqlcmd = new SqlCommand();
           sqlcmd.CommandText = "INSERT Customers(firstName, surname) 
                     VALUES(@firstName, @surname)";
           sqlcmd.Connection = sqlcon;
           SqlDataAdapter sqladp = new SqlDataAdapter();
           sqladp.InsertCommand = sqlcmd;
       
           NorthWindCustomer dst = new NorthWindCustomer();
           NorthWindCustomer.CustomerRow row = dst.Customer.NewCustomerRow();
           row.FirstName = firstName;
           row.Surname = surname;
           dst.Customer.AddCustomerRow(row);
           try
           {
                   slqcon.Open();
                   sqladp.Update(dst);
           }
           finally
           {  
                   sqlcon.Close();
           }
   }

         Figure: Inserting rows using DataAdapter with SQL INSERT statement, then use DataApdater.Update

   In this example, the SQL is mixed up with the .NET code, and has to be manually updated if the database schema is changed. However, the strongly typed DataSet automatically updates when the database schema changes.

4. Use DataAdapter with a stored procedure for INSERT, then use DataAdapter.Update (strongly-typed-dataset)

   public void DASPInsert(string firstName, string surname)
   {
           SqlConnection sqlcon = new SqlConnection();
           sqlcon.ConnectionString = "Persist Security Info=False;
                     Integrated Security=SSPI; database=northwind;
                     server=mySQLServer;Connect Timeout=30";
           SqlCommand sqlcmd = new SqlCommand();
           sqlcmd.CommandText = "proc_InsertCustomer";
           sqlcmd.CommandType = CommandType.StoredProcedure;
           sqlcmd.Connection = sqlcon;
           SqlDataAdapter sqladp = new SqlDataAdapter();
           sqladp.InsertCommand = sqlcmd;
           NorthWindCustomer dst = new NorthWindCustomer();
           NorthWindCustomer.CustomerRow row = dst.Customer.NewCustomerRow();
           row.FirstName = firstName;
           row.Surname = surname;
           dst.Customer.AddCustomerRow(row);
       
           try
           {
                   sqlcon.Open();
                   sqladp.Update(dst);
           }
           catch
           {
                   MessageBox.Show(
                         "Unable to open connection.",
                         "Error", MessageBoxButtons.OK, MessageBoxIcon.Error);
           }
           finally
           {
                   sqlcon.Close();
           }
   }

        Figure: Inserting rows using DataAdapter with a stored procedure for INSERT, then use DataAdapter.Update (strongly-typed-dataset) - best for SQL Server

   This is the best approach for Microsoft SQL Server. The parameters for the stored procedure are automatically generated and the strongly typed dataset updates when the database schema changes.

5. Use DataAdapter with SQL SELECT statement, then use command builder to automatically create INSERT, UPDATE and DELETE statements as required. Then use DataAdapter.Update (strongly-typed-dataset).

   public void DACmdb(string firstName, string surname)
   {
           SqlConnection sqlcon = new SqlConnection();
           sqlcon.ConnectionString = "Persist Security Info=False;
                     Integrated Security=SSPI; database=northwind;
                     server=mySQLServer;Connect Timeout=30";
           SqlCommand sqlcmd = new SqlCommand();
           sqlcmd.CommandText = "SELECT firstName, surname FROM Customers";
           sqlcmd.Connection = sqlcon;
           SqlDataAdapter sqladp = new SqlDataAdapter();
           sqladp.SelectCommand = sqlcmd;
           SqlCommandBuilder cmdb = new SqlCommandBuilder(adp);
       
           NorthWindCustomer dst = new NorthWindCustomer();
           NorthWindCustomer.CustomerRow row = dst.Customer.NewCustomerRow();
           row.FirstName = firstName;
           row.Surname = surname;
           dst.Customer.AddCustomerRow(row);
       
           try
           {
                   sqlcon.Open();
                   sqladp.Update(dst);
           }
           catch
           {
                   MessageBox.Show(
                          "Unable to open connection.",
                          "Error", MessageBoxButtons.OK, MessageBoxIcon.Error);
           }
           finally
           {
                   sqlcon.Close();
           }
   }

        Figure: Inserting rows using DataAdapter with SQL SELECT statement, then use command builder to automatically create INSERT, UPDATE and DELETE - best for SQL Server

        This approach is the best approach for Jet (Access) databases, as stored procedures in Access are difficult to implement and unreliable. The INSERT statement is automatically generated by .NET and the strongly typed databases update when the database schema is changed.

Bad example - Images under Product root folder.

Good example - Images under \Images folder.

Bad example - HTML file in \Images Folder.

Good example - Images only, clean \Images folder.

Good example - All the wise setup file in the \setup folder.

1. The SQL Server Database or the Server machine cannot be accessed by the user, and so developer settings are completely useless to the user.
2. The user doesn't install the application in the default location. (i.e. instead of C:\Program Files\ApplicationName, the user could install it on D:\Temp\ApplicationName)
3. The developer has assumed that certain application dependencies are installed on the user's machine. (i.e. MDAC; IIS; a particular version of MS Access; or SQL Server runtime components like sqldmo.dll)

To prevent issues from arising and having to re-deploy continuously which would only result in embarrassing yourself and the company, there are certain procedures to follow to make sure you give the user a smooth experience when installing your application.

1. Have scripts that can get the pathname of the .exe that the user has installed the application on
   
   Wise has a Dialog that prompts the user for the installation directory:

   

        Figure: Wise Prompts the user for the installation directory and sets the path to a property in wise called "INSTALLDIR"

        An embedded script must be used if the pathname is necessary in the application (i.e. like .reg files that set registry keys in registry)

      'The .reg file includes the following hardcoded lines:
   
   
    '[HKEY_CLASSES_ROOT\SSWNetToolkit\shell\open\command]
   
   
     '@="\"C:\\Program Files\\SSW NetToolKit\\WindowsUI\\bin\\SSW.NetToolkit.exe\" /select \"%1\""
   
   
    'This should be replaced with the following lines:
   
   
    '[HKEY_CLASSES_ROOT\SSWNetToolkit\shell\open\command]
   
   
    '@="\"REPLACE_ME\" /select \"%1\""
   
   
                                           
     Dim oFSO, oFile, sFile
   
   
     Set oFSO = createobject("Scripting.FileSystemObject")
   
   
                                           
     sFile = Property("INSTALLDIR") & "WindowsUI\PartA\UrlAcccess.reg"
   
                                           
     Set oFile = oFSO.OpenTextFile(sFile)
   
   
     regStream = oFile.ReadAll()
   
   
     oFile.Close
   
   
    string appPath = replace(Property("INSTALLDIR") & "WindowsUI\bin\SSW.NetToolkit.exe", "\", "\\")
   
   
    regStream = replace(regStream, "REPLACE_ME", appPath)
   
   
    Set oFile = oFSO.OpenTextFile(sFile,2)
   
   
    oFile.Write regStream
   
   
    oFile.Close
   

        Figure: The "REPLACE_ME" string is replaced with the value of the INSTALLDIR property in the .reg file

2. After setting up the wise file then running the build script, the application must be first tested on the developers own machine.
   Many developers forget to test the application outside the development environment completely, and don't bother to install the application using the installation package they have just created.
   Doing this will allow them to fix e.g. pathnames of images that might have been set to a relative path of the running process and not the relative path of the actual executable.

     this.pictureReportSample.Image = Image.FromFile(@"Reports\Images\Blank.jpg");
                                               

        Bad code - FromFile() method (as well as Process.Start()) give the relative path of the running process. This could mean the path relative to the shortcut or the path relative to the .exe itself, and so an exception will be thrown if the image cannot be found when running from the shortcut.

      string appFilePath = System.Reflection.Assembly.GetExecutingAssembly().Location;
   
   
   string appPath = Path.GetDirectoryName(appFilePath);
   
   
   this.pictureReportSample.Image = Image.FromFile(appPath + @"\Reports\Images\Blank.jpg");
                                               

        Good code - GetExecutingAssembly().Location will get the pathname of the actual excecutable and no exception will be thrown.

   This exception would never have been found if the developer didn't bother to test the actual installation package on his own machine.
    

3. Having tested on the developer's machine, the application must be tested on a virtual machine in a pure environment without dependencies installed in GAC, registry or anywhere else in the virtual machine.
   
   Users may have MS Access 2000 installed and, the developer's application may behave differently on an older version of MS Access even though it works perfectly on MS Access 2003. The most appropriate way of handling this is to use programs like VM Ware or MS Virtual PC.
   This will help the developer test the application on all possible environments to ensure that it caters for all users, minimizing the amount of assumptions as possible.

#if DEBUG MessageBox.Show("Application started"); #endif

                          //Bad Code


                          DateTime dt = new DateTime.Now();


                          DataSet ds = new DataSet();


                          // It could be confused with Date time.


                          DataTable dt = ds.Tables[0];

Bad code - Without meaningful name.

                     //Good Code


                     DateTime currentDateTime = new DateTime.Now();


                     DataSet employmentDataSet = new DataSet();


                     DataTable ContactDetailsDataTable = ds.Tables[0];

Good code - With meaningful name.

More information on naming convention.

1. Save and close the file in Visual Studio .NET, and check in the file if it is checked-out.
2. Open Visual SourceSafe Explorer and rename the file.
3. Rename it in Visual Studio .NET, click "Continue with change" to the 2 pop-up messages:
   

   

   Figure: Warning message of renaming files under source control.

   

   Figure: You are seeing this as the new file name already exists in SourceSafe, just click "Continue with change".

We recommend that you should always use a code profiling tool to measure performance gains whilst optimising your application. Otherwise, you are just flying blind and making subjective, unmeasured decisions. Instead, use a tool such as JetBrains dotTrace profiler. These will guide you as to how to best optimise any code that is lagging behind the pack. You can run this on both ASP.NET and Windows Forms Applications. The optimisation process is as follows:

1. Profile the application with Jetbrains dotTrace using the "Hot Spot" tab to identify the slowest areas of your application

   

   Figure: Identify which parts of your code take the longest (Hot Spots)

2. Some parts of the application will be out of your control e.g. .NET System Classes. Identify the slowest parts of code that you can actually modify from the Hot Spot listing
3. Determine the cause of the poor performance and optimise (e.g. improve the WHERE clause or the number of columns returned, reduce the number of loops or use a StringBuilder instead of string concatenation)
4. Re-run the profile to confirm that performance has improved
5. Repeat from Step 1 until the application is optimised

To add a SSW Code Auditor file to your solution:

1. Start up SSW Code Auditor
2. Add a new Job
3. Add a the solution file to be scanned
4. Select the rules to be run
5. Configure email (not required)
6. Select File > Save As (into the solution's folder as "codeauditor.SSWCodeAuditor")
7. Open your Solution in Visual Studio
8. Right click and add existing file
9. Select the SSW Code Auditor project file
10.  Right click the newly added file and select "Open With"
    

    

11.  Point it to the SSW Code Auditor executable

1. Stat up Microsoft FxCop
2. Create a New Project
3. Right click the project and Add Target
4. Select the Assembly (DLL/EXE) for the project
5. Select File > Save Project As (into the solution's folder as "fxcop.FxCop")
6. Open your Solution in Visual Studio
7. Right click and add existing file
8. Select the Microsoft FxCop project file
9. Right click the newly added file and select "Open With"
10. Point it to the Microsoft FxCop executable

1. Stat up NUnit
2. Create a New Project by selecting File > New Project and save it to your solution directory as "nunit.NUnit"
3. From the Project menu select Add Assembly
4. Select the Assembly (DLL/EXE) for the project that contains unit tests
5. Select File > Save Project
6. Open your Solution in Visual Studio
7. Right click and add existing file
8. Select the NUnit project file
9. Right click the newly added file and select "Open With"
10. Point it to the NUnit executable

Now you can simply double click these project files to run the corresponding applications.

     StringBuilder sb = new StringBuilder();
     sb.AppendLine(@"<script type=""text/javascript"">");
     sb.AppendLine(@"function deleteOwnerRow(rowId)");
     sb.AppendLine(@"{");
     sb.AppendLine(string.Format(@"{0}.Delete({0}.
        GetRowFromClientId(rowId));", OwnersGrid.ClientID));
     sb.AppendLine(@"}");
     sb.AppendLine(@"</script>"); 

Bad example - Hard to read ?the string is surrounded by rubbish + inefficient because you have an object and 6 strings

     string.Format(@"<script type=""text/javascript"">                  
       function deleteOwnerRow(rowId)                    
      { {0}.Delete({0}.GetRowFromClientId(rowId)); } </script> ", 
       OwnersGrid.ClientID);                                    

Good example Slightly easier to read ?but it is 1 code statement across 10 lines

     string scriptTemplate = Resources.Scripts.DeleteJavascript;
     string script = string.Format(scriptTemplate, OwnersGrid.ClientID); 

     <script type=""text/javascript"">
     function deleteOwnerRow(rowId)
     {
            {0}.Delete({0}.GetRowFromClientId(rowId));
     }
     </script> 

Figure: The code in the first box, the string in the resource file in the 2nd box. This is the easiest to read + you can localize it eg. If you need to localize an Alert in the javascript

Figure: Add a recourse file into your project in VS2005

Figure: Read value from the new added resource file

DataSet returnedResult = webserviceObj.GetByDateCreatedAndEmpID(DateTime.
Now,'JZ');                            

[WebMethod] public DataSet GetByDateCreatedAndEmpID(DateTime DateCreated, String                                
EmpID)                                
{
     EmpTimeDayDataSet ds = new EmpTimeDayDataSet();                                
     m_EmpTimeDayAdapter.FillByDateCreatedAndEmpID(ds, DateCreated.Date, EmpID);                                
     return ds;
}                            

Figure: web service method (web service server time zone: GTM+10)

When front end calls this web method with the value of current local time (14/01/2006 11:00:00 PM GTM+8) for parameter 'DateCreated', it expects a returned result for date 14/01/2006, while the service end returns data of 15/01/2006, because 14/01/2006 11:00:00 PM (GTM+8) would be adjusted to be 15/01/2006 01:00:00 AM at the web service server (GTM+10)

In v1.1/v1.0 you have no way to control this serializing/deserializing behaviour on DateTime. In v2.0 with the new notion DateTimeKind you can get a workaround for above example,

Datetime unspecifiedTime = DateTime.SpecifyKind(DateTime.Now,DateTimeKind.
Unspecified);                                
DataSet returnedResult = webservceObj.serviceObj.GetByDateCreatedAndEmpID,
(unspecifiedTime,'JZ');                            

Figure: front end code in .NET v2.0 (front end time zone: GTM+8)

In this way, the server end will always get a datetime value of 14/01/2006 11:00:00 without GTM offset and return what front end expects

<configuration>
     <appSettings>
          <add key="ConnectionString" value ="integrated security=true;
           data source=(local);initial catalog=Northwind"/>
     </appSettings>
</configuration>

and access this connection string in code like this:

SqlConnection sqlConn = 
new SqlConnection(System.Configuration.ConfigurationSettings.
AppSettings["ConnectionString"]);                        

Bad example - old ASP.NET 1.1 way, untyped and prone to error.

In .NET 2.0 you can access it in another way

Step 1: Setup your settings in your common project. E.g. Northwind.Common

Figure: Settings in Project Properties

Step 2: Open up the generated App.config under your common project. E.g. Northwind.Common/App.config

Figure: Auto generated app.config

Step 3: Copy the content into your entry applications app.config. E.g. Northwind.WindowsUI/App.config The new setting has been updated to app.config automatically in .NET 2.0

 <configuration>
      <connectionStrings>
         <add name="Common.Properties.Settings.NorthwindConnectionString"
              connectionString="Data Source=(local);Initial Catalog=Northwind;
              Integrated Security=True"
              providerName="System.Data.SqlClient" />
        </connectionStrings>
 </configuration>                        

Then you can access the connection string like this in C#

SqlConnection sqlConn =
 new SqlConnection(Common.Properties.Settings.Default.NorthwindConnectionString);                                

Good example - access our connection string by strongly typed generated settings class.

<connectionStrings>
   <add name="ConnectionString" connectionString="Server=(local);
Database=NorthWind;" />
</connectionStrings>
<appSettings>
   <add key="ConnectionString" value="Server=(local);Database=NorthWind;"/>
</appSettings>

Bad example - use duplicate connection string in web.config.

We recommend you use the Windows NT authentication by default, because Windows security services operate by default with the Microsoft Active Directory?directory service, it is a derivative best practice to authenticate users against Active Directory. Although you could use other types of identity stores in certain scenarios, for example Active Directory Application Mode (ADAM) or Microsoft SQL Server? these are not recommended in general because they offer less flexibility in how you can perform user authentication.

If not, then add a comment confirming the reason.

<connectionStrings>
   <add name="ConnectionString" connectionString="Server=(local);
    Database=NorthWind;Integrated Security=SSPI;" />
</connectionStrings>

Bad example - not use Windows Integrated Authentication connection string without comment.

<connectionStrings>
    <add name="ConnectionString" connectionString="Server=(local);
     Database=NorthWind;Integrated Security=SSPI;" />
</connectionStrings>

Good example - use Windows Integrated Authentication connection string by default.

                <connectionStrings>
                    <add name="ConnectionString" 
                     connectionString="Server=(local);
                     Database=NorthWind;uid=sa;pwd=sa;" />
                    <!--It can't use the Windows Integrated because they are 
                     using Novell -->                
</connectionStrings>

Good example - not use Windows Integrated Authentication connection string with comment.

Default string appearance

Highlighted string appearance

Tools | Options form of Visual Studio

Bad example - Using Windows Command Processor (cmd.exe) for running batch files.

Good example - Using PowerShell for running batch files

We recommend that you add this document as a solution item and the name be '_Instructions.doc' or '_Instructions.docx'. You can also break up this document into '_Instructions_Compile.docx' and '_Instructions_Deploy.docx'

Here's a summary of what this document would contain. They are not compulsory but may necessary for running the project.

1. Project structure

   All parts that composes the project and how they work with each other.

2. Third party stuffs

   Any software, tools and DLL files that this project uses. (e.g., NHibernate, ComponentArt)

3. Database configuration
4. Other configurations
5. FTP information and Deployment procedure
6. Other things to take care of

Bad example - A project without an instructions.

Good example - A project with an instructions.

SqlCommand sqlcmd = new SqlCommand(); sqlcmd.CommandText = "
                    proc_InsertCustomer" sqlcmd.CommandType
                    = CommandType.StoredProcedure; sqlcmd.Connection = sqlcon;

Bad Example

SqlCommand sqlcmd = new SqlCommand(); sqlcmd.CommandText = "
                     dbo.proc_InsertCustomer"; sqlcmd.CommandType
                     = CommandType.StoredProcedure; sqlcmd.Connection = sqlcon;

Good Example

By inserting an @ character in front of the string, e.g. @"C:\Temp\MyFile.txt", you can turn off escape sequences, making it behave like VB.NET. File paths should always be stored like this in strings.

private static string LoadContentFromWeb(string strUri)

{
...

WebResponse response = request.GetResponse();

...
}

Figure: Invoke web method by the normal way (Bad - because this will hang your UI thread)

The correct way to invoke web method is using asynchronous call to send a request and use the delegated CallBack method to read the response, see code below:

 public static void GetOnlineVersionAsync(string strUri)
{
    try
    {
     ...

        IAsyncResult r = request.BeginGetResponse(new AsyncCallback(ResCallBack), request);
     }
     catch(WebException ex)
    {
        Console.WriteLine(ex.ToString()) ;
     }
}



private static void ResCallBack(IAsyncResult ar)
{
   try
   {
      string content = string.Empty;
      WebRequest req = (WebRequest)ar.AsyncState;
      WebResponse response = req.EndGetResponse(ar);

      ...

      RaiseOnProductUpdateResult(content);

   }
   catch(WebException ex)
   {
      Console.WriteLine(ex.ToString());
      RaiseOnProductUpdateResult(string.Empty);
    }
}

Figure: Invoke web method by using asynchronous method and CallBack (Good - UI thread will be free once the request has been sent)

When working with Web Service, asynchronous methods will be automatically generated by your web services proxy.

Figure: Automatically generated asynchronous methods

See Scott's blog Preventing Dialogs on the Server-Side in ASP.NET or Trace.Fail considered Harmful

 public static void ExceptionFunc(string strException)
{
    System.Diagnostics.Trace.Fail(strException);
}

Figure: Never use Trace.Fail

<configuration>
   <system.diagnostics>
      <assert AssertUIEnabled="true" logfilename="c:\log.txt" />
   </system.diagnostics>
</configuration>

Figure: Never set AssertUIEnabled="true" in web.config

<configuration>
   <system.diagnostics>
      <assert AssertUIEnabled="false" logfilename="c:\log.txt" />
   </system.diagnostics>
</configuration>

Figure: Should set AssertUIEnabled="false" in web.config

Code generators can be used to generate whole Windows and Web interfaces, as well as data access layers and frameworks for business layers, making them an excellent time saver. However making the code generators generate your projects for the first time takes much time and involves lots of configurations.

In order to make it easier to do the generation next time, we recommend you putting the command line of operations into a file called "_Regenerate.bat". When you want to generate it next time, just run the bat file and all things are done in a blink.

cs D:\DataDavidBian\Personal\New12345\NetTiers.csp

Figure: An example of command line of Code Smith for NorthWind

Thus "_Regenerate.bat" file must exist in your projects (of course so must other necessary resources).

Figure: Good - Have _Regenerate.bat in the solution