10. Oktober 2017
Konstantin Novikov
0

Building .NET Core Applications

Preamble

.NET Core is still a new technology and people might ask themselves questions like “how applicable is it in a real- life scenario?”, “how convenient is it to set up?”, “what do I need to configure, to get a build-pipeline up and ready?”, “do I need any tools aside from the official .NET Core SDK?” … therefore I want to share my gained experience while setting up and configuring a “Microsoft-friendly” build- controller and agent scenario. It is based on the regular Microsoft technologies including Team Foundation Server 2017 and Microsoft Windows VSTS build agent, both hosted on Microsoft Windows Server 2016.

Prerequisites

Build controller
• TFS 2017
Build agent
• VSTS-Agent win-7-x64-2.112.0
• .NET Core SDK 1.0.3 for Windows

Although it is not the cheapest way to implement a .NET Core build pipeline, it is also not the most expensive one, since we are not installing any Visual Studio stuff inside the build agent. And yes you arguably could host a vsts build agent inside a linux for example but that setup will be mentioned in a seperate blogpost. Alright lets not go any further into licence and pricing discussions and jump right to the technology part.

Set-Up

First of all you need to establish a controller-agent connection so all the neat build data is captured and processed correctly. There are 4 different ways how you can do it which are explained here:
See http://go.microsoft.com/fwlink/?LinkID=825113 for more detailed information.

After you are done with that, connect to Build-Agent-Host via remote desktop and download/install the .NET Core SDK.
See https://go.microsoft.com/fwlink/?linkid=847097 for more detailed Information.

Make sure that the dotnet.exe path is added to the PATH environment variable and you can call it from the cmd/powershell.
At this point you are pretty much done with your build agent configuration and you can jump right into your TFS source controlled .NET Core project and add a default .NET Core build definition.

Build configuration

If you are using the ASP.NET Core (Preview) build template to add a build definition, then you should follow these steps below.

 

After you added the build definition modify the single tasks according to your project root structure as it is shown below. Keep in mind that all the commands are seperate tools which are composed inside the .NET Core CLI Toolchain.

The restore command is mapped to the integrated NuGet, we use the verbosity flag to display the „used nuget feeds“ information.

The build command is mapped to integrated msbuild. The $(BuildConfiguration) variable gets replaced before the actual target gets executed on the build agent. It should either be replaced by „Debug“ or „Release“.

The test command is mapped to vstest.console or to xunit.console depending on your configuration.

Notice that the test command requires an extra logger parameter in case you want to capture and print test for publishing reasons. Now you need to add the „Publish Test Results“ step and configure the path wildcards/naming in a way that it grabs the results.xml file produced by your vstest.console logger.

After you queued up and finished your build you should get a report which should look similar to the one below.

 

 

Conclusion

So at the current .NET Core SDK and TFS state, there are still minor configurations required to get your pipeline going. Regardless, the installation effort is very minimal and intuitiv in my opinion and the alternative to host a .NET application on a Linux OS instead of Windows should make a ton of people happy! So give it a try 😊.

Building .NET Core Applications and enjoy it!

 

9. Oktober 2017
Hendrik Loesch
0

DWX 2017 – 100 Leute haben wir gefragt…

Wie schon in den vergangenen Jahren war die Saxonia Systems AG auch dieses Jahr wieder bei der Developer Week (DWX 2017)  in Nürnberg vertreten. So gestalteten wir das Programm aktiv mit Vorträgen und gewährten tiefe Einblicke in unseren Arbeitsalltag, sowie unsere Leistungen.

mehr

14. November 2016
Sebastian Thurm
0

WPF-Tricks: Kontext-Menü per Behaviour

Behaviours bieten in WPF die Möglichkeit ein Stück Funktionalität in einer wiederverwendbare Komponente zu verpacken. Behaviours erlauben Anwendungsdesignern – mit wenig Aufwand – Änderungen am Programmverhalten zu bewirken ohne in den Programmcode einzugreifen. Die Entwickler stellen dafür beispielsweise Behaviours für Drag & Drop oder Touch-Interaktion bereit, die dann im „Blend“ einfach auf das entsprechende Element angewandt werden. Dieses Tutorial zeigt, wie sich mit Hilfe eines Behaviours ein Kontext-Menü erzeugen lässt.

