Brian Mains Blog

Currently, I have a couple test projects using NUnit.  I have them setup so that I use the startup program to be the NUnit-GUI.exe file.  This means that when I click the run button, the NUnit GUI runs, which is great.  But NUnit loads the last loaded assembly, and not the current project, at least by default.

 I was reading in the documentation and I found that you can pass in a command argument (VS.NET properties, debug, command argument textbox) of the project that you want to load.  I added the name of the DLL that I wanted to test in the command argument, and it worked great.  This was the parameter that I needed, so when I was debugging, it loaded this project.

If any of you have ever gotten an error stating that:

An error has occurred while establishing a connection to the server. When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections. 

This document walks you through how to fix the problem using SQL Server Surface Area Configuration tool.  This is a great document explaining the fix:  http://support.microsoft.com/default.aspx?scid=kb;EN-US;914277

Essentially you use the tool to enable local and remote connections; real easy fix.

When quering XML elements that belong to a namespace, you have to create an XmlNamespaceManager, and pass it to every SelectNodes or SelectSingleNode statement you make.  This object is used to resolve the namespaces in the queries, so that you can get to the correct resultset.  You can't access the data without this feature.  To create one, you do:

XmlNamespaceManager nsMgr = new XmlNamespaceManager(doc.NameTable);

I passed in the NameTable of an existing XmlDocument.  From this, you can add namespaces defined in the XML:

nsMgr.Add("DSS", "http://someuri.com/schemas/");
nsMgr.Add("XRR", "http://someuri.com/schemas/");

Then you can do this query for an element defined in the DSS namespace:

XmlNode node = doc.SelectSingleNode("Entity", nsMgr);

You can find out more about this class at:  http://msdn2.microsoft.com/en-us/library/system.xml.xmlnamespacemanager.aspx

If you are interested in writing your own trace listener (say to write to a database), you can do so from inheriting the System.Diagnostics.TraceListener class, which you can find examples on the web.  However, if you want to use it in your web application, there are several steps you need to take, which you can find documented here:  http://msdn2.microsoft.com/en-us/library/b0ectfxd.aspx

Using this example, you can register custom listeners through:

<system.diagnostics>   
  <trace autoflush="true">
    <listeners>
      <add name="DatabaseTraceListener"
        type="Mains.DatabaseTraceListener, App_Code"/>
    </listeners>
  </trace>
</system.diagnostics> 

Autoflush means messages will be written automatically to the listener; if false, then a manual Flush() method call must be peformed before trace information is written.  You add your custom class using the <add> element, like many other sections in the code.  I left out the initializeData property, which may or may not be allowed with trace listeners.

Once defined, you can use tracing in two ways.  First, you can use it manually:

System.Diagnostics.Trace.Write()

Or you can use the tracing that comes with the Page class (System.Web.TraceContext), defining this in the web.config:

<system.web>
    <trace enabled="true" writeToDiagnosticsTrace="true"/>
</system.web>

writeToDiagnosticsTrace means that all tracing will run through the trace listeners you setup in the <system.diagnostics> section.  The last step is to setup the compilers to output the switch /d:Trace, as defined below:

<system.codedom>
  <compilers>
    <compiler language="c#;cs;csharp"
              extension=".cs"
              compilerOptions="/d:TRACE"
              type="Microsoft.CSharp.CSharpCodeProvider, System, Version=2.0.3500.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" warningLevel="1" />
    <compiler language="VB"
              extension=".vb"
              compilerOptions="/d:Trace=true"
              type="Microsoft.VisualBasic.VBCodeProvider, System,                                        Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
  </compilers>
</system.codedom>

For windows projects, you can set up the /d:Trace switch in the property settings for the project.  However, with web applications, you must specify the information here.  If you don't specify the compiler options, tracing information through the diagnostics trace listener is ignored completely, which I found out the hard way when debugging.

I was excited to see the <urlMappings> element.  When enabled, you can specify url's that when entered into the browser will redirect to another page.  For example, take the following section:

<urlMappings enabled="true">
    <add url="~/link.aspx" mappedUrl="~/newlink.aspx" />
    <add url="~/weather.aspx" mappedUrl="~/info.aspx?section=weather" />
</urlMappings>

While not the best examples, they illustrate the point.  When you go to link.aspx, newlink.aspx will display; however, link.aspx will show in the browser.  You can also use this to hide querystring values, so that when you go to weather.aspx page, the right querystring value is provided.

More information is available at:  http://msdn2.microsoft.com/en-us/library/ms228302.aspx

