I recently spent several hours debugging a very strange startup problem with an application I was developing, and the root cause was so wacky I just had to blog about it.
I have been spending a lot more time lately working in Linux environments, which has afforded me with an opportunity to learn more about the Bourne Again Shell and it’s scripting environment. One thing I found somewhat tedious and difficult to figure out was how to effectively do BASH error handling in shell scripts. I’ve summarized several gotchas I encountered as well as several patterns that seem to work quite well.
If you know anything about MSBuild, you know that knowing the order of evaluation for properties, items and such is critical. But how does the order of evaluation work when chaining control to other scripts using the
Visual Studio has shipped with built-in Intellisense support for MSBuild for several years, however anyone who has used either of the two commonly used add-on packs (the Community Tasks and the Extension Pack) has undoubtedly noticed that these custom tasks are not natively supported. Further, anyone who has gone digging will notice that these projects either explicitly do not support intellisense or simply do not make it obvious how to set it up. As such I have taken the liberty of doing the leg work needed to get these working and decided to make my findings public on todays post.
One habit that nearly every talented software developer I have had the privilege of working with has mastered is the use of code snippets. Read on to find out why I think that is and to discover some tips for using them effectively.
So, like most build masters, you likely have a background in programming and as such are trained to make all your machines work as efficiently as possible. The problem with applying that same level of thinking to your role as build master is that much of your work now involves working with people. Read on to find out why people who try to be efficient build masters tend not to be as effective as you think…
Todays batch file gotcha applies equally well to DOS commands in general, but if you think you understand how basic wildcard substitution is performed you may want to read on about this subtle gotcha…
When multiple DOS commands are to be executed together, say in a loop or in a conditional block, they are wrapped in round brackets. But this subtle gotcha has caused me many head-scratching sessions in front of my text editor…
Look at the following two statements: <Message Text=”Value = ‘@(SourceFiles)”/> and <Message Text=”Value = ‘@(SourceFiles)” Condition=”%(SourceFiles.identity)!=””/>? If you don’t know why these two statements give different outputs then you need to read on.
So you’ve built your awesome product which is designed to target several platforms. This may be as simple as supporting several versions of Windows (XP, Vista and 7, say) or as complex as supporting Linux, Windows, Mac and maybe even an Android flavor, on both 32 and 64 bit environments. Now, being a good developer you have been diligent in writing your unit tests, using good coding practices including clean version control patterns and all. Then you are now tasked with setting up automation for this product – what do you do? You will soon discover that scaling your automated testing is not as simple as you first thought. (more…)