Dev Blog - Johan Danforth

TcpTrace by Simon Fell is a great tool to trace your HTTP and SOAP calls with, until you begin using WCF and it starts complaining about you not going directly to the service, address filter mismatch and all that. It's quite easy to fix that though, just add an endpoint behavior to your client configuration and tell it your're running via TcpTrace, like this sample:

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

<system.serviceModel>

<bindings>

<wsHttpBinding>

<binding name="WSHttpBinding_IMyService" >

<security mode="Message">

<message clientCredentialType="Windows" />

</security>

</binding>

</wsHttpBinding>

</bindings>

<behaviors>

<endpointBehaviors>

<behavior name="tcpTraceBehavior">

<clientVia viaUri="http://localhost:8080/MessageSecurityWindows/Service.svc"/>

</behavior>

</endpointBehaviors>

</behaviors>

<client>

<endpoint address="http://localhost:1035/MessageSecurityWindows/Service.svc"

behaviorConfiguration="tcpTraceBehavior"

binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_IMyService"

contract="MessageSecurityWindowsClient.MyService.IMyService"

name="WSHttpBinding_IMyService">

</endpoint>

</client>

</system.serviceModel>

</configuration>

While digging a bit deeper into Message and Method Security options for WCF services, I ran upon several good articles by Michèle Leroux Bustamante, both on TheServerSide.NET and on the That Indigo Girl blog she created for her book, "Learning WCF". I've just ordered the book and cannot wait to get my hands on it. I read several of the preview chapters she published on her blog and I really like the way she explains things. Good stuff, go get the book already!

So I can't take credit for any of the code in this blog post, I'm just putting things up here for myself for safe keeping and for others to learn. The documentation and samples around message security on MSDN is also pretty good, for example - http://msdn.microsoft.com/en-us/library/ms730301.aspx

So, this is a sample to do message security with a Windows client. It also shows how to make sure the caller belongs to a certain group or role to access it.

SERVICE CODE

So, to make sure the caller is a member of the Administrators group, you decorate the method with a PrincipalPermission attribute like this:

[ServiceContract()]

public interface IMyService

{

[OperationContract]

string MyOperation1(string myValue1);

}

public class MyService : IMyService

{

[PrincipalPermission(SecurityAction.Demand, Role = "Administrators")]

public string MyOperation1(string myValue1)

{

/// do something...

}

}

SERVICE CONFIGURATION

The service configuration needs to declare that message security should be handled by Windows.

<system.serviceModel>

<services>

<service name="MyService" >

<endpoint contract="IMyService" bindingConfiguration="wsHttpWindows" binding="wsHttpBinding"/>

</service>

</services>

<bindings>

<wsHttpBinding>

<binding name = "wsHttpWindows">

<security mode="Message">

<message clientCredentialType="Windows" />

</security>

</binding>

</wsHttpBinding>

</bindings>

</system.serviceModel>

CLIENT CODE

You don't need to do anything special for the client code part. Just make the call. The config file needs to be edited though.

CLIENT CONFIGURATION

Likewise, the client needs to declare the equivalent security means in its configuration file:

<system.serviceModel>

<bindings>

<wsHttpBinding>

<binding name="WSHttpBinding_IMyService" >

<security mode="Message">

<message clientCredentialType="Windows" />

</security>

</binding>

</wsHttpBinding>

</bindings>

<client>

<endpoint address="http://localhost:1035/MessageSecurityWindows/Service.svc"

binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_IMyService"

contract="MessageSecurityWindowsClient.MyService.IMyService"

name="WSHttpBinding_IMyService">

</endpoint>

</client>

</system.serviceModel>

It's all created for you if you "Add Service Reference", which of course requires you to first add an "mex" endpoint to the service.

We're using the SQL Server 2005 Service Broker functionality to replicate data and send messages between databases, and we got a tip from a Microsoftie to get hold of this book.

The book is written by Roger Wolter, Program Manager on the Service Broker team and it is straight forward, full of samples starting with a really, really simple service broker sample and builds up throughout the book. It covers most things you need to know about the topic, poison messages, multiple servers, certificates etc. and everything within some 220 pages.

Vertigo made a reference application for Microsoft, using WPF and Silverlight, called Family.Show. It's a nice looking and very easy to use genealogy app which has all the features you've come to expect from a WPF tool – zoom, move, animate, shadows…. You name it. Source code is available too of course.

Nice thing is it can handle GED files, which is a weird but common ASCII format for exporting and importing genealogy data.

If you haven't already, head over to Scottgu's blog and read his excellent explanation of the Extension Methods feature, part of the "Orcas" release later this year. No need to show any example here, better to look at what Scott did, but with this feature you can add new methods to the public contract of ANY existing CLR type! Even Object itself. This feature is available in some dynamic languages already, and it's mighty cool. No need to subclass or anything. It will be available for both c# and VB.NET.

Microsoft has really stepped into the dynamic languages arena with all these new features. It will be very interesting to see some of the productive stuff people will come up with soon where you combine these new features with LINQ. Ruby on Rails, watch up… I do hope the new stuff will also spice up the IronPython language.