I'm creating an experimentation in XP.  The following blog available at http://dotnetslackers.com/community/blogs/extreme_programming/default.aspx  This blog will walk through a windows application at all steps, from planning to development to releasing the project, and planning for the future.

XP works in iterations, that is on a specific set of features for a specified iteration period.  Usually, this period is 1-3 weeks, as determined by the team.  But I think that for most, the amount of testing that you do is more than normal at this stage, but it makes sense.  However, I can tell I'm not completely in the XP mindset because I'm not used to that, and I don't test as much as I should, at least as not as much as Ron Jeffries does, in his "Extreme Programming Adventures in C#" book.

However, to me, I don't see the practicality of some of the tests; furthermore, I don't also understand the point about the customers doing the customer tests; most customers aren't accustomed to testing frameworks, as well as the code themselves.  After all, that is why they are the customers.  (Hopefully, I grasped the concept of this point correctly).

But, I must digress that I have a lot more to learn about testing first, before I go out writing a bunch of code that ends up not working, or is filled with bugs.

Whenever using a gridview/detailsview operation, where the detailsview is bound to the gridview selectedvalue property through a DataSource control's ControlParameter (typical master/details view setup), there are a few operations to consider aiding with the use of the interface.

For instance, when finishing editing, updating, or deleting, it is good to refresh the gridview as well, through a manual DataBind().  This will get an updated data source, which will reflect your changes.  Whether on insert/update you want to show the item in the details view is up to you; for update, this will occur because the item is still selected; you can deselect by setting the selectedindex to -1 before rebinding after the update.  Insert's are harder, because the item isn't in the current data set, and depending on the specific data source, it may or may not show when rebinding (depending on your data source filters/constraints).

Also, when an item is selected, and you page through the data source, an erroneous item is now selected, one you didn't select.  It is good to override PageIndexChanging to set the selectedindex to -1.  This could be the case for sorting to, and you even may want to update the current page to start over at 0, so the user can start at the beginning.  Sorting the data changes the order, sometimes drastically, and starting at the beginning is needed.

These are some general design ideas to implement with master/details view setups.

One of the concepts of XP is to have pair programming at least, which means that you have more than one developer to work on the project.  The reason is having another program to bounce ideas off of and to double-check each other's code really helps to keep the correctness of the code high.

I looked back through one of my pages because of a small problem, and realized I had left out a portion of the update code that cancelled the update when there were errors on the page!  Luckily, I didn't push the system too far, but this was very unfortunate, when I am close to going to production.

Anyway, I'm not in a situation to work with pair programming, but I realize the benefit of it.  We all have our strengths and weaknesses, but after so many hours, it is common to make mistakes.

For those that don't know, there is a new application development methodology growing in the software industry called Extreme Programming (XP).  It's a new way to look at designing your applications, which creates the specific design as you go, instead of designing the system all up-front.  This may be controversial, but what you have to realize is that no one can think of all of the constraints up-front; usually, it is in the middle of the project that we are aware of our flaws, and the longer these flaws go, the more costly it is to fix in the long run.

Iterative development also works well on projects where everyone has their own ideas for the project, and they may not like what was done in the past iteration.  Through this approach, they could easily rework the problem areas for the next iteration, instead of having to correct the problem in a maintenance cycle, which would be more costly.

The approach is to start out with a list of features called stories.  The user writes the features that they want, and from this, the developer can assign the risk of each, and select how long it will take to implement, in a timespan between one to three weeks.  If a task takes longer than three weeks, it is broken up; if it is less than one week, then taskes are combined.

From this, in the Requirements phase, the developers perform a series of "spikes", or tests to work out issues they aren't familiar with.  After being sure of the problem they are having, they begin to work at the Iterative phase, which is a one-to-three-week time period.  At the end of each iteration is tested, working code that the user can visually see and use.  It is from this that the users can determine when they want to implement.

The idea is to have frequent deployments from this working code.  Iterations can also add bug fixes, as well as add or break down any additional stories that may be thought of later.  As the project goes along, a velocity is determined, which is how many stories are being completed in the iterative time period.  This is used to adjust the release plan, which is always being adjusted to make it more accurate as the project moves along.

XP is controversial as it is a different way of designing applications, especially for the users who are expecting to see general and detailed system designs in advance, so they can determine the features.  But in most of the projects I've worked on, most of them always have changes, or flaws in their design that weren't caught or thought of, that need fixed.  This is only human; we can only think so far ahead, and are likely to be wrong in some of our assumptions.  Personally, I like the approach, and look forward to using it.