Marcus Hammarberg

This case may sound strange and I have seen loads of post that describes how to get out of this behavior. But we have a case where we want to allow anonymous access and the let a external component manage the security validation.

This turned out to be very hard to figure out and required some wizard-like skills of Anders Granåker amongst others.

OK – the case is very simple. I have a WCF Service that I want to allow anonymous access to. I don’t care about message and transport security (for now). Just allow anonymous access – I’ll take care of the authorization in code.

The last step is a bit interesting… In this time and age you could think that a simple recycling of the application pool would be enough but … no. Do an IISReset to be sure.

Another gotcha that confused us a lot was that when you set an account to be the anonymous account for the virtual directory, you’re prompted to set the password. And retype it to be sure. But that password is not check if it’s the right password! Beware – I locked out our administrator account due to this.

Again – the script I am starting off is written by Todd of the Tar Pit. I’ve just tweaked it to take project property as input. That was the recommended way to change the endpoint for one service, to set the endpoint to a projectwide parameter.

And here is a DOS-command that runs the MSBuild-target TestAll with the project property set to a endpoint.

Please note that I was running this on a 64-bit Windows 7 and got some strange paths (Framework64) that you want to change..

I have been singing SOAPUi’s praises lately and it’s really great for testing services. In this post I describe how I made the whole thing work for testing WCF Services.

But, as stated in this post, there was still one more thing to be solved… The endpoints from the command line. You want to use different endpoints in different environments. And in my specific customer case I want one of them to stay the same all of the time, since that endpoint points (sorry, could not resist myself) to a “singleton” kind of service.

Luckily the SOAPUi team also have some great support (Thanks Ole, who replied in Swedish!). So here you have it – how to change the endpoint for one of your services under test from the command line – which in my case means the build script.

So now I can change the endpoint from the command line! In my build script when I have deployed the service to the testing environment for example! Yeah!

I've been generating documentation from our XML-comments with Sandcastle for quite some time now. It has worked alright but there were some stuff that really annoyed me, I though that I had to put up with it.

But this is the beauty of my line of work comes into play... all of a sudden we've got a new team member. Christer Cederborg from Avega (of course) - a great guy and very knowledgeable in things like build scripts and other. And you get to learn from each other. This is why I am in this business - sharing and knowing.

OK - Christer told me that you can use something called a response file to send commands to Sandcastle. The response file is in fact just the parameters you would send to Sandcastle the command line, but in a file. This made us go around the use of .shfb-files.

Sandcastle Help File Builder is certainly a great tool when you generate the documentation manually but is sucks when it comes to incorporating it into a build script. You cannot use wildcards or relative paths in .shfb-files which complicate things in a major way. I actually created two separate file, one for local developer use and one for our build script. They were of course almost always out of sync...

But with the use of a response file you can set all the commands you need to Sandcastle and get the same result. Here is a short extract from our response file:

-assembly=LF.GBP.*.dll, LF.GBP.*.xml
-dependency=Microsoft.Practices*
-dependency=Lf.Gemi*

-VisibleItems="InheritedMembers, InheritedFrameworkMembers, Protected, SealedProtected"

-ShowMissingParams=true
-ShowMissingRemarks=false
-ShowMissingReturns=true

And here is how to call Sandcastle in MsBuild with the use of the response file:

<PropertyGroup>

      <SandCastleExePath>C:\Program Files\EWSoftware\Sandcastle Help File Builder\SandcastleBuilderConsole.exe</SandCastleExePath>

        <SandCastleOuputLocation>$(DropLocation)\SystemDokumentation\Tjanster</SandCastleOuputLocation>
        <SandCastleWorkingDir>$(CurrentSolutionRoot)\SandCastleWorkingDir</SandCastleWorkingDir>
        <SandCastleResponseFile>$(CurrentSolutionRoot)\Solution Items\Documentation\LF.GBP.SandCastleSettings.txt</SandCastleResponseFile>

</PropertyGroup>

<Target Name="GenerateDocumentation" Condition="'$(Documentation)' == 'true'">
    
    <RemoveDir Directories="$(SandCastleOuputLocation)" />
    <MakeDir Directories="$(SandCastleOuputLocation)" />
    <RemoveDir Directories="$(SandCastleWorkingDir)" />
    <MakeDir Directories="$(SandCastleWorkingDir)" />

    
    <Exec WorkingDirectory="$(OutDir)"
Command=""$(SandCastleExePath)" @"$(SandCastleResponseFile)" -workingpath="$(SandCastleWorkingDir)" -outputPath="$(SandCastleOuputLocation)"" />

    
    <RemoveDir Directories="$(SandCastleWorkingDir)" />
</Target>

For some time now people has been turning to me at my customer for answerers regarding TFS Build. I have learned a great deal from that but sometimes I feel like I haven't made sure that I understood the underlying thought from Microsoft.

One of those areas is that the TFSBuild.proj-file is not your ordinary MSBuild-file. Or rather; it's is but is run by Team Foundation Server and you get to configure it and it's properties. This is what I though and I was actually right. Phew!

There are some properties and targets that you can override in order to customize the build process. You can think of these targets like events being fired, and you can hook into them and customize their actions. And this is quite easy once you know how.

But then I often get the question; "Ok - what can I configure". I haven't had a good answer (this was my best so far) but now I found a list of the customable targets and properties.

Customizable Team Foundation Build Targets (and their run order)
Customizable Team Foundation Build Properties

Also I found out that any properties you define in the build script can be sent-in as a parameter. Either from the command-line (or textbox for command line arguments in the Visual Studio GUI) or via the .rsp-file.
If the already has a value that value will be overridden with the sent-in value. The value you set in the .proj-file can be though of like a default-value.

So - some good finding for a lazy Tuesday mooring in the couch. Abbe is sound asleep and I am doing MSBuild. Life is good.

Here is a cool site with MSBuild Recipes. I might post to it from now on. Sharing is knowing.

I found a very niffty little feature of MSBuild, that is really helpful when it comes to structuring your build file.

In MSBuild the "sub-routines" are called targets and works just like expected, that is you can call the targets and invoke them in the order you like. BUT, there are no way of sending parameters to them - which at first are very hard to understand.

From this article I learned how to do it. And it's not to hard. But it's a bit of a hack... in my opinion.

Actually it's easier to describe it as it's intended from the outset, to call targets in other files. Imagine that you create a MSBuild-file called DeployScript.proj with a target called DeployIt. In order to deploy to different environments we use some variables that instructs MSBuild to deploy to different paths for example. Like the $(PublishWebSitePath) in the example below:

<RemoveDir Condition="Exists('$(PublishWebSitePath)')" Directories="$(PublishWebSitePath)" />
<MakeDir Directories="$(PublishWebSitePath)" />

We can now call the targets of the DeployScript.proj-file from another file, with parameters, in the following manner:

<MSBuild Projects="DeployScript.proj" Targets="DeployIt" Properties="PublishWebSitePath=\\[server]\[share]" />

And now it's quite easy to understand how to call targets in your own MSBuild-file with parameters. It's works the same way as above. You just give the current build-file name in the projects-value.

Using this technique you'll get a much better way of structuring your build-files. And maybe even get some reusable stuff for your next project...

MSBuild

Marcus Hammarberg

Arkiv

Kategorier

Avega Group bloggare