mehr

17. Oktober 2016
Thomas Wilk
0

Swipe-Gesten in WPF

WPF als Grafik-Framework bietet dem .NET Entwickler eine Vielzahl von vorgefertigten Bedienelementen. In vielen Fällen muss man diese Bedienelemente jedoch erweitern um den Anforderungen an die Software gerecht zu werden, wie auch in diesem Fall: Ein Bildbetrachter soll um die Swipe-Gesten „Von-Rechts-nach-Links“ und „Von-Links-nach-Rechts“ erweitert werden. Die Funktionalität zum Bildwechsel ist bereits enthalten und wurde mit Pfeilen an den jeweiligen Außenkanten des Bildes für den Benutzer sichtbar gemacht.

mehr

25. Juli 2016
Marek Böttcher
0

Lokalisierung mit ASP.NET Core

Im Gegensatz zu ASP.NET Core RC1 werden ab RC2 und RTM die Lokalisierungsfeatures besser unterstützt. Es gibt bei ASP.NET Core unterschiedliche Möglichkeiten wie man die Lokalisierung (multilanguage support) einer Website hinzuzufügen kann. Ich möchte hier eine exemplarische Vorgehensweise zeigen, so wie sie in einem Projekt der Saxonia Systems AG zum Einsatz kam. Wir haben uns bei diesem Projekt für die Verwendung von Resource-Dateien (.resx) entschieden, weil damit das Lokalisierungsthema aus dem Quellcode ausgelagert wird. So kann man z.B. die einzelnen Dateien einem externen Übersetzer zum Bearbeiten geben, ohne das dafür Kenntnisse über den Quellcode benötigt werden.

mehr

23. Mai 2016
Sebastian Thurm
0

WPF-Tricks: Icons zur Laufzeit färben

Icons helfen Nutzern sich in einer Anwendungsoberfläche zurecht zu finden. Gut gemachte Icons sind schnell erfassbar und leisten damit einen wichtigen Beitrag zur intuitiven Bedienbarkeit. Sie gehören daher in jede Anwendung – können Entwickler aber auch vor unerwartete Probleme stellen.

mehr

21. Dezember 2015
Hendrik Loesch
2

Quo vadis Microsoft?

Betrachtet man was uns Technologieradare, Anbieter für Weiterbildungsmaßnahmen oder diverse Konferenzagenden zeigen, scheint es zurzeit nur die Wege „Mobile“ und „Web“ zu geben, wenn man mit einem neuen Softwareprojekt starten möchte. Dieser Einschätzung möchte ich nicht gänzlich widersprechen, unkommentiert lassen kann ich sie jedoch auch nicht.

mehr

7. Dezember 2015
Katrin Hammer
2

Gefahren durch modifizierte Cookies

Zum Ende des vierten Quartals sind wieder vermehrt Cookies im Umlauf. Wie entstehen diese und wie kann der Client damit umgehen? Gerade die modifizierten Cookies können Probleme verursachen, sowohl beim Client als auch auf dem Server. Die richtige Vorbereitung kann helfen, mit dieser Gefahr umzugehen.

mehr

9. Oktober 2015
Katrin Hammer
0

BASTA! – von Elefanten und Hamburgern

Letzte Woche fand die BASTA! 2015 in Mainz statt. Die Saxonia Systems AG war Gold Partner und mit 3 Vorträgen unserer Kollegen vertreten. Es reichte von Softwareevolution über „Was ist eigentlich Unit“ bis hin zu den Qualitätsmetriken. Speaker waren hier Hendrik Lösch, Kay Greybenstein und Martin Uhlig.

mehr

3. August 2015
Holger Zaman
0

Cordova goes MS Visual Studio

Mit Apache Cordova können Apps für verschiedene mobile Endgeräte entwickelt werden. Diese Anwendungen können auf die Funktionen des jeweiligen Endgerätes – zum Beispiel die Kamera – zugreifen, ohne dass dafür nativer Code für ein spezielles Endgerät entwickelt werden muss. Für die Implementierung von Apps mit Cordova reichen HTML, CSS und JavaScript (vgl. http://cordova.apache.org/).

mehr