Atombrenner

The best fellow employee ...

2012-01-19T21:10:00.001+01:00

... is someone that you can criticize without pissing him off. The same should be true the other way round. I'm glad that I'm working for an exceptional company where nearly everyone has this attitude.

Speed up your build with UseHardlinksIfPossible

2011-11-27T12:35:00.001+01:00

MsBuild 4.0 added the new attribute "UseHardlinksIfPossible" to the Copy task. Using Hardlinks makes your build faster because less IO operations and disk space is needed (= better usage of file system cache). What's best is that this new option is already be used by the standard .net build system! But Microsoft decided to turn them off by default.

After searching a little bit in the c# target files I found out how to turn this feature globally on and my build was 20% faster than before. And if you have big builds with more than a hundred projects this counts!

So here comes the way to turn on hard linking in your build. First, this works only with NTFS. Second you have to explicitly set the ToolsVersion to 4.0. You can do this with a command line argument (msbuild /tv:4.0) or inside the project file (<Project DefaultTargets="Build" ToolsVersion="4.0" ...).

Then you have to override the following properties with a value of "True":

CreateHardLinksForCopyFilesToOutputDirectoryIfPossible
CreateHardLinksForCopyAdditionalFilesIfPossible
CreateHardLinksForCopyLocalIfPossible
CreateHardLinksForPublishFilesIfPossible

Use command line properties (msbuild /p:CreateHardLinksForCopyLocalIfPossible=true) to override them for all projects in one build. Or you can create a little startup build file that collects all projects and set the properties in one place. Here is mine:

Code Snippet
<?xml version="1.0" encoding="utf-8"?>
 <Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" >
 
   <PropertyGroup>    
     <Include>**\*.csproj</Include>
     <Exclude>_build\**\*.csproj</Exclude>
     <CreateHardLinksIfPossible>true</CreateHardLinksIfPossible>
   </PropertyGroup>
 
   <ItemGroup>
     <ProjectFiles Include="$(Include)" Exclude="$(Exclude)"/>
   </ItemGroup>
 
   <Target Name="Build" >
     <MSBuild Projects="@(ProjectFiles)" Targets="Build" BuildInParallel="True" ToolsVersion="4.0"
              Properties="Configuration=$(Configuration);
                          BuildInParallel=True;
                          CreateHardLinksForCopyFilesToOutputDirectoryIfPossible=$(CreateHardLinksIfPossible);
                          CreateHardLinksForCopyAdditionalFilesIfPossible=$(CreateHardLinksIfPossible);
                          CreateHardLinksForCopyLocalIfPossible=$(CreateHardLinksIfPossible);
                          CreateHardLinksForPublishFilesIfPossible=$(CreateHardLinksIfPossible);
                          " />    
   </Target>
   
 </Project>

Feature Toggle Status Page

2011-08-06T22:42:00.001+02:00

If a website uses Feature Toggles it should have some diagnostic page that displays the the current configuration and state of all toggles. On our Feature Toggle status page it is even possible to explicitly switch a toggle ON or OFF with one click. Another feature that I like is, that you can quickly see toggles that are still in use but nowhere configured. This is an indication that it was forgotten to remove some code.

More cool Feature Toggle Features

2011-08-06T22:09:00.001+02:00

We have extended our Feature Toggle implementation with two more features:

an activation interval that determines in advance when a toggle is on or off
a toggle that is only enabled for a certain rate of visitors

We release new versions every two weeks and sometimes the activation of a feature is coupled to a fixed date by marketing or legal reasons. You could argue that the feature itself should implement the date checking but it was attractive to use the existing Feature Toggle infrastructure. Our existing implementation could be easily extended to support this, but I admit that it added complexity and that the implementation is now a little bit impure in the sense that it is now no longer exclusively used as a development tool.

The Feature Toggle configuration is still simple and readable. Everything except the name attribute is optional so you have to specify only the borders you need:

<toggle name="myFeature" enabled="true" /> 
<toggle name="myFeature" enabled="true" from="2012-01-01" /> 
<toggle name="myFeature" enabled="true" to="2012-06-01" /> 
<toggle name="myFeature" enabled="true" from="2012-01-01" to="2012-06-01" />

The second feature was inspired by the allowHttpOverride property original developed for testing purposes. If a user visits our page the toggle decides randomly with the given rate if the toggle is on or off. The result is stored inside a browser cookie and never changed. So it works for features that span several pages or workflows. The rate feature is extremely useful if you plan to do canary releases for only a few percent of your users. If everything works fine you can slowly increase the rate until it reaches 100%.

Every toggle attribute can be combined with every other attribute, e.g. a toggle that is on only for a specific interval with a specific rate and overriding it per cookie or query parameter is not allowed:

<toggle name="myFeature" enabled="true"  
        from="2012-01-01" to="2012-06-01"
        rate="42"
        allowHttpOverride="false" />

A Cool 'Feature Toggle' Feature

2011-06-26T19:11:00.001+02:00

Recently we gave our Feature Toggles the possibility to be overridden at runtime. For a web application I found this extension quite useful and its implementation was easy and straightforward. This is the configuration for toggles that are always on or off:

<featureToggles>
     <toggle name="aFeature" enabled="true" />
     <toggle name="anotherFeature" enabled="false" />
 </featureToggles>

If I want that the toggle can be overridden at runtime I just add one additional attribute:

<featureToggles>
     <toggle name="aFeature" enabled="true" allowHttpOverride="true"/>
     <toggle name="anotherFeature" enabled="false" allowHttpOverride="true"/>
 </featureToggles>

Now if a visit a page, say www.atombrenner.de/test, I can modify the url to be www.atombrenner.de/test?aFeature=off and now for the complete request the toggle is off. For workflows that cover more than one page request we use cookies. Just create a new cookie with your favorite cookie manager (I like the 'Edit this cookie' plugin for Google Chrome very much).

The name of the cookie must be the name of the toggle you want to override. Allowed values are: 0, 1, off, on, false, true. If both a query string value and a cookie value is given, the query string parameter wins.

If find this feature extremely useful because it allows you to toggle very quickly the feature on or off, without the need for recompiling or reconfiguring. This enables you

to always test that your app is still stable when the new feature is turned off
to give testers or managers a quick preview of the feature during development
to provide external partners a preview of the feature in the live environment, so they can test and accept features before it goes public.

Exception Logging Antipatterns

2011-06-26T13:19:00.001+02:00

Here are some logging antipatterns I have seen again and again in real life production code. If your application has one global exception handler, catching and logging should be done only in this central place. If you want to provide additional information throw a new exception and attach the original exception. I assume that the logging framework is capable of dumping an exception recursively, that means with all inner exceptions and their stacktraces.

Catch Log Throw

catch (Exception ex)
 {
     _logger.WriteError(ex);
     throw;
 }

