Technicalities

A recent project involved drawing regions on a map of a country using the Bing Maps Silverlight control . The user could zoom in to a suburb and draw a region (polygon) around an area on the map. Another feature, and hence the purpose of this blog post, involved enabling a user to draw a line through a region (polygon) and split the region in two: how was that splitting done? Note: you will probably need some database experience and ideally some Bing/Google Maps experience for this to make sense A quick intro to SQL Server Spatial queries SQL Server 2008 introduced support for geo-spatial data . The two new spatial data types are: Geometry: supports flat data surfaces. The following will create a polygon and a line and you can see that our resulting rectangle and line are straight: DECLARE @Geometry GEOMETRY = 'POLYGON((10 10, 40 10, 40 40, 10 40, 10 10))' DECLARE @Linestring GEOMETRY = 'LINESTRING(5 5, 50 50)' SELECT @Geometry SELECT @Linestr

A recent project I was working on needed a lot of data to be passed quickly between a Silverlight client and a .Net server. The approach taken, instead of using a relatively-heavy XML SOAP implementation, was to go with a lightweight JSON REST web service. Information on the web is moderately clear on how this works, but I found the POST part of the picture to be virtually non-existent. As I would be passing in more data than some browsers support through the querystring, I didn't have any other option: I had to figure it out. Thus, if you need that info, read on... GET The following is a sample web service with one GET method:     [ServiceContract]     [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]     public class MyTestService     {         [OperationContract(Name = "MyTestMethod")]         [WebGet(UriTemplate = "myTestMethod/{aParameter}", ResponseFormat = WebMessageForm

With quite a few contracts I have been working on over the years I have ended up helping out with the build process for ASP.Net websites. Many existing enterprise build processes I have encountered tend to involve making a custom build of the codebase for UAT and then once UAT is passed making another build for PROD. This process brings in a significant risk of a developer on a team checking in changes AFTER UAT was build and thus ending up with untested code in PROD. This risk is unnecessary. The following is an approach I have used at a number of enterprises for creating a single .msi installer which can be run in a DEV environment (if it exists), then copied into a UAT environment for user testing before finally being copied and run in PROD. The single installer gets built once but can handle the different server/database configurations of the different environments and can install the correct .config files in each environment. The methodology is as follows: Within Visual Studio