Monday, January 14, 2008

People Search Box Error

I was trying to work out why an error was being thrown from a SharePoint 2007 web part today, that extends peoplesearchboxex.cs. The error was the wonderfully helpful "Object reference not set to an instance of an object" exception, being thrown from the base method, PeopleSearchBoxEx.CreateChildControls().

After a lot of messing around, it turns out the error was thrown because of some invalid data in the "Properties" web part property. I removed the data in there and it worked correctly.

This is some pretty disappointing error reporting, considering how likely it is that configuration data could be incorrect.

Labels: , , , , , , ,

Wednesday, August 08, 2007

SQLMetal Linq Schema Error

When trying to use Linq to SQL using SQLMetal to generate the classes and xml mapping file, I was getting errors at runtime relating to the schema of the mapping file.

I am running the Orcas Beta 2, but I had also installed a pevious Linq preview. Removing that previous version fixed the problem.

Labels: , , , , ,

Sunday, August 05, 2007

SQLMetal Error

I am currently playing around with Linq to SQL, and I am using sqlmetal.exe to generate an external xml mapping file for my database.

After installing Visual Studio 2008 beta 2, running my sqlmetal command (which in the previous version had been running without a problem) returned the following message:

error The user instance login flag is not supported on this version of SQL Server. The connection will be closed.

After playing around a bit, I discovered that changing the /database value from "localhost" to the actual name of my PC fixed the problem.

Labels: , , , , , , , , ,

Monday, February 05, 2007

TFS: Unable to connect to the remote server

When trying to add a project to Team Foundation Server Source Control, the following dialogue box appears:

Reason:
Can be caused when workspace is not mapped correctly.

Resolution:
  1. Select TFS server in Team Explorer.
  2. Go to File > Source Control > Workspaces.
  3. Highlight your computer name and click 'Edit'.
  4. Select the root of the server, and select the local root you want to use (ie. visual studio 2005/projects).
If you get an error stating that the workspace location is already mapped, it may be because you have been using a different TFS server in the past. If so, remove the old workspace first, using the utility described here: http://msdn2.microsoft.com/en-us/library/54dkh0y3(VS.80).aspx

If the server no longer exists, you will not be able to remove the workspace with the tf workspace utility. In this case, you need to open the versionControl.config file found here:

C:\Documents and Settings\[user]\Local Settings\Application Data\Microsoft\Team Foundation\1.0\Cache\versionControl.config

Once you have opened the file in a text editor, remove the references to your old server by removing the node entirely, or change the workspace path.

Once you have done this, complete the steps above to set up your workspace.

Monday, January 15, 2007

Strategy Pattern vs Visitor Pattern

I have been trying to memorise Gang of Four design patterns recently, and came across the Strategy and Visitor patterns.

I struggled for a while to understand the difference between these two patterns, and the circumstances that would require one over the other.

I believe I understand correctly now, and thought it prudent to write it down somewhere. Here is as good a place as any for me to refer back to later, and it provides the added bonus of allowing people to correct me.

This post may not give you a good introduction into the Visitor and Strategy patterns, but will hopefully clarify when you should use one over the other (something I had difficulty finding a nice example of on the web).

Firstly allow me to provide an overview in my own words for each of the patterns:

Visitor Pattern
Consists of "Visitees" or "Hosts" and "Visitors". Hosts are objects within an object tree, and Visitors contain operations to be performed on these Hosts.

Hosts expose an Accept() method, which takes a Visitor object, and Visitors expose a Visit() method which has an overload for each Host. When the Accept() method is called on the Host, and a Visitor passed, a Visit() method is called on the visitor.

Using this pattern, operations become Double Dispatch, meaning they are executed based on two classes; the Host and the Visitor.

Strategy Pattern
Consists of a "Context" and a "Strategy". Contexts are objects within a tree related classes, and a Strategy is a class containing a series of operations to be used by the Contexts.

Strategy provides an interface of which Context objects are aware. When a Context object is created, a Strategy is also created (if not static) and given to the Context. Operations can then be selected from the selected Strategy as desired.

The Difference
While both patterns improve separation of concerns, and are fairly similar at face value, there are some important differences:

The Strategy pattern is designed to have the Strategy operation decided at runtime. Concrete Strategy objects can be passed to each Context operation. According to the Gang of Four Design Patterns book, Visitor patterns have a Composite Association between the Host and the Visitor and therefore the Visitor containing the operations has the same life cycle as the Host.

