DevTree on Marko Apfel

Be careful when Git suppresses bin Folders

Fri, 05 Oct 2012 08:12:00 +0200

Initial situation

Often for Visual Studio projects the typical content of a .gitignore file contains this line

bin or
[B|b]in

It is used to avoid that Git tries to track compile outputs as repository relevant data.

Installing of SDKs, Visual Studio and additional toolsets on build machines

Mon, 05 Dec 2011 15:07:00 +0100

Last week I get the information directly from Microsoft, that at build machines SDKs must be installed to guarantee that MSBuild works well in some circumstances.

We have the problem, that a self-containing build should include all necessary build artifacts – particularly Silverlight stuff. I tried to encapsulate the special steps in own targets and a build was finally possible (see my former posts). But at local machines without installed Silverlight stuff it gives problems for problems. Because reason of time finally I decide to go the Microsoft way – they break my volition.

Toolset agnostic build server and Silverlight projects

Thu, 10 Nov 2011 22:42:00 +0100

Problem

Normally I try to have my continuous integration as most a possible toolset free to ensure that no local stuff could have an impact to my build.

My Silverlight app references a special compile target in a folder outside my developer tree:

Running StyleCop without an installation to empower continuous integration

Mon, 07 Nov 2011 22:32:00 +0100

Problem

A continuous integration server should only have a minimal toolset installed. This ensures that no unwanted libraries could affect the build and other steps.

Clearly that with this slogan also StyleCop should not be installed to the CI server. But we wanna have this analysis as an part of the whole build.

Using NuGet in a MSBuild-target to have the packages at the last stand

Wed, 06 Jul 2011 18:15:00 +0200

Motivation

Encouraged from the article “Using NuGet without committing packages to source control” I decided to wrap the NuGet-call in a MSBuild target instead of using a pre-build event.

Because we also trigger FxCop and StyleCop via targets this fits better in our project management.

About trials, spikes, samples, prototypes and clean code

Mon, 04 Jul 2011 14:38:00 +0200

Writing clean code is only possible if you are known with the uses technology. Often during a development process this level must initially be reached.

To distinguish the levels of understanding I guess separate folders under the DevTree:

Whitepaper “Aufbau eines pragmatisch smarten DevTree“

Wed, 15 Jun 2011 11:46:00 +0200

Motivation

Kommen Ihnen diese Szenarien bekannt vor:

der Build scheitert, weil ein Kollege ein 3rd Party Framework eingeführt hat und nur lokal auf seiner Maschine die benötigten Bibliotheken installiert sind
der Build scheitert weil ein 3rd Party Framework auf einigen Maschinen in anderen Versionen vorhanden ist und sich damit die Datei-Versionen und -Funktionalitäten der Bibliotheken unterscheiden
das Build-Ergebnis unterscheidet sich auf verschiedenen Maschinen weil jeweils andere Toolsets in die kompilierende Umgebung eingebunden sind (Code-Weaver und -Analysierer, die als Plugin in Visual Studio installiert sind)
die benötigten Fragmente für ein aktuell benötigtes MSI-Setup (z.B. PDF-Dokumentationen) liegen in der Verantwortlichkeit eines Kollegen, der diese Dateien auf seinem Laptop hat, mit welchem er gerade unterwegs ist
nach der Inbetriebnahme einer neuen Maschine sind stundenlange Installationsopern notwendig um wieder am Projekt mitarbeiten zu können
die ausgerollte Software läuft beim Kunden nicht, weil Bibliotheken in der Applikation referenziert wurde, welche nicht im Standard-Installationsumfang beim Kunden sind

Root Cause Analysis

Was ist der Grund all dieser und verwandter Probleme?