Be( a)ware of String.Replace method

If you're using String.Replace method, you will encounter an ArgumentException if oldValue is null or empty.

This may be annoying if you don't check the old value or don't trap this exception.

A radical workaround would be to introduce a little overload with your own static method or by extending the System.String class with a "safe" method like :

/// <summary>
/// Extensions for System.String class
/// </summary>
public static class StringExtensions
{
    /// <summary>
    /// Safely replace all occurrences of specified System.String instance, with another System.String instance
    /// </summary>
    public static string SafeReplace(this string extendedString, string oldValue, string newValue)
    {
        if (string.IsNullOrEmpty(oldValue))
        {
            return extendedString;
        }

        return extendedString.Replace(oldValue, newValue);
    }
}

CodeProject

Per developer configuration files (Visual Studio)

Configuration files (such as app.config, web.config, etc.) are very convenient, but it's a real pain to manage them in a collaborative environnement.

Although Microsoft introduced web.config transforms in Visual Studio 2010, it suffers (stop me if I'm wrong) from several limitations :
- it don't permit to make per developer web.config
- it only works for web.config (a workaround exists for app.config)

In my case (a team with a dozen of .NET developers on several ASP.NET projects, with Visual Studio 2005 and SVN as source control) who is probably next to yours, each developer was changing it's configuration files with it's own values (connection string, debug mode, etc.) and was periodicaly commiting it's changes, making other developers loose their values or have conflicts while updating (XML are badly merged with SVN)

I solved this problem by using NANT (http://nant.sourceforge.net) in all our .NET projects (Visual Studio 2005), basically :

1) genuine configuration files (such as web.config in an ASP.NET project) are moved as templates in a subfolder.

2) hard coded values must be remplaced with ${your_property} properties

3) genuine configuration files must be ignored in your source control server

4) each developer should create his property file (whose name must include at least the current Windows username), with customized values for ${your_property} properties

5) a NANT's build file must be created, it's aim is to load the current Windows username property file, then copy the templated configuration files to their genuine place (properties must be extended)

6) NANT must be triggered during the Visual Studio's pre-build event, to execute the build file

That's all folk, now each developer can manage it's own property file (who can be/must stored in your source cotrol server) independently of the machine he's logged (as long as the Windows username is the same of course !)

Depending of your needs, you can extend this principle with the machine name, the current configuration, etc.

Check out the full featured article on CodeProject.

You can either contact me if you want more informations.

How to merge your dotnet assemblies

For deployment purpose, you may want to merge your dotnet assemblies.

Microsoft provides ILMerge to do such thing !

Although this tool is very usefull, it's also pretty raw, so you may use a GUI wrapper such as ILMergeGui.

To finish this article, and because a good developper is a lazy developper, I warmly recommand to use NAnt in post-build generation event to automate the merge.

Happy merging !

Integration of MediaWiki for (but not only for) technical documentation

After being intronized Manager of Research & Development about two years ago, one of my first projects was to set up a set of technical documentation (in Microsoft Word format) to define rules to be followed by the .NET (and VBA) development team.

A documentation for CSharp rules, one other for ASP.NET applications, yet another for the rules database objects...

Now, although it is more and more complete, it is also more and more heavy and cumbersome, and finally less and less read (so followed) by the team, despite the code reviews and regular reminders.

Following a discussion with my brother (who is a talented developer much closer to open-source world than me), we talked about MediaWiki, which made me want to try to use it in order to centralize all our documents into a single repository easily reachable by all the team.

Article after article, link after link, we get quickly to the game. After only two weeks, much of our documentation is already migrated, a lot of new articles have quickly emerged, and this new tool is now interesting for everyone: the development team (and managers) can now quickly find the information they need to work properly, rules are now better followed.

As for the collaborative aspect, we currently limited editing to management, but we plan to allow each developer to contribute to the documentation with the establishment of moderation.

Back to the Blog

After two years of inactivity on this blog and on professional social networks for various reasons, I again want to take the time to share about the infinite world of development.

My posts will focus on Dot Net (especially CSharp, ASP.NET), technical architecture, object-oriented programming, relational databases, and many other things in which I was able to specialize in particular data persistence.

But also on my daily life and issues related to coaching a development team, and why no articles posted from time to time on CodeProject.