Friday, 31 December 2010

WCF service reference not creating correct proxy classes

Problem

I had a test project using NUnit to run unit tests for some components of a WCF service. In addition, I decided to include some integration tests that actually called a WCF service running in IIS on the localhost. To run the integration tests I created a service reference (which should generate the proxy classes) some types I had expected to find didn’t appear as proxies. The types that didn’t appear were declared as known types against the WCF service definition and all data contract attributes were correct. 

When I tried to use a type I had expected to find as a proxy class ReSharper was trying to help me out by referring me to the actual classes in the service projects, not from generated proxies. Even stranger, when I looked at the Reference.cs file (which should contain the proxy classes) the proxy classes were indeed missing but I could find declarations for the actual classes from the service projects.

Image1 
To find References.cs – in the Solution Explorer, View All Files and expand the service reference.

Solution

The fact that ReSharper was helping by pointing at the service projects was the clue. Because this was a test project I had included unit tests that created instances of classes from the service projects and as such had included references to those projects. When I added the service reference it looks like the actual service classes were used in preference to creating proxies.

I removed the references to the service projects, commented out code that needed those references and then re-added the service reference. The proxies were generated correctly.

The moral of the story is, don’t add references to the actual service projects as well as service references to the same code. It’s a good idea to run integration tests in a separate project so the references and service references don’t trip over each other.

Friday, 31 December 2010

Thursday, 30 December 2010

Shapefile basics

It looks like I’m going to have to get to grips with shapefiles and GIS data so here’s a post to give me a heads-up on shapefiles.

What is a shapefile?

A shapefile stores nontopological geometry and attribute information for the spatial features in a data set. The geometry for a feature is stored as a shape comprising a set of vector coordinates.

Because shapefiles do not have the processing overhead of a topological data structure, they have advantages over other data sources such as faster drawing speed and edit ability. Shapefiles handle single features that overlap or that are noncontiguous. They also typically require less disk space and are easier to read and write.

Shapefiles can support point, line, and area features. Area features are represented as closed loop, double-digitized polygons. Attributes are held in a dBASE® format file. Each attribute record has a one-to-one relationship with the associated shape record.” *

Note that a geographic element forming part of a shapefile is referred to as a feature.

“A representation of a geographic feature that has both a spatial representation referred to as a "shape" and a set of attributes.” ***

So, key points:

  • The data is nontopographical geometry it faster to search.
  • Shapefiles can support point, line, and area features.

A shapefile is capable of storing a mixture of different shape types but this is prevented by the specification: "All the non-Null shapes in a shapefile are required to be of the same shape type."

Parts of a shapefile

Firstly, a shapefile actually consists of several files, not one, and a shapefile can contain a combination of mandatory and optional files. A shapefile will contain 3 mandatory files:

  • .shp - the shape file containing the feature geometry
  • .shx - the shape index containing a positional index of the feature geometry (facilitates quick searching)
  • .dbf - the attribute file containing attributes for each shape (dBase IV format)

An ESRI shapefile consists of a main file, an index file, and a dBASE table. The main file is a direct access, variable-record-length file in which each record describes a shape with a list of its vertices. In the index file, each record contains the offset of the corresponding main file record from the beginning of the main file. The dBASE table contains feature attributes with one record per feature. The one-to-one relationship between geometry and attributes is based on record number. Attribute records in the dBASE file must be in the same order as records in the main file.” **

There are a number of optional files but I am currently interested in:

  • .prj – the projection file containing the coordinate system and projection information in plain text
  • .sbn and .sbx – both containing the spatial index of the features
  • .shp.xml - metadata in XML format

 

References

* http://www.esri.com/library/whitepapers/pdfs/shapefile.pdf, p.5
** http://www.esri.com/library/whitepapers/pdfs/shapefile.pdf, p.6
*** http://www.esri.com/library/whitepapers/pdfs/shapefile.pdf, p.31

Thursday, 30 December 2010

Viewing contents of the Global Assembly Cache (GAC)

Here’s a quick tip, if you view the GAC using Windows Explorer you get a nice sanitised view; the underlying folders are aggregated and the contents displayed. This can be useful for quickly finding and removing things from the GAC. However, it doesn’t show you where things really are.
The Windows Explorer view is provided by a shell extension and it is possible to disable it but you’ll lose drag and drop installation into the GAC.
To see where things are really living open a DOS prompt and navigating to the GAC directory:
untitled
The directory listing will reveal the following set of folders:
  • GAC – .NET 1.x assemblies
  • GAC_32 – .NET 2.x assemblies built for 32-bit
  • GAC_64 – .NET 2.x assemblies built for 64-bit (only of 64-bit machines)
  • GAC_MSIL – .NET 2.x assemblies that are architecture independent (32 or 64-bit)
  • NativeImages_Vx_Architecture – Each of these folders is used for storing native images of .NET assemblies that have been pre-compiled using NGen (i.e. no need for JIT). There can be a number of these folders for different .Net versions and compilation targets (e.g. 32 or 64-bit)
  • temp, tmp – Temporary folders
You can then navigate to individual folders and list the contents.