No additionally info is added. The global exception handler will log this error anyway, therefore the logging is redundant and blows up your log. The correct solution is to not catch the exception at all.

Catch Log Throw Other

catch (Exception ex)
 {
     _logger.WriteError(ex, "information");
     throw new InvalidOperationException("information"); // same information
 }

Same as Catch Log Throw, but now you have two totally unrelated log entries. Solution: use the InnerException mechanism to create a new exception and don't log the old one:
throw new InvalidOperationException("information", ex);

Log Un-thrown Exceptions

catch (Exception ex)
 {
     var myException = new MyException("information"); 
     _logger.WriteError(myException); 
     throw myException;
 }

In this case an un-thrown exception is logged. This could cause problems, because the exception is not fully initialized until it was thrown. For example the Stacktrace property would be null. Solution: don't log, just attach the original exception ex to MyException:
throw new MyException("information", ex);

Non Atomic Logging

catch (Exception ex)
 {
     _logger.WriteError(ex.Message);
     _logger.WriteError("Some information");
     _logger.WriteError(ex);
     _logger.WriteError("More information");
 }

Several log messages are created for one cause. In the log they appear unrelated and can be mixed with other log message. Solution: Combine the information into one atomic write to the logging system: _logger.WriteError(ex, "Some information and more information");

Expensive Log Messages

{        
    [...] // some code         
    _logger.WriteInformation(Helper.ReflectAllProperties(this));         
}

This one is really dangerous for your performance. An expensive log message is generated all the time even if the logging system is configured to ignore it. If you have expensive message, put the generation into an if block side by side with the logging statement:

if (_logger.ShouldWrite(LogLevel.Information))
{
    // do expensive logging here
    _logger.WriteInformation(Helper.ReflectAllProperties(this));

}

Disable ASP.NET Development Server

2011-06-13T11:19:00.002+02:00

I always forget how to stop the ASP.NET Development server from starting when I attach to the IIS for debugging, so here is the way to do it:

Select the web or WCF project. Press F4 to show the property window. If only an empty window appears, repeat the process.
Set the first property to "False".

If your solution contain projects that start the ASP.NET Development Server you will enjoy my macro that sets this property solution wide:

Sub TurnOffAspNetDebugging()

    REM The dynamic property CSharpProjects returns all projects 

    REM recursively. "Solution.Projects" would return only the top 

    REM level projects. Use VBProjects if you are using VB :-).          

    Dim projects = CType(DTE.GetObject("CSharpProjects"), Projects)

    For Each p As Project In projects

        For Each prop In p.Properties

            If prop.Name = "WebApplication.StartWebServerOnDebug" Then

                prop.Value = False                  

            End If

        Next

    Next

End Sub

Feature Toggle or Feature Branch

2011-06-12T22:37:00.001+02:00

I'm working in company that releases every two weeks with the goal to do weekly releases and eventually daily releases. We introduced Feature Toggles for the development of features that overlap a release without destroying Continuous Integration.

Recently I noticed that people start using Feature Toggles for features that take only a few hours to implement. In this case the effort to setup, configure and test the Feature Toggle is easily more than 50 percent of implementation effort. It would be much more efficient to create a branch and merge it one or two days later back to the trunk. The cost for having no continuous integration is less than the cost for using a toggle in this case.

Why are people doing this? One answer could be that they are entrapped by the possibility to dynamically turn features on or off. Another is process thinking: because there was a process that enforced feature branches for feature development it is believed that you now must use Feature Toggles. Another company specific reason is that we had feature branches coupled with a heavyweight process (including the setup of a complete cloned environment with automatic builds, databases, dozens of service, ...) that was so painful that everybody shivers when hearing the word Feature Branch.

Make sure that you are using feature toggles and feature branches for the right things. A lightweight feature branch needs much less brainpower than implementing of a toggle for the modification of an legacy feature.

Why a Feature Toggle should be ‘OFF’ if it is undefined

2011-03-30T07:50:00.001+02:00

When I first implemented some infrastructure supporting Feature Toggles I thought it was a good idea to have three states: on, off and undefined. If some code access a feature that is not defined it should throw an exception. The reason for this was that I used a fairly dynamic approach where a feature was identified by its name. This allows simple adding and removing of feature toggles without the static typing overhead. The drawback is that typing errors cannot be found by the compiler or interpreter, e.g. the feature is defined as “Toggle” but you write “togle”. In this case I thought it would be good to throw an exception.

But if you are developing a component that is is used in several applications than you have to define the feature in every applications configuration. Even if the feature should be disabled everywhere except in your test application. And if the feature is finished you have to remove the feature from all application configuration again. Error prone and time consuming.

Therefore an undefined feature toggle should always be treated as ‘OFF’.

Feature Toggles Links

2011-02-24T15:55:00.002+01:00

At work we want to use Feature Toggles (Branching in code) to avoid “Feature Branch Hell”. Here is a list of links with experiences and definition from others with thanks to Pete and Natalya.

Visual Studio 2010 Javascript Snippets for Jasmine

2011-02-16T20:56:00.001+01:00

Because Resharper 5 does not support live templates for Javascript I’m forced to use the built in VS2010 snippets. The default Javascripts snippets are located here:

%ProgramFiles%\Microsoft Visual Studio 10.0\Web\Snippets\JScript\1033\JScript

The ‘1033’ locale ID may be different for your country. I’m using the following snippets for creating Jasmine specs:

describe

<CodeSnippet Format="1.1.0" xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
<Header>
    <Title>describe</Title>
    <Author>Christian Rodemeyer</Author>
    <Shortcut>describe</Shortcut>
    <Description>Code snippet for a jasmine 'describe' function</Description>
    <SnippetTypes>
      <SnippetType>Expansion</SnippetType>
    </SnippetTypes>
</Header>
<Snippet>
    <Declarations>
      <Literal>
        <ID>suite</ID>
        <ToolTip>suite description</ToolTip>
        <Default>some suite</Default>
      </Literal>
    </Declarations>
    <Code Language="jscript"><![CDATA[describe("$suite$", function () {
        $end$
    });]]></Code>
</Snippet>
</CodeSnippet>

it

<CodeSnippet Format="1.1.0" xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
<Header>
    <Title>it</Title>
    <Author>Christian Rodemeyer</Author>
    <Shortcut>it</Shortcut>
    <Description>Code snippet for a jasmine 'it' function</Description>
    <SnippetTypes>
      <SnippetType>Expansion</SnippetType>
    </SnippetTypes>
</Header>
<Snippet>
    <Declarations>
      <Literal>
        <ID>spec</ID>
        <ToolTip>spec description</ToolTip>
        <Default>expected result</Default>
      </Literal>
    </Declarations>
    <Code Language="jscript"><![CDATA[it("should be $spec$", function () {
        var result = $end$
    });]]></Code>