Scott ends his blog post with something important to keep in mind:

Hopefully the above post gives you a basic understanding of how extension methods work, and some of the cool extensibility approaches you will be able to take with them.  As with any extensibility mechanism, I'd really caution about not going overboard creating new extension methods to begin with.  Just because you have a shiny new hammer doesn't mean that everything in the world has suddenly become a nail!  

Never thought I was going to blog about SQL... but I'm doing this mostly for myself because I need to use this at work on monday. I know enough to do database design and whip up a few necessary stored procs, but when it comes to functions and the new Common Table Expression (CTE) in SQL 2005 I'm quite lost. I got a tip about CTE from my buddy Jan-Erik so I sat down with Google and SQL Books online to see if it could help me out.

Most examples out there lists the employees below a manager, and their employess etc. What I needed to do was go the other way - to create a view or something which showed all the employees in a table and who their manager on a certain level is. Not just their immediate boss, but the boss on some upper level.

To test this I started out with a small, simple table called Employee with 4 columns in it (EmpId, Name, BossId, Type), where BossID is the immediate boss, or the "parent":

CREATE TABLE [dbo].[Employee](

TABLE [dbo].[Employee](

[EmpId] [int] NOT NULL,

[Name] [varchar](50) NOT NULL,

[BossId] [int] NULL,

[Type] [varchar](50) NULL,

CONSTRAINT [PK_Table_1] PRIMARY KEY CLUSTERED

Or something like that J I'm also setting a FK between BossId and EmpId:

ALTER TABLE [dbo].[Employee] WITH CHECK ADD CONSTRAINT [FK_Employee_Employee] FOREIGN KEY([BossId])

REFERENCES [dbo].[Employee] ([EmpId])

Next I filled it with some data:

1 Helen    NULL Mega boss
2 Lisa      1        Boss
3 Otto      1        Boss
4 Carin     2       Team lead
5 Carl       2       Team lead
6 Niel       4       Project manager
7 Thomas 3       Team lead
8 Johan    4       Code monkey
   
Pretty simple, but enough to test with. This organization has 4 levels, from 'Mega boss' to 'Code monkey'. To iterate "up" in the hierarchy I'm using CTE and the WITH <table(columns)> AS syntax, and I'm putting it into a scalar function which takes the EmpID and the manager Type as parameters:

CREATE FUNCTION [dbo].[GetBossByType]

(

      @empid int,

      @type varchar(20)

)

RETURNS int

AS

BEGIN

DECLARE @bossid int;

WITH reports(EmpId,name,bossid,type) AS

(

      -- set the starting point, a specific employee (from in-parameter)

      SELECT EmpiD,name,bossid,type FROM Employee WHERE empid = @empid

      UNION ALL

      -- get the empid from the person (e) who has empid which corresponds the the previous person's (r) bossid

      SELECT e.empid,e.name,e.bossid,e.type FROM employee e JOIN reports r

      ON r.bossid = e.empid WHERE r.bossid IS NOT NULL

)

-- from the above we have a hierarchical list of managers in a table called "reports",

-- get the id from the boss with the type I'm looking for

SELECT @bossid = empid FROM reports WHERE TYPE = @type;

RETURN @bossid

END

Now, to create a view that has empid, name and boss id for a specific "level" I used a SELECT statement like this:

SELECT EmpId, Name, dbo.GetBossByType(EmpId, 'boss') AS BossId

FROM dbo.Employee

WHERE (BossId IS NOT NULL)

As you can see, I'm calling my function (GetBossByType) as part of the SELECT, passing in the EmpID and the type of manager I want to list. The result of the query/view is this (EmpId, Name, BossId):

2 Lisa       2
3 Otto       3
4 Carin      2
5 Carl        2
6 Niel        2
7 Thomas  3
8 Johan     2
 

Works for me. Lisa and Otto are of the manager type 'Boss' already, that's why they have their own EmpId as BossId. The hierarchical query can be a bit difficult to grasp first, but it's powerful. Sorry about the bad syntax and not sticking to upper/lower cases everywhere :)

Writing a custom task for MSBuild is very simple, here's the bare minimum code you would need to get you going:

To test it, create a test-project like a dummy console app and add this to the end of the .proj file:

<UsingTask TaskName="IRM.Tasks.HelloTask"    AssemblyFile="C:\code\HelloTask\bin\Debug\IRM.Tasks.dll" />

<Target Name="AfterBuild">

      <HelloTask Name="Johan" />

</Target>

If you unload the project from the Solution Explorer window you can Edit it directly in VS. 

But if you want to debug the task and set breakpoints in it? It was described by Neil Enns of the MSBuild team quite some time ago. After you have created a test-project and added the custom task to the .proj file as described above, do this:

1. Open your custom task project
2. Go to Project > projectname Properties…
3. Go to the Debug tab
4. Change the start action to “Start external program” and put in the full path to MSBuild as the program. In my case the path is “C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe”
5. Change the “Command line arguments” to the full path to your test project
6. Close the property window

Now just start debugging your custom task, MSBuild should start up and start to build your test-project and will stop at any breakpoints you set in your custom task code. Neat!