The Visitor in the Visitor Pattern must be aware of all Hosts and provide operations for each. The Visitor controls the operations run by the Host. This means that if your object model changes regularly, it will involve additional maintenance if a Visitor Pattern is used.

The Strategy in the Strategy Pattern will provide only the required algorithms, and the decision over which operation is executed is handled by the Context. Therefore the Context in the Strategy Pattern must be aware of the operations on the Strategy. If a Context is added, there is less maintenance (providing a new algorithm is not required).

Use the Visitor Pattern When:
  • An object structure will not change often, but operations across them will.
  • You have specific related functionality for each concrete class, and wish to encapsulate it.
  • Operation requires data that the Object shouldn't know about.
  • You wish to maintain state within operations across multiple objects.
Example:
  • An application may change its "Skin" which will alter the way controls are drawn. The code for deciding how controls are drawn could be encapsulated in Visitor implementations. Each control will require a separate operation.

Use the Strategy Pattern When:
  • A few algorithms will be used by many different classes.
  • Different algorithms may be used by a class at different times.
  • Operation requires data that the Object shouldn't know about.
  • Classes are using multiple conditional statements. These can be moved to an implementation of the Strategy class.
  • An object structure is likely to change often.
Example:
  • Different methods of calculating interest and fees will be used by clients of a bank. These algorithms can be encapsulated in Strategy implementations and associated with individual clients at runtime.

I am interested in getting feedback on these conclusions. Please let me know if you think anything I have written in incorrect, or you can think of better examples or ways to clarify things.

Tuesday, August 15, 2006

Proxy Frustration

Recently I was getting a proxy authentication error when trying to test a web service. I had created an asp.net 2.0 website that contained a simple form that when submitted, requested information from my web service which was hosted in another domain.

I was running the web site locally in debug mode and could access it without any issues. When I submitted the form (causing the asp.net code to make a request to the web service) I received the following error:

The request failed with HTTP status 407: Proxy Authentication Required

I wasn't specifying any proxy information, so I enlisted an infrastructure guy to help. "You should turn off your proxy information in "Internet Explorer" he told me. "That has nothing to do with it" I replied and proceeded to draw a diagram, explaining that it was the web server that had the problem when trying to access the web service, not me as the client.

He understood what I was trying to tell him, and agreed. "Just turn it off so I can rule it out" he said, and I complied.

Sure enough, removing the proxy settings in my browser fixed the problem. "I'm getting a coffee" my infrastructure friend stated smugly, and walked off.

Obviously my only conclusion is that the web server started by Visual Studio 2005 uses the system proxy settings by default. A quick web search confirmed it:


http://msdn.microsoft.com/vstudio/support/knownIssues/default.aspx

2.22 In .NET Framework 2.0, GlobalProxySelection.Select behaves differently than in version 1.1 when an empty System.Net tag is present in the machine.config file

In version 1.1 of the .NET Framework, specifying an empty System.Net element in the machine.config file, GlobalProxySelection.Select returns an empty web proxy instance indicating that no proxy is to be used. In version 2.0, the new default is that the system proxy settings (same as what is specified in Internet Explorer) will be used in this case.

To resolve this issue

Modify the machine.config file to disable the default proxy as shown below.

<system.net>
<defaultProxy enabled="false" />
</system.net>

Unfortunately this solution didn't work for me and I had to add a proxy exclusion rule to IE. If I find a better solution, I'll post it here.

Sunday, January 29, 2006

Debugging Visual Studio 2005 AddIns

Recently I have been working on a Visual Studio AddIn and came across a problem.

When I first created the AddIn project, a file was created in my AddIns directory (My Documents\Visual Studio 2005\Addins) called "[addin name] - For Testing.AddIn". This is used when debugging.

I created a release version of the program and deleted this file so that I could deploy the release version. Later I made a change and wanted to debug the program only to find it no longer appeared in the visual studio tools menu. The "for testing.addin" file had not been recreated by visual studio as I had assumed it would.

Fortunately the problem was easy to resolve:
  1. Copy the "[project name].AddIn" file from your project root to the AddIns directory (My Documents\Visual Studio 2005\Addins)
  2. Rename the file to "[project name] - For Testing.AddIn".
  3. Open the file in a text editor and alter the path where it references your dll (<assembly>) to point to your debug dll.

You should now be able to debug your project and have the addin display in your tools menu.