</Snippet>
</CodeSnippet>

func

<CodeSnippet Format="1.1.0" xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
<Header>
    <Title>function</Title>
    <Author>Christian Rodemeyer</Author>
    <Shortcut>func</Shortcut>
    <Description>Code snippet for an anonymous function</Description>
    <SnippetTypes>
      <SnippetType>Expansion</SnippetType>
      <SnippetType>SurroundsWith</SnippetType>
    </SnippetTypes>
</Header>
<Snippet>
    <Code Language="jscript"><![CDATA[function () {
        $selected$$end$
    }]]></Code>
</Snippet>
</CodeSnippet>

Removing the mime-type of files in Subversion with SvnQuery

2011-02-10T21:12:00.001+01:00

If you add files to subversion they are associated with a mimetype. SvnQuery will only index text files, that means files without an svn:mime-type property or where the property is set to something like “text/*”. At work I wondered why I couldn’t find some words that I know must exist. It turned out that subversion marks files stored as UTF-8 files with BOM as binary, using svn:mime-type application/octet-stream. This forces the indexer to ignore the content of the file.

I used SvnQuery to find all files that are marked as binary, e.g. t:app* .js finds all javascript files and t:app* .cs finds all C# files. With the download button at the bottom of the results page I downloaded a text files with the results. Because svn propdel svn:mime-type [PATH] can work only on one file (it has no --targets option) I had to modify the text file to create a small batch script like this:

svn propdel svn:mime-type c:\workspaces\javascript\file1.js
svn propdel svn:mime-type c:\workspaces\javascript\file1.js
svn propdel svn:mime-type c:\workspaces\javascript\file1.js
…

After this change indexing worked again. I now run a daily query that ensures that no sources files are marked as binary.

What means “Skipped” in the subversion merge log?

2011-01-23T17:24:00.001+01:00

I have seen many people who tend to ignore the “Skipped” messages that are sometimes displayed when you do a merge with subversion:

The “Skipped” message means that the merge operations wants to create or modify a file but that file already exists in your working copy and is not under version control (added to the repository:This can easily happen if you do a forward merge from trunk to a brunch and revert your local changes to the working copy (maybe because some manual merges went wrong). The revert command will leave new files as orphaned files in the working copy.

Don’t ignore those warnings! If you commit a working copy with “Skipped” warnings and do a backward (reintegrate) merge from branch to trunk, subversion will delete the formerly skipped files from the trunk! As a rule, you should never ignore “Skipped” warnings and if they occur fix the root problem then repeat the merge on a clean working copy.

C# Object Initialization Wonders

2010-11-21T20:04:00.001+01:00

Since I am coding a lot in JavaScript recently I tend to use C# Object Initialization more often than before. Last evening I had an astonishing experience …

I had a class Foo

public class Foo
{
public List<string> Data { get; set; }
}

and wrote this object initializer:

var bar = new Foo {Data = {"a", "b"}};

The first wonder was that this code actually compiles. Fine, nearly as compact as JavaScript. But at runtime I had a mysterious error. When I finally inspected the Data property with Debug.WriteLine(string.Join(", ", bar.Data)); it contains 1, 2, a, b and not the expected a, b. So the former assignment to Data was not setting the property but somehow adding to the existing content. Looking into the Foo constructor proved this.

public Foo()
{
Data = new List<string>{"1", "2"};
}

The compiler interpreted the assignment to the Data property as a collection initializer and was just calling Add() for “a” and “b” on the existing collection. To overwrite the existing collection I had to specify a new type:

var bar = new Foo {Data = new List<string>{"a", "b"}};

I’m not really sure if this is a bug or a feature …

Always “Compare whitespaces” when merging

2010-10-14T17:15:00.001+02:00

I am working in an environment where we develop features in branches, using Subversion and TortoiseSVN. Every day we do a forward merge from the trunk to branch. When the feature is complete the branch is merged back to the trunk and the branch gets deleted. Recently I noticed a lot of whitespace issues, like wrong indentations. It turned out that the reason for this is one commonly misunderstood option in the merge dialog of TortoiseSVN: “Compare whitespaces”

The default settings of this dialog are the correct ones but many developers automatically click on one of the "Ignore whitespace" options. Why? Because they are using this option in their diff tools all the time. But what is good when comparing is actually a very bad thing when merging. Imagine that someone surrounds some existing code with an “if” or “try-catch” block. That would indent the existing code which is just a whitespace change. The new indentation will not be merged to the branch if you choose one of the ignore options! The same is true if you changed tabs to spaces or inserted some empty lines. And now comes the worst problem: You chose to ignore whitespaces on forward branches. But you didn't ignore them when merging back to the trunk. Now you actually have erased all whitespace changes from the trunk between the time you created the branch and the time you merged it back!

So remember one thing: Always choose "Compare whitespaces" in the merge options!

Speed up your Subversion repository

2010-08-21T10:11:00.001+02:00

Normally, I am satisfied with the performance of Subversion. I used to work on a 20GB repository with ca 20000 revisions, 20 developers in a not so fast local network. Daily business operations like update, commit were done in a few seconds.

Now I work with 30 developers on 4GB repository with ca 18000 revision in a super fast network. And the performance sucks, compared to my former experiences. A checkout of a 120MB working copy takes more than 10 minutes. Updating (without any changes) takes at least 40 seconds.

So what’s the problem here? I have some guesses but are not yet sure about the real reasons. But here are my suggestions:

Use the FSFS mode (I hope nobody is using Berkeley DB anymore?)
Use Sharding. This affects the way how the repository is stored on the server. At most 1000 files are put in one directory then another directory will be created. This helps a lot if the underlying file system performance worse with an increasing number of files per directory.
Pack your repository regularly. Normally, each revision is stored as a single file. If you have a sharded repository then svnadmin pack will convert all full shards into one big files. This saves space and helps the OS to reduce I/O and improve caching.
Use the svn:// protocol. The http and https protocols are just a tunnel for WebDAV delta-v which is a quite chatty protocol. For each file you need a full roundtrip from the client. On high latency networks this could be a real bottleneck. The svn protocol is much faster and consumes less cpu cycles. On my test machine a complete checkout of 120MB working copy took on average 5min 20s over https:// and only 4min over svn://.
Check your commit hooks. Perhaps you have installed some expensive commit hooks. On Windows, try using RunDetached to prevent subversion from waiting for the hook to finish.
Beware of Polling Build Agents. If you are Continuous Integration there will be some kind of mechanism in place to detect changes in the repositories. The most efficient one is a post commit hook, but for example CruiseControl.NET and TeamCity use an inefficient polling approach that is basically doing an “svn log” and parsing the output. Doing this over https every second from forty build agents can easily bring up the load on the repository server to 100%. A more efficient polling mechanism would be to store the latest revision and query only the newest revision of the repository. This is only implemented by some custom plugins.
Monitor I/O load. Still, when people think of performance they think of CPU performance. But for the subversion repository I/O is the limiting resource. An update or checkout operation will do many small reads on different areas of the repository. Therefore the average access time is the most important factor. If your repository is running on a virtual machine make sure that the repository is located on a physical drive that is exclusively reserved for this purpose. Use a SSD or at least a 10,000 RPM drive.
Store your repository on a Intel Solid State Disk. The disk should be exclusively reserved for use by the repository. No other application should touch it. This is the simplest and most effective way to improve performance.
Optimize your working copy. Change the layout so you can do partial updates. Try to use svn update –-svn-depth -exclude to exclude parts you don’t need in your day-to-day work. Remove files you don’t need.

Note: All tips are written at the time of Subversion 1.6 and increase the server performance. Subversion 1.7 will improve the local working copy which theoretically should also increase the client performance.

Requirements for a Dependency Injection Container

2010-08-08T23:41:00.001+02:00

Recently I was asked by a coworker about my requirements for a DI Container as part of a poll to all developers. My first reaction was to answer with the famous Ford quote “If I’d asked people what they wanted, they would have said faster horses.” This was because I personally realized the benefits of using a DI container only after working with one in a real project. Before this experience I wasn’t really able to give reasons why I should use one at all. Sure, I wanted one to try out, because I had the feeling it could be useful, but giving requirements was out of scope.

Today I have worked with Spring.NET and much more with Unity. I know StructureMap and Autofac (but Castle Windsor is still on my list :-). I believe that DI containers should be provided by the .NET framework (and sooner or later will be) just like the collection classes. No big up front requirements analysis should be done because a DI container is no longer rocket science. Just start using one that is accepted by the community. If you haven’t used one you wouldn’t know what a DI can do for you. If you have used only one you would repeat features as requirements. If you know more than one you would list the features you love most.

This is my list of important and useful features:

Container setup should be possible in code with a readable and fluent API. Use explicit xml configuration only as a last resort (too much bad experiences with Spring.NET xml configuration). Setup with code allows intellisense and checking at compile time. Most setups will be done in test code, not in production code!
Wiring dependencies should be possible by conventions or attribute based. Use explicit wiring only as a last resort (bad maintainability).
Understandable error message and diagnostic help if something went wrong when constructing/resolving a type.
Constructor and property must be possible, event and method injections would be nice to have.
Nested Container. That means you can create a container that inherits from an existing one and add or overwrite some mappings or strategies. Useful for test code.
Extensibility: it should be possible to implement autofaking or automocking strategies (described here and here) which are extremely useful for unit testing.
Lifetime of objects should be configurable in different ways (free, singleton, container bound, thread bound, …).
If object lifetime can be bound to the container lifetime the disposal of the container should also dispose all contained objects.
Automatic factories. The possibility to not inject a single object but a generic factory, say Func<T>(), without explicit configuration.
The container should have at least two distinct interfaces, one for configuring the container and one for resolving/constructing types.
Static Service Locator Facade (with override possibility) for working with legacy code.
Partial construction if you have no control over object creation (for frameworks like WPF or ASP.NET) but still want to use you container to inject some dependencies.
Should have no or very tedious interface to specify constructor parameters at resolve time. Reason: if you do so you don’t use your DI container as intended.
… (to be continued) …

How to change the ReSharper naming style for test methods

2010-07-25T12:52:00.001+02:00

For normal methods I use the Pascal casing convention (or UperCamelCase as it is called by ReSharper). But in unit tests readability rules and therefore I use very long names like:

public void MethodUnderTest_Scenario_ExpectedResult()

ReSharper marks them as violating the naming style, which is quite annoying because this distracts from real problems. Luckily there is a way to tell ReSharper to use a different naming convention for test methods. It is a little bit hidden in the ReSharper options, but here is the way to go:

ReSharper Options –> Naming Style –> Advanced settings

In “Affected entities” mark “Test method (property)” and disable inspections.

Now you have no warnings in your tests anymore that complain of inconsistent naming styles. Naming styles for non test classes and methods are still working as before. This was tested with ReSharper 5.1.

Don’t use keyword substitution if you use branches

2010-07-05T14:03:00.001+02:00

Many version control systems use some kind of keyword substitution, e.g. in Subversion the keyword $Author:$ gets replaced on every commit through the committing author, say $Author: crodemeyer$. Now imagine that you have several branches of your trunk and that each branch is modified in parallel. When the time comes to merge back the changes to the trunk you will get many conflicts. They cannot be resolved automatically because in every branch the same line of code has been changed. Indeed you have entirely broken automatic reintegration of branches if you use keyword replacement.

Fortunately Subversion has the possibility to control keyword substitution with the svn:keywords property. Be a hero and use “svn pd svn:keywords –R” to disable keyword substitution completely.

Always databind SelectedItem before ItemsSource

2010-05-02T16:20:00.001+02:00

The order in which bindings are defined in Xaml are relevant. Look at this Example: I have a ComboBox and a ViewModel. The ItemsSource of the ComboBox is bound to the Repositories property and SelectedItem is bound to SelectedRepository.

The constructor of the ViewModel initializes the Repositories with a non empty collection and sets the SelectedRepository to the first element.

public ViewModel()
{
Repositories = new List<string> {"First", "Second", "Third"};
SelectedRepository = Repositories[0];
}

Yet, immediately after starting, I got null reference exceptions from other databound properties that are referencing the SelectedRepository property! After a little debugging I found out that when assigning the ViewModel to the DataContext of the view, the Binding Engine assigns null to the SelectedRepository! If you change the declaration of Databinding everything works as expected:

Conclusion: the order of databinding declaration matters!

Using Assembly.CodeBase to get the location if shadow copied

2010-04-30T14:15:00.003+02:00

A long time I had problems with NUnit tests that needed to access files living relative to the tested dll. NUnit (and Resharper) are shadow copying a dll before running the test, so the Location property of an assembly returns the path to the shadow folder and not the original location where the expected file lives. My solution was to disable shadow copying in NUnit and Resharper. But every now and then I forgot to disable it in new projects. The result was spending time with debugging until I remembered to disable shadow copying.
But now I have found by chance a much better solution, which is more robust and also useful for other shadow copying scenarios like hosting WCF services in IIS. You can use the assemblies CodeBase property to get the original location. The only drawback is that the codebase is formatted as a Uri. It normally includes a file protocol “file:///” and uses slashes ‘/’ instead of backslashes ‘\’, so you need to modify the returned string a bit:

var assembly = Assembly.GetExecutingAssembly();

var path = assembly.CodeBase.Replace("file:///", "").Replace("/", "\\");

I believe that in certain scenarios you may see other protocols (perhaps http://) but for unit testing scenarios that relieves from the pain of remembering to disable shadow copying.

Mercurial tutorial by Joel Spolsky

2010-02-25T17:21:00.001+01:00

A really good mercurial tutorial (especially for those who are damaged by subversion) by Joel Spolsky:

http://hginit.com/index.html.

Wissensvermittlung und ein Konfuzius Zitat

2010-02-23T13:51:00.001+01:00

Ich habe gerade ein sehr passendes Zitat von Konfuzius gelesen (Papier, OBJEKTspektrum 03/2009) indem ich mich selbst wiedererkenne, wenn es um Wissensvermittlung geht:

“Erkläre es mir und ich werde es vergessen. Zeige es mir und ich werde mich erinnern. Lass es mich selber machen und ich werde es verstehen.”

Expression Blend 3 Design Time Attributes

2010-02-23T12:43:00.001+01:00

Only a few people (including me until a few weeks ago) know that Expression Blend supports so called “Design Time Attributes”. These properties are very valuable to get “Design Time Data” into Blend. Without those example data designing DataTemplates is cumbersome and no fun. Those Design Time Attributes are not documented at all and I found out about them only by chance, reading some blogs. It seems that they are officially introduced with VS 2010 and documented there. Nevertheless they are fully functional with VS 2008 because they are ignored by the compiler and only used by design tools like blend.

All Design Time Attributes live in the d: namespace:

d:DesignHeight	In Blend, there is a special handle you can use to modify the d:DesignHeight and d:DesignWidth attributes without modifying the real Height attribute. This is handy if you just want to test some resizing logic.
d:DesignWidth
d:DataContext	Lets you specify the DataContext used at design time. Example: d:DataContext={StaticResource MyDataContextObject}, or even better use d:DesignInstance
d:DesignInstance	d:DataContext="{d:DesignInstance Type=local:MyDataContext, IsDesignTimeCreatable=True}"
d:DesignData	needs VS2010, links to a sample data object defined in a xaml file
d:DesignSource	sets the Source property of a CollectionViewSource at design time

You are not thy user

2010-02-15T21:51:00.001+01:00

I have just finished reading Dave S. Platt’s book “Why Software SUCKS”, and it was a lot of fun. I like his polemic and exaggerated way to make his point. And I strongly believe that at its heart he is absolutely right in his findings.

The believe of programmers, that the user of a program is like him, causes much if not all of the trouble with the usability of programs nowadays. “You are not your user” says Platt. And if a programmer thinks “If I design a user interface that I like, the users will love it.” Dave says “Wrong!”. This is not new knowledge, in Germany we know it as “Der Trugschluß der egozentrischen Intuition”, but no one before described it in such a catchy way.

But I don’t like the oversimplification that always the programmer is the bad guy. In my experience the same amount of damage to usability is done by every person in the development chain, that means QA people, project managers, sales people, directors and the people responsible for buying.

Think of Joe Programmer, who actually knows something about user interface design and has studied it for several years. He has seen the actual users in person and at work and knows the problem thy want to solve. He has designed a beautiful user interface and now his boss comes in, demanding a short review. “I don’t like that. My favorite GeekyApp does it like this, I like it and therefore it must be liked by the customer. Please change your software so that it does work like my beloved GeekyApp.” Ouch. Next comes the QA guy: “I need to test the performance of your app and I don’t like to manually create 1000th entries of test data, could you please add some batch generator to your UI, it would help me doing my job faster!” Argh, no user will ever do what you poor QA guy have to do. Now the sales people cry: “I need more colors and more animations. Otherwise I can’t sell it!” Sigh. Then the project manager declares: “I need a quick way to discover what is going on in the customers installation, please give me more analysis features.” Last but not least, even the people who are responsible for buying the software force him to cripple the user experience because the prefer to buy what they like and not what their users like. Poor users, no wonder why so many software sucks.

My tip for Joe Programmer: Not only the final user has needs, everyone in the chain has his own needs. You cannot ignore them but must find a way to satisfy them adequately. You can give QA an automation api without compromising the user interface. You can build a system diagnosis view, that the normal user never will see. You can argue with sales and your boss (point them to Platt’s book). Offer some “baffle” mode for presentations and to convince the buying agent. This is a lot of work but by reading “Why Software SUCKS” you have a chance to convince the other people that they are also not like your users. At least it helps to detect the trap before falling into it.

New NUnit syntax of how to expect exceptions

2010-01-23T18:17:00.001+01:00

I have just stumbled upon a new beautiful syntax of how you can write a unit tests that expects that a method throws a certain exeception or an exception derived from it. First your test fixture needs to inherit from AssertionHelper which gives you the static Expect method. Then you can implement a test like this:

[Test]
public void GetExternals_InvalidWorkingCopy_ThrowsSvnException()
{
    // Arange
    var ep = new WorkingCopyCache();

    // Act & Assert
    Expect(() => ep.Get(@"X:\Dummy"), Throws.InstanceOf<SvnException>());
}

To be honest this constraint based syntax exists for quite a while now, but I just didn’t know before. IMHO it is very powerful and readable, compared to other solutions. For more details about how NUnit evolved to finally arrived at this syntax see this blog http://nunit.com/blogs/?p=63.

AssemblyAttributes

2009-12-19T10:54:00.002+01:00

This is a cute little helper class that is useful for almost every .NET or Silverlight application that displays some information about itself (think “About Box”). It retrieves the values of the following assembly attributes in an easy and consistent manner:

Title
Product
Copyright
Company
Description
Trademark
Configuration
Version
FileVersion
InformationalVersion

Doing so is a piece of cake for every experienced developer but getting these information for the 100th time manually through reflection is quite cumbersome. And junior developers sometimes don’t know where to start and get lost in learning about reflection and attributes.
With the help of generics and lambdas you can code an elegant class that solves this problem one and for all. Usage is like this:

AssemblyAttributes assembly = new AssemblyAttributes();

string title = assembly.Title;
string version = assembly.Version;

And this is the full source:

/// <summary>
/// Easy access to common Assembly attributes.
/// </summary>
public class AssemblyAttributes
{
    readonly Assembly _assembly;

    public AssemblyAttributes() : this(Assembly.GetCallingAssembly())
    {}

    public AssemblyAttributes(Assembly assembly)
    {
        _assembly = assembly;
    }

    public string Title
    {
        get { return GetValue<AssemblyTitleAttribute>(a => a.Title); }
    }

    public string Product
    {
        get { return GetValue<AssemblyProductAttribute>(a => a.Product); }
    }

    public string Copyright
    {
        get { return GetValue<AssemblyCopyrightAttribute>(a => a.Copyright); }
    }

    public string Company
    {
        get { return GetValue<AssemblyCompanyAttribute>(a => a.Company); }
    }

    public string Description
    {
        get { return GetValue<AssemblyDescriptionAttribute>(a => a.Description); }
    }

    public string Trademark
    {
        get { return GetValue<AssemblyTrademarkAttribute>(a => a.Trademark); }
    }

    public string Configuration
    {
        get { return GetValue<AssemblyConfigurationAttribute>(a => a.Configuration); }
    }

    public string Version
    {
        get
        {
#if !SILVERLIGHT
            return _assembly.GetName().Version.ToString();
#else
            return _assembly.FullName.Split(',')[1].Split('=')[1]; // workaround for silverlight
#endif
        }
    }

    public string FileVersion
    {
        get { return GetValue<AssemblyFileVersionAttribute>(a => a.Version); }
    }

    public string InformationalVersion
    {
        get { return GetValue<AssemblyInformationalVersionAttribute>(a => a.InformationalVersion); }
    }

    /// <summary>
    /// Returns the value of attribute T or String.Empty if no value is available.
    /// </summary>
    string GetValue<T>(Func<T, string> getValue) where T : Attribute
    {
        T a = (T)Attribute.GetCustomAttribute(_assembly, typeof(T));
        return a == null ? "" : getValue(a);
    }

}

The real workhorse of this class is the GetValue<T> method. It gets an arbitrary custom attribute from an assembly. If it exists, it returns the result of applying the getValue delegate on it. If the attributes does not exist, it returns the empty string.

The full article with downloads is posted at CodeProject.

Improve performance through using FileAccess.Write

2009-12-14T16:36:00.001+01:00

At work I’m implementing a little app that copies video files from cameras to network folders. The size of a video file is usually several hundred megabytes. The target file is written with the standard .NET FileStream class. The strange thing I noticed was that calling Close on the stream took between 15 and 20 seconds. Even if I flushed the stream Close call took ages. I created the stream like this

var output = new FileStream(path, FileMode.Create);

After playing with the available constructor overloads I found a better solution:

var output = new FileStream(path, FileMode.Create, FileAccess.Write, FileShare.Read);

Using this overload, the Close call took only 1 millisecond! That means a performance boost of factor 20000 just by using the right FileAccess Options.

Tip: Always use the “Read” or “Write” if you don’t need “ReadWrite”. This will give you a performance boost on network files.

Open Xaml file in Xml view without loading the Designer

2009-12-12T16:29:00.002+01:00

I use Expression Blend almost always as a design tool for my WPF projects. If I want to do quick modifications inside the xaml code from Visual Studio, I find the designer loading time quite annoying. But VS offers you the possibility to open xaml files in the xml/xaml view by default. Just open Tools –> Options –> Text Editor –> XAML –> Miscellaneous and tick “Always open documents in full XAML view” check.

WiX Lessons Part 2

2009-12-08T22:34:00.001+01:00

Today I did some localization of my WiX based installer and learned, that Windows Installer must have a very old code base. While localization with WiX is really easy it inherits some limitations that you don’t expect nowadays. First you cannot use UTF8 or Unicode to define your string tables. No, you need to specify windows codepages that should be used for a concrete language. Unicode is not supported. So you have to dig in old documentation for appropriate codepages (Luckily I can use Windows-1252 for West European Languages). Second you cannot simply build one msi for all languages. You must build a msi package for every language. Then you can either use a bootstrapper to decide which msi to start, or you can use some black magic on the command line which uses transformations at runtime to morph one msi into the appropriate language. Multi Language packages are not built into Windows Installer.

I had another strange behavior today regarding the usage of WiX library. I made a simple library with some very minimalistic installer gui which needs three images. The three images are located inside an Images folder. See attached picture for the project structure. The files are referenced like this:

First build succeeded than it always failed, saying that it could not find “Images\banner.bmp”. It seems some tool in the chain needs an absolute path because I fixed the build by adding the $(sys.CURRENTDIR) preprocessor directives:

SourceFile="$(sys.CURRENTDIR)Images\banner.bmp"

And you need to check “Bind files into the library file” on the Build page of the project properties. Else the library contains only the filenames and every project using the library must have access to the absolute path of the images. By default this is unchecked which imho corrupts the meaning of a redistributable library.

Windows 7 Upgrade

2009-11-23T17:17:00.001+01:00

Last week I have upgraded my business notebook from Vista to Windows 7. I have lots of stuff installed on this machine and I wanted to save time reinstalling every little tool I need. And it worked!

I started the setup in the afternoon and when it said “This can take several hours” decided to go home early this day. In the next morning it prompted for the serial key and wow Windows 7 was ready! In only needed to adjust the desktop resolution and was able to continue working without interruption. Every shortcut, every app was just working. This was the fastest and most impressive OS update I have experienced in the last twenty years.

And working with Windows 7 is really more effective! All those subtle changes that you begin using without noticing. Working feels much fluffier now and I instantly became addictive. Must upgrade all other PC’s now …

WiX Lessons Learned

2009-10-29T09:41:00.002+01:00

The last week I was playing around with the Windows Installer XML to create a simple setup for a very simple product implemented with .NET. All I needed to do was to copy some files, install a service under a custom account, let the user enter the address of some web services.
These features are hot:

open source
frontend for the built-in windows installer
done by people who know windows installer inside out
simple declaration of files and actions in xml
simple install/deinstall of services with properties like windows account or description
custom actions can done with .net very easily, they have read/write access to properties via a session object (see tutorial)
you can use managed custom actions for easy validation of custom dialogs
can easily integrated into automatic msbuild builds
very good logging capabilities which helps you on debugging
property based, declarative style
property values can be changed by administrators to support customized automatic install on clients
support for commit/rollback and repair/maintenance mode

But this is what bites me:

Bringing new Custom Dialogs (e.g. query user/password) into the dialog chain is really a pain in the ass. The chaining is done through adding event-actions to the next/back buttons which open new dialogs. Adding some conditional logic if a dialog should be shown or not has to be done by attaching conditions on the adding of event actions of the Next button of the previous dialog and the Back button of the following dialog. An you have to deal with this because on Repair/Maintenance Mode your need probably another dialog sequence.
Managed Custom Actions don’t seem to work in elevated mode. The bad thing is, that the installation succeeds without an error, and the custom action is ignored (that is unless you look into the log file).
There is no easy way to manipulate files, say app.config on the fly during installation. There is an XmlConfig extension you can use, but using it is rather crude, if you know how to do it in managed code.
The GUI support is very limited, you can have edit, password, combobox, listbox, check and radio controls, but layouting is done by entering x and y coordinates by hand. Browsing for a file is impossible, you can browse only for directories.

Other things:

You need the WiX tutorial or you are lost
You need DTF (Deployment Tools Foundation) for managed custom actions
- it is included in the WiX package
- the documentation is hidden in the doc folder of you installation … it is neither linked from the WiX documentation nor to be easily found on the internet
If you are a mortal .NET developer you have to do bend your mind to understand it, the windows installer technology sometimes feels like C64 basic with line numbers. Don’t be afraid, after one or two frustrating days you will get it.

IE8 Kompatibilitätsansicht für Intranetsites

2009-10-20T22:41:00.008+02:00

Nachdem ich nun dem Table Layout abgeschworen habe und ins CSS Lager gewechselt bin, habe ich am Wochenende auch mein Hobbyprojekt SvnQuery auf CSS umgestellt. Das hat zwar etwas Mühe gekostet, aber dafür habe ich wieder etwas gelernt, das html hat eine klare Struktur und nebenbei wurden noch einige andere html Fehler beseitigt.

Zurück in der Arbeit aktualisierte ich auch die Suche der Firmenrepositories. Doch gleich bei der ersten Suche der Schock: Fette Scrollbalken schon auf der Startseite, offensichtlich wurde das Layout 200% breit statt wie gewünscht 100%. Und das auf dem IE8 gegen den ich hauptsächlich getestet hatte. Hatte ich schlecht getestet? Warum war mir das daheim nicht aufgefallen?

Also schnell das Projekt heruntergeladen, lokal installiert und ausprobiert. Und siehe da, das Layout war wie erwartet. Aber was war das Problem? Irgendwo musste es einen Unterschied geben. Entwickelt hatte ich gegen den ASP.NET Development Server, in der Firma läuft ein IIS6. Also schnell die Seite auf dem lokalen IIS gehostet. Doch auch hier wurde die Seite einwandfrei dargestellt. Jetzt wurde es mysteriös. Der einzige Unterschied, der noch blieb, war, dass auf meinem Enwicklungsrechner ein deutsches Vista mit IIS7 lief, und der Produktivserver mit einem englischen Windows Server 2003 und IIS6 arbeitete. Vielleicht ein Lokalisierungsproblem im IIS oder IE8? Ein Vergleich der Quelltexte von beiden Quellen zeigte zumindestens, dass der ASP.NET DataPager ein paar Texte lokalisierte (First ~ Erste, Next ~ Nächste, ...). Nachdem dies gefixt war, gab es aber auch hier keine Unterschiede mehr ... bis auf die Adressen der verlinkten CSS Stylesheets und Javscripts. Nun lernte ich, dass ASP.NET Scripts an dynamischen Adressen zum Nachladen generiert :
script src="/search/WebResource.axd?d=UV3-E5OwNGFcSb3I84w2&t=6391349351841...
Diese Scripte sind immerhin ca 20k groß und ihre Adresse ändert sich bei jedem Aufruf der Webseite. Vielleicht lag hier das Problem. Also speicherte ich die funktionierende Seite in ein lokales html file und bog händisch Schritt für Schritt die Links von der funktionierenden Quelle auf die nicht funktionierende um, in der Hoffnung irgendwann eine Seite mit dem zerstörten Layout zu erreichen.
Am Ende hatte ich jedoch eine lokale Seite mit Scripten und Stylesheets vom nicht funktionierenden Server, die immer noch das korrekte Layout anzeigte. Jetzt war ich völlig perplex!

Ich lud nun die beiden Seiten, funktionierend und defekt, in zwei Tabs des IE8. Während ich versuchte, mir eine neue Hypothese für dieses seltsame Verhalten auszudenken, schaltete ich immer zwischen beiden Tabs hin und her ... bis mir etwas auffiel. Es gab Unterschiede, aber außerhalb des eigentlichen Darstellungsbereiches. Das Symbol für die Kompatibilitätsansicht im IE8 war im defekten Layout nicht sichtbar! Warum nicht? Der andere Unterschied war in der Statusleiste zu sehen, die funktionierende Seite kam von "Computer" die andere von "Lokales Intranet". Hatte es etwas mit dem berüchtigten Zonenmodell zu tun? Ich konnte im Menüpunkt "Internetoptionen" nichts finden. Aber im Menü "Seite" gibt es den Punkt "'Einstellungen der Kompatibilitätsansicht" und dort gibt es die Option "Intranetsites in Kompatibilitätsansicht darstellen".
D.h. alle Seiten aus dem Intranet (wo sich auch das Firmenrepository befindet) werden in der Kompatibilitätsansicht dargestellt, und in der Kompatibilitätsansicht geht das Layout kaputt! Seiten vom lokalen Computer (localhost, Dateisystem) und aus dem Internet werden im neuen, standardkonformen Modus angezeigt! Offensichtlich ist dies die Standard Einstellung des IE8, wobei mir der Sinn dieser Option wirklich schleierhaft ist. Noch merkwürdiger, dass sie standardmäßig aktiviert ist.

PS: Der Grund für das defekte Layout in der Kompatibilitätsansicht war übrigens ein absolut positioniertes Element, dessen Style die folgenden Attribute fehlten:
right: 1px;
top: 1px;
width: auto;
overflow: hidden;

Homepage Redesign mit Expression Web und Subversion

2009-10-11T23:02:00.001+02:00

Gestern und heute habe ich mit einem Design für meine Homepage begonnen. Diese hatte ich mal vor Urzeiten (ca 2003) nach einem Provider Wechsel neu angelegt aber dann wegen Hochzeit, Kindern etc. nie wieder angefasst. Um den Lachanfällen von Frau, Kollegen und Nachbarn ein Ende zu setzen musste etwas passieren. Und eine gute Gelegenheit mal wieder meine Html Kenntnisse aufzupolieren. Und am besten gleich mal Expression Web 3 ausprobieren. Gesagt getan, rein ins Vergnügen.

Erste Erkenntnis, Table Layout ist out, CSS funktioniert tatsächlich, und nach einer halben Stunde Template Erforschung hatte ich dann a) ein funktionierendes neues Layout mit Navigation und b) endlich verstanden was das Cascading bedeutet. Und das man das Separation of Concerns Prinzip auch auf Stylesheets anwenden kann. Im Vergleich zu Frontpage oder gar dem Html Editor vom Visual Studio ist Expression Web um Lichtjahre besser. Kaum wartet man ein paar Jahre, schon geht alles viel leichter :-)

Doch dann bekam ich Probleme als ich versuchte mein Homepage Projekt unter Versionskontrolle zu stellen, konkret mit Subversion. Expression Web hat ja erstaunlicherweise keine eingebaute Unterstützung für Versionskontrolle außer für Microsofts TFS, welches außerhalb von großen Unternehmen kaum verbreitet sein dürfte. Mit Subversion bekommt man die größten Probleme, wenn Dateien oder gar Verzeichnisse umbenannt oder verschoben werden. Dies muss man unbedingt mit einem Subversion Client machen. Nun sind jedoch genau diese Operationen beim Aufbau einer neuen Struktur nicht gerade selten. Mit Expression Web läßt sich das alles sehr einfach und bequem erledigen, alle Hyperlinks werden automatisch angepasst, etc. Doch danach ist die Subversion Working Copy erst einmal Schrott. OK, dann verschiebe und benamse ich mittels TortoiseSVN. Hat man dabei jedoch Expression Web offen, hatte ich öfters das Problem, das plötzlich Dateien mit altem Inhalt überschrieben wurden, Links kaputt waren und am Ende das Programm behauptete meine Homepage wäre kein gültiges WebSite Projekt mehr.

Grund waren geheime (versteckte) _vti_* Verzeichnisse, deren Inhalt von TortoiseSvn logischerweise nicht upgedatet werden konnte. Letztendlich habe ich meine Homepage wieder aus der Versionskontrolle entfernt und mache jetzt wieder händische Backups des kompletten Verzeichnisses.

Ich frage mich nun, ob überhaupt jemand dieses Programm zu professionellen Web Design hernehmen kann, bzw. wo es Microsoft positioniert? Ohne funktionierende Versionskontrolle kann man doch nicht guten Gewissens arbeiten? Oder arbeiten Web Site Entwickler etwa noch ohne Versionskontrolle? Ich meine ein Versionkontroll Plugin Konzept wäre im Vergleich zu den vielen tollen anderen Features wirklich trivial gewesen. Es muss doch nur eine Benachrichtung übers Anlegen, Ändern, Löschen, Umbenennen, und Verschieben gesendet werden.

Wirklich schade, ohne dieses "fehlende Feature" ist Expression Web 3 wirklich ein tolles Produkt.

Don't forget to run aspnet_regiis and ServiceModelReg

2009-10-06T16:13:00.004+02:00

Every few month I run into weird installation problems on IIS so that ASP.NET applications (including .svc WCF services and Silverlight applications) don't run with misleading error messages. Today I was running into this problem again. Seems that I hadn't the correct permissions to download a .xap file from the ClientBin silverlight folder. After fiddling around for half an hour or so I eventually remembered to run aspnet_regiis.exe -i to reregister the current .net framework. This solved the problem immediately.
Even if this tool is located in "%windir%\Microsoft.NET\Framework\v2.0.50727" it seems to reregister the newest installed framework (in my case .NET 3.5 and Silverlight).

A similar problem can occur for WCF services with the .svc extension. In this case you need to run ServiceModelReg.exe -i again. This tool is located in "%windir%\Microsoft.NET\Framework\v3.0\Windows Communication Foundation"

My recent transformation from hating code generators to loving them

2009-09-30T18:52:00.002+02:00

For a long time now I believed that code generators were evil. When I discussed this topic I mainly gave these reasons:

a strong believe that you could pack every code into a class and just use it from there
a chapter from The Pragmatic Programmer I wrongly remembered as "Beware of evil code wizards"
bad experience with MFC Wizards(VS 4.2) for database based data entry / viewing dialogs

It didn't came to my mind until now that I was already using code generators everyday:

Automatically add using references when typing still unreferenced types
Using Resharper's Complete Code to insert delegates or create method stubs
using Resharper's Live Templates to insert unit testing stubs

Perhaps they were so small and convenient that I didn't recognize them as code generators. Lateley I had to do a lot of WCF programming. First I totally rejected the recommended way of using Web References because they generated tons of code I didn't understand. I wanted to do it like Juval Löwy, that means

refactor all contracts into a ServiceContract dll
reference this dll from the server and the client
let the client use a ChannelFactory to create a proxy on the fly from the service interface

This was an elegant and easy to understand solution. Additionaly I would got compiler errors if I changed an interface and forgot to change the client. This is absolutely necessary if you use Continous Integration. Then I needed to think more and more about cross cutting concerns with WCF proxies like

retrying failed service calls
authentication
central exception handling

Some of these things cannot be simply refactored into another class and just used. Basically, often you need to wrap every method into a try-catch block or do some common initialization. You have to do the same thing over and over again, and if every member in your team has to do it also it becomes a nightmare to ensure that everyone is doing it in the same way. In parallel I needed to do some Silverlight clients for the same WCF services. This should be easy, but with Silverlight you can't reference the ServiceContract dll generated by normal .net (because it uses a different runtime version) and even worse you need to use the asnychronous communication modell, which means you need another interface with other methods. Combined with the additional needed cross cutting concerns and soon you have a very unmaintainable code base.

In this situation I started to think of a code generator that could generate proxies for silverlight and .net with allthe special cross cutting stuff from one single source. I started to develop it, and a day later I had a protypegenerating working proxies. I spent another day with integrating it into Visual Studio and the automatic build and then it was obvious to me that this was the right solution to my problems. Integrating cross cutting concerns is really simple, all the special knowledge is encapsulated inseid the proxy generator, proxies get regenerated on every automatic build with the newest proxy generator, team members just add a custom service generation step and start using the proxies. No more code reviews and no more search and replace through the whole code base if a cross cutting concern changes.

After this experience I have now reread the chapter about evil wizards and learned that my understanding mutated over the years. Actually the pragamatic programmer encourages you to build code generators to automate repetive tasks. The evil is not the code generation itself. The evil is, that you get code that you don't understandand that you must modify it, because it is like a framework. After a modification you cannot regenerateit without loosing your modifications.

Having this remembered and extended my understanding I can now happily say that generating code from file A to file B in a repeatable way is always safe. Its just like a compiler for a DSL stored in file A. Just don't modify B. Creating method stubs or unit test hull is also safe, even if you need to modify them, because they are small and understandable. But keep aware of run-once-wizards which generate complex application frameworks that you don't understand.

Eintrag Eins

2009-09-18T15:10:00.004+02:00

So, nun versuche ich mich auch mal als Blogger. Ich möchte hier Dinge aufschreiben die ich mit Mühe herausgefunden habe und die ich irgendwann einmal via google wiederfinden möchte. Manchmal brauche ich nämlich Jahre später Sachen die ich bereits gelöst wurden, aber oft vergesse ich all die vielen Probleme, die ich nur einmal gelöst habe ;-) . Ich habe es mir zur Gewohnheit gemacht vor jedem Problem *immer* zu googeln, um zu schauen ob vielleicht jemand anderes das gleiche oder ein ähnliche Problem gelöst hat. Und wenn meine Gedanken und Ideen für Google sichtbar sind, brauche ich nur einmal suchen :-) Ein Frage stellt sich mir noch, schreibe ich lieber in Englisch oder in Deutsch? Deutsch geht deutlich flüssiger, aber bei vielen technischen Problemen sucht man eh nach den englischen Keywords. Dann werde ich die Beitrage am besten gleich in Englisch schreiben.