.
Anmeldung | Registrieren | Hilfe

.NET-Blogs Archiv Oktober 2015

Localization mit ASP.NET 5

27.10.2015 01:21:00 | Jürgen Gutsch

Seit der Beta 8 wird Localization richtig unterstützt. Mit diesem Beitrag möchte ich Zeigen, wie man die Localization einsetzen kann.

Konfigurieren

Die Konfiguration findet wie üblich in der startup.cs statt. In der Methode Configure fügen wir eine neue Middleware ein:

app.UseRequestLocalization();

Diese Middleware setzt die Thread Culture für den aktuellen Request. Wie die Culture gesetzt wird, beschreiben die RequestLocalizationOptions die optional als Argument übergeben werden können. In den meisten Fällen werden die Options wohl nicht nötig sein. Wer aber die Steuerung der Cultures selbst übernehmen möchte kann das machen, indem die RequestLocalizationOptions angepasst werden:

Die Eigenschaft DefaultRequestCulture legt die Standard-RequestCulture. Die RequestCulture ist eine Kombination aus Culture und UICulture. Werden die Cultures nicht gesetzt, wird System.Globalization.CultureInfo.DefaultThreadCurrentCulture, bzw. System.Globalization.CultureInfo.DefaultThreadCurrentUICulture gesetzt

Die Eigenschaften SupportedCultures und SupportedUICultures definieren eine Liste mit unterstützten Cultures. SInd die Listen leer, wird die DefaultRequestCulture als einziger Eintrag gesetzt. Sind die Listen ‘null’, werden alle Cultures unterstützt.

Die interessanteste Eigenschaft ist die List der RequestCultureProviders. Die Provider ermitteln die aktuelle Culture. Das wird die Stelle sein, wo wohl am ehesten eingegriffen werden müsste. Standardmäßig sind drei Provider aktiv:

  • QueryStringRequestCultureProvider
    Ermittelt die Culture aus einem QueryString-Parameter
    Die standard Query-Variablen sind “culture” und “ui-culture”
    z. B: &culture=en-US&ui-culture=de-DE
  • CookieRequestCultureProvider
    Ermittelt die Culture aus einem Cookie
    Der Cookie-Name lautet: ASPNET_CULTURE und die Werte des Cookies sind mit der Pipe (|) getrennt, wie folgt angegeben “c=” für die Culture und “uic=” für die UICulture:
    z. B: c=en-US|uic=de-DE
  • AcceptLanguageHeaderRequestCultureProvider
    Ermittelt die Sprache aus den Browsereinstellungen die per AcceptLanguage-Header vom Browser mitgesendet werden.

An dieser Stelle kann theoretisch ein eigener RequestCultureProvider eingehängt werden. Z. B: einer der die Cultures aus einer Konfiguration oder aus der Datenbank holt. Dabei gewinnt der erste Provider der einen Wert liefert.

In der folgenden Reihenfolge werden nun die Cultures ermittelt:

  1. Vom Query String
  2. Vom Cookie
  3. Vom AcceptLanguage-Header
  4. Von der DefaultRequestCulture aus den Options
  5. Von der aktuellen Thread Culture

Services einbinden

Jetzt muss die Localization noch bekannt gemacht werden. Dafür müssen wir in der Methode ConfigureServices die nötigen Services registrieren und diesen mitteilen wo die Resource-Files gefunden werden können:

// Add Localization to the services container.
services.AddLocalization(x => x.ResourcesPath = "Resources");

// Add MVC services to the services container.
services.AddMvc()
    .AddViewLocalization(x => x.ResourcesPath = "Resources");

Die Angabe des ResourcePath in den Methoden AddLocalization() und AddViewLocalization() ist optional, allerdings tut das in der aktuellen Beta 8 noch nicht fehlerfrei.

Implementation 

Das war es dann auch schon. Wir können nun pro View und pro Controller eine Resource-Datei erstellen. Dabei gilt die Konvention, dass die Resource-Datei wie die View oder wie der Controller zu heißen hat.

In der View wird nun der IViewLocalizer injiziert, der die Resource anhand des ViewNamens ermittelt:

using Microsoft.AspNet.Mvc.Localization
@inject IViewLocalizer Localizer

<p>@Localizer["MyLocalizedKey"]</p>

Im Controller nutzen wir den generischen IHtmlLocalizer den wir ebenfalls per IoC erhalten

public class HomeController : Controller
{
    private readonly IHtmlLocalizer<HomeController> _localizer;

    public HomeController(IHtmlLocalizer<HomeController> localizer)
    {
        _localizer = localizer;
    }

    public IActionResult About()
    {
        ViewData["Message"] = _localizer["AboutMessage"];

        return View();
    }
}

Für die DataAnnotations geben wir wie gewohnt die Resource-Eigenschaften ErrorMessageResourceName und ErrorMessageResourceType in den jeweiligen Attributen an.

[Required(
        ErrorMessageResourceName = "RequiredName",
        ErrorMessageResourceType = "MyAwesomeResources")]
public string Name { get; set; }

Fazit

Im Prinzip funktioniert die Localization recht gut, allerdings nicht, wenn das Web mit dem Visual Studio über den IIS Express gestartet wird. Das ist ein bekannter Bug, der wohl das Visual Studio Tooling für ASP.NET 5 betrifft. Benutze ich dagegen Kestrel als Host, funktioniert die Localization wunderbar. 

Was man noch beachten sollte:
Die Resources für die Views müssen – anders als angekündigt – nicht heißen wie die View, sondern wie der komplette Pfad zur View. Wenn also eine View unter Views/Home/About.cshtml liegt, so muss die Resource-Datei die Namen Views.Home.About.cshtml.de-DE.resx (den entsprechenden anderen Culture-Name für die jeweilige andere Sprahe natürlich) Diese Namenskonvention scheint nicht wirklich intuitiv zu sein.

ASP.NET 5 Konfiguration

21.10.2015 19:59:00 | Jürgen Gutsch

Wie inzwischen bekannt sein dürfte, ist im ASP.NET 5 die alte Web.Config verschwunden. Diese wird durch ein viel flexiblere Art der Konfiguration ersetzt. Ein Teil der Konfig ist in die project.json gewandert. Die eigentliche Konfiguration der Applikation über AppSettings oder auch für die ConnectionStrings, wandert im neuen Visual Studio Template in die appsettings.json.

Dabei fällt wieder mal auf, dass es sich hauptsächlich um JSON basierte Konfiguration handelt, die bei ASP.NET 5 zum Einsatz kommt. Standardmäßig werden aber mehr Arten der Konfiguration angeboten. Neben der erwähnten JSON-Konfiguration, gibt es die Möglichkeit INI-Dateien einzulesen, Kommandozeilen-Parameter und Umgebungsvariablen einzulesen, oder ganz einfach ein Dictionary (genauer: ein IEnumerable<KeyValuePair<String, String>>) im C# Code zu übergeben.

Da es nun mehrere Varianten gibt, muss auch die Konfiguration konfiguriert werden. ;)

Genau das passiert im Constructor der Startup.cs, in der schon die appsettings.json und der BasisPfad eingelesen werden:

var builder = new ConfigurationBuilder()
                 .SetBasePath(appEnv.ApplicationBasePath)
                 .AddJsonFile("appsettings.json");
// … 
Configuration = builder.Build(); 

Die Methoden AddIniFile(), AddCommandline() und AddInMemmoryCollection können hier analog zu AddJsonFile angehängt werden.

Ist alles konfiguriert, geht es nun darum an die konfigurierten Daten zu kommen.

Schauen wir uns mal eine kleine appsettings.json mit folgendem Inhalt an:

{
  "ApplicationConfiguration": {
    "SiteName": "Configuration Demo",
    "SiteColor""#0000FF",
    “ArticlesPerPage”: 10
  }
}

Wir sehen hier einen Knoten (ojeh, ich nutze immer noch die alten XML-Begriffe) mit der Bezeichnung “ApplicationConfiguration“, sowie die darunter legenden Elemente “SiteName”, “SiteColor” und “ArticlesPerPage”. Die Bezeichner sind hier völlig beliebig

Um an die Daten zu kommen, könnten wir nun auf das oben erstellte Objekt Configuration zugreifen und wie in einem KeyValue Liste auslesen:

var siteName = Configuration["ApplicationConfiguration:SiteName"];

Dabei bilden alle übergeordneten Bezeichner, bis zum gewünschten Element, den Pfad zum gewünschten Inhalt. Ähnlich wie sich mit XPath verhält. Der Komplette Pfad, mit Doppelpunkt als Trenner, wird als Key angegeben. Das Resultat ist ein String.

Damit das Applikationsweit funktioniert, müsste das Objekt Configuration als Service registriert werden:

services.AddInstance<IConfigurationRoot>(Configuration);   

Allerdings ist das keine sehr elegante Methode und die Registrierung der Configuration als Service wäre ganz sicher schon als Standard von Microsoft umgesetzt. Besser ist es die Konfiguration typisiert ein ein eigenes Konfig-Objekt einzulesen:

Der Bereich mit dem Namen “ApplicationConfiguration” wird als Configuration Section gesehen, wie wir es noch aus der Web.config kennen. Diese Sections können explizit ausgelesen werden und einem eigenen Objekt zugewiesen werden:

services.Configure<ApplicationConfiguration>(
    Configuration.GetSection("ApplicationConfiguration"));

Der Typ zum zugehörigen JSON:

public class ApplicationConfiguration
{
    public string SiteName { get; set; }
    public string SiteColor { get; set; }
    public int ArticlesPerPage { get; set; }
}

Dabei ist zu beachten, dass der Name der Klasse und auch die Namen der EIgenschaften, den Bezeichnern im JSON entsprechen

Diese ApplicationConfiguration ist dann sehr einfach – und bereits vorkonfiguriert – über das IoC überall zugreifbar. z. B: auch in den Views:

@using Microsoft.Framework.OptionsModel
@using WebApplication6.Configuration
@inject IOptions<ApplicationConfiguration> Config

<title>@Config.Options.SiteName</title>

Oder in jeder per IoC instanziierten Klasse im ASP.NET 5 Projekt:

public class HomeController : Controller
{
    private readonly IOptions<ApplicationConfiguration> _configuration;

    public HomeController(IOptions<ApplicationConfiguration> configuration)
    {
        _configuration = configuration;
    }

    public IActionResult Index()
    {
        var siteName = _configuration.Options.SiteName;

        return View();
    }
}

Oben haben wir gesehen, wie sowohl eine JSON Datei eingelesen wird, als auch Umgebungsvariablen. Es lassen sich auch weitere JSON Dateien mit einlesen. Diese können sowohl unterschiedliche Sections enthalten, also auch identische. Die zuletzt eingebundenen Konfigurationen überschreiben dabei die vorigen, wenn es identische Angaben gibt. Das kann z. B: genutzt werden, um eine Standardkonfiguration bei Bedarf zu überschrieben.

Unterschiedliche Konfiguration per Deployment-Umgebung

Nehmen wir einmal an, wir möchten unterschiedliche Konfigurationen für verschiedene Deployment-Umgebungen automatisiert hinterlegen, um z. B: ConnectionStrings, oder was auch immer, unterschiedliche zu Konfigurieren. Bisher musste man dafür entweder die Settings im Deployment-Prozess umschreiben, oder die Web.Config Tranformation nutzen. Mit ASP.NET 5 lässt sich das viel einfacher Lösen. Dabei können wir die vorhandene Umgebungsvariable ASPNET_ENV nutzen, die standardmäßig immer eingelesen wird. Diese steht unter IEnvironment.EnvironmentName mit den Werten “Development”, “Staging” und “Production” zur Verfügung. (Sie kann theoretisch auch andere Werte enthalten die vom ASP.NET 5 Intern halt nicht berücksichtigt werden.)

Möchten wir nun also eine Datei namens “appsettings.Development.json” einlesen sieht der Konstruktor der Startup-Klasse nun so aus:

public Startup(IHostingEnvironment env, IApplicationEnviroNun nment appEnv)
{
    // Setup configuration sources.
    var builder = new ConfigurationBuilder(appEnv.ApplicationBasePath)
        .AddJsonFile("appsettings.json")
        .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true);
    Configuration = builder.Build();
}

Per String-Interpolation geben wir den EnvironmentName in de Namen der angefragten JSON-Datei rein und können nun je nach Umgebung verschiedene Konfig-Dateien laden, die vom Deployment-Prozess in das Projektverzeichnis gelegt werden. Der zweite optionale Parameter “optional” gibt an, ob die Datei vorhandenen sein muss oder nicht. So könnte die Datei in der Produktiv-Umgebung weggelassen werden, um die Grundkonfiguration zu nutzen. Auf diese Art können wir also die Konfiguration für die jeweilige Deployment-Umgebung überschreiben oder ergänzen.

Ohne Umgebungsvariablen

Sollte es aus irgendeinem Grund nicht möglich sein, eine Umgebungsvariable in den Zielumgebungen zu setzen. So schafft dieser Blog Beitrag Abhilfe. Er erklärt hier wie man eine JSON-Konfig als Grundkonfiguration nutzen kann, um die Ziel-Umgebungen einzustellen, damit mit diesen Daten die eigentliche Konfiguration geladen werden kann.

XML Konfiguration

Oben habe ich mit keinem Wort die XML Konfiguration erwähnt. Die gibt es natürlich immer noch, allerdings muss sie separat per NuGet Package eingebunden werden:

"Microsoft.Framework.Configuration.Xml": "1.0.0-beta7"

Nun sollte analog zur JSON auch die Methode AddXmlFile() zur Verfügung stehen. Diese Funktioniert genauso wie die AddJsonFile() Methode.

Weitere Informationen

Strongly typed AppSettings Configuration in ASP.NET 5

Neu in ASP.NET 5 Beta 8

19.10.2015 00:31:00 | Jürgen Gutsch

Letzte Woche habe ich in den .NET Usergroups Bern und Friedrichshafen noch die Beta 7 gezeigt und dann erscheint die Beta 8 mit einigen interessanten Änderungen und Neuerungen.

Kestrel überall

Es wurde angekündigt, dass Kestrel ASP.NET 5 Webs auch im IIS hosten soll. Nun ersetzt Kestrel auch im neuen Visual Studio Projekt den WebListener als Hosting umgebung. Das Kommando “web” verweist jetzt auf Kestrel. Der WebListener bleibt uns erhalten, ist aber nicht mehr standardmäßig eingebunden.

image

Im IIS sorgt der HttpPlattformHandler (ein natives Plugin für den IIS) jetzt dafür, dass die Anfragen direkt an Kestrel weitergegeben werden. Der HttpPlattformHandler muss auf den IIS installiert werden, wenn ASP.NET 5 Webs gehostet werden sollen. Für Entwickler ist das Plugin bereits im Beta8 Web Tools Update enthalten.

Für bestehende Webs und klassische ASP.NET Projekte muss nichts angepasst werden. Diese laufen wir gewohnt. Der HttpPlattformHandler wird über eine web.config configuriert die im Verzeichnis “wwwroot” liegt.

Konfiguration überall

Eine kleine Änderung, die aus Sicht von ASP.NET Entwicklern Sinn macht: Die “config.json” wurde umbenannt und heißt jetzt “appsettings.json”. Kein großes Ding, macht es aber klassischen ASP.NET Entwicklern möglicherweise etwas einfacher sich zu orientieren.

image

(Mehr zur Konfiguration in einem der nächsten Beiträge)

Localization überall

Neu wird auch Localization jetzt richtig unterstützt. Ein Thema dem ich mich in einem separaten Blog-Beitrag intensiver widmen werden. Eine neue Middleware sorgt dafür dass die richtige Culture für den aktuellen Request gesetzt wird. Weiterhin lassen sich Services registrieren, welche die Localization in der Applikation Verfügbar macht.

NuGet überall

Die Benutzung von NuGet wurde ebenfalls etwas überarbeitet. So wird nun ein Feedback angezeigt, wenn die Packages restored werden und die Icons wurde redesigned. Auch die Anzeige von Referenz-Fehlern im Soution Explorer und in der project.json wurde verbessert. Lauter Kleinkram, im Vergleich zu folgender Änderung: Wie wir wissen, kann eine ASP.NET 5 Applikation (wie alle DNX–Apps) in ein NuGet-Package deployed werden. Jetzt ist es endlich möglich für eben dieses Package explizit Abhängigkeiten festzulegen und zusätzliche Dateien zu definieren die im Package enthalten sein sollen.

image

Weitere Änderungen:

Etwas detaillierter und noch ein paar weitere Neuigkeiten zu Beta8 ist in der offiziellen Ankündigung zu lesen: Announcing Availability of ASP.NET 5 Beta8

Softwareevolution – eine Übersicht

12.10.2015 11:08:49 | Hendrik Loesch

Für die Basta habe ich ein Plakat erstellt um eine Übersicht zum Thema Software Evolution zu geben. Dessen Inhalt möchte ich nun auch hier zur Verfügung stellen, da das Thema sicher eine ganze Reihe von Personen interessieren dürfte. Wie in Abbildung 1 gezeigt, unterteilt sich der Lebenszyklus eines komplexen Softwaresystems in mehrere Phasen. Häufig wird […]

DevOps Hackathon mit Chef am 28 Oktober in Berlin

10.10.2015 09:19:49 | Christian Binder

DevOps-LinkedInGeneric-580x300banner-Template

DevOps HandsOn in Berlin in Zusammenarbeit mit Chef - Alle Details findet Ihr unter: www.aka.ms/devopsberlin

Authorization Policies in ASP.NET 5 Middlewares

07.10.2015 00:02:02 | Jürgen Gutsch

Um auch selektiv statische Dateien im Ordner “wwwroot” vor unautorisiertem Zugriff zu schützen, kann man den Weg über eine sog. Authorization Policy gehen. Die Policy wird dann in einer eigenen Middleware genutzt, welche die eigentliche Zugriffsprüfung vornimmt.

Wie das konkret aussieht schreibt K. Scott Allen sehr ausführlich in seinem aktuellen Blogpost: Authorization Policies and Middleware in ASP.NET 5

Generell sind Authorization Policies eine elegante Art der Autorisierungsprüfung in eigenen Middlewares. Dabei lassen sich beliebig viele Policies hinzufügen, die wiederum an beliebigen Stellen geprüft werden können.

52 Tipps zur .NET Performance Analyse

02.10.2015 09:30:22 | Andre Kraemer

Wie bekomme ich meine Anwendung schneller? Diese Frage stellen mir viele meiner Kunden, die mich zu einer Performanceanalyse Ihrer .NET Anwendung einladen. Natürlich lässt sich eine solche Frage nicht pauschal beantworten. In der Regel hilft nur ein gezieltes Profiling der Anwendung. Trotzdem gibt es einige Best Practices, deren Einhaltung bereits enorm zur Steigerung der Anwendungsperformance führen können. 52 Tips and Tricks to boost NET Performance Book Cover

52 solcher Performance Tipps hat das Team von Red-Gate gesammelt. Dazu wurden Performance Experten aus der ganzen Welt gebeten ihre besten Tipps beizusteuern. Das Ergebnis ist ein kleines E-Book, zu dem ich auch zwei Tipps beitragen durfte.

Das Buch ist in die folgenden Bereiche gegliedert:

  • Allgemeine Performance Ratschläge
  • .NET Performance Verbesserungen
  • ASP.NET Performance Tipps
  • Tipps zum Datenzugriff
  • Speicheroptimierung
  • Generelle Tipps

Meine Tipps beziehen sich auf den Datenzugriff mit dem Entity Framework. Ein Problem, welches ich häufig beobachte besteht darin, dass Daten unnötig mit aktiviertem Change Tracking geladen werden. Change Tracking ist ein Mechanismus, der dafür sorgt, dass das Entity Framework über eine Veränderung der Daten einer Entität informiert wird. Über diesen Weg reicht später ein einfacher Aufruf der Methode SaveChanges am DBContext, um alle Änderungen automatisch zu sichern.

Häufig ist jedoch bereits beim Laden klar, dass die Daten nicht verändert werden. Nutzt man nun jedoch den Standardweg des Entity Framwork 6, wie ihn folgender Code zeigt, werden die Daten automatisch mit aktiviertem Change Tracking abgerufen.

using (var db = new NorthwindDb())
{
    var shippers = db.Shippers.ToList();
    foreach (var shipper in shippers)
    {
        Console.WriteLine("{0} - {1}", shipper.ShipperID, shipper.CompanyName);
    }
}

Die Lösung des Problems ist relativ einfach. Ein Aufruf der Erweiterungsmethode AsNoTracking() deaktiviert das Change-Tracking für die über diesen Weg geladenen Entitäten.

using (var db = new NorthwindDb())
{
    var shippers = db.Shippers.AsNoTracking()ToList();
    foreach (var shipper in shippers)
    {
        Console.WriteLine("{0} - {1}", shipper.ShipperID, shipper.CompanyName);
    }
}

Die Frage ist nun natürlich: Was bringt der Aufruf von AsNoTracking()?

In meinem Beispiel, in dem ich 10.091 Datensätze aus der Tabelle Customers der Northwind Datenbank gelesen habe, konnte ich folgende Werte messen:

Mit Change-Tracking: 10958 ms

Ohne Change Tracking: 9047 ms

Wie wir sehen, spart der Einsatz von AsNoTracking im vorliegenden Fall knapp 2 Sekunden.

Natürlich ist das immer noch nicht sonderlich schnell. Deshalb habe ich einen weiteren Tipp im E-Book veröffentlicht, der ein weiteres, häufiges Problem beim Datenzugriff mit dem Entity Framework behandelt. Wer wissen möchte wie er lautet, sollte einen Blick ins E-Book werfen :-)

Vor einiger Zeit habe ich übrigens ein kleines Video aufgezeichnet, in dem ich die generelle Vorgehensweise beim Performance Profiling mit dem ANTS Performance Profiler erkläre. Wer sich also unsicher ist, warum die eigene Anwendung zu langsam ist, der sollte hier einmal einen Blick rein werfen.

Ihr habt auch tolle Performance Tipps? Dann schreibt ihn doch in einen Kommentar zu diesem Post!

52 Tipps zur .NET Performance Analyse

02.10.2015 08:30:22 | Andre Kraemer

Wie bekomme ich meine Anwendung schneller? Diese Frage stellen mir viele meiner Kunden, die mich zu einer Performanceanalyse Ihrer .NET Anwendung einladen. Natürlich lässt sich eine solche Frage nicht pauschal beantworten. In der Regel hilft nur ein gezieltes Profiling der Anwendung. Trotzdem gibt es einige Best Practices, deren Einhaltung bereits enorm zur Steigerung der Anwendungsperformance führen können.

52 Tips and Tricks to boost NET Performance Book Cover

52 solcher Performance Tipps hat das Team von Red-Gate gesammelt. Dazu wurden Performance Experten aus der ganzen Welt gebeten ihre besten Tipps beizusteuern. Das Ergebnis ist ein kleines E-Book, zu dem ich auch zwei Tipps beitragen durfte.

Das Buch ist in die folgenden Bereiche gegliedert:

  • Allgemeine Performance Ratschläge
  • .NET Performance Verbesserungen
  • ASP.NET Performance Tipps
  • Tipps zum Datenzugriff
  • Speicheroptimierung
  • Generelle Tipps

Meine Tipps beziehen sich auf den Datenzugriff mit dem Entity Framework. Ein Problem, welches ich häufig beobachte besteht darin, dass Daten unnötig mit aktiviertem Change Tracking geladen werden. Change Tracking ist ein Mechanismus, der dafür sorgt, dass das Entity Framework über eine Veränderung der Daten einer Entität informiert wird. Über diesen Weg reicht später ein einfacher Aufruf der Methode SaveChanges am DBContext, um alle Änderungen automatisch zu sichern.

Häufig ist jedoch bereits beim Laden klar, dass die Daten nicht verändert werden. Nutzt man nun jedoch den Standardweg des Entity Framwork 6, wie ihn folgender Code zeigt, werden die Daten automatisch mit aktiviertem Change Tracking abgerufen.

using (var db = new NorthwindDb())
{
    var shippers = db.Shippers.ToList();
    foreach (var shipper in shippers)
    {
        Console.WriteLine("{0} - {1}", shipper.ShipperID, shipper.CompanyName);
    }
}

Die Lösung des Problems ist relativ einfach. Ein Aufruf der Erweiterungsmethode AsNoTracking() deaktiviert das Change-Tracking für die über diesen Weg geladenen Entitäten.

using (var db = new NorthwindDb())
{
    var shippers = db.Shippers..AsNoTracking()ToList();
    foreach (var shipper in shippers)
    {
        Console.WriteLine("{0} - {1}", shipper.ShipperID, shipper.CompanyName);
    }
}

Die Frage ist nun natürlich: Was bringt der Aufruf von AsNoTracking()?

In meinem Beispiel, in dem ich 10.091 Datensätze aus der Tabelle Customers der Northwind Datenbank gelesen habe, konnte ich folgende Werte messen:

Mit Change-Tracking: 10958 ms

Ohne Change Tracking: 9047 ms

Wie wir sehen, spart der Einsatz von AsNoTracking im vorliegenden Fall knapp 2 Sekunden.

Natürlich ist das immer noch nicht sonderlich schnell. Deshalb habe ich einen weiteren Tipp im E-Book veröffentlicht, der ein weiteres, häufiges Problem beim Datenzugriff mit dem Entity Framework behandelt. Wer wissen möchte wie er lautet, sollte einen Blick ins E-Book werfen Smiley

Vor einiger Zeit habe ich übrigens ein kleines Video aufgezeichnet, in dem ich die generelle Vorgehensweise beim Performance Profiling mit dem ANTS Performance Profiler erkläre. Wer sich also unsicher ist, warum die eigene Anwendung zu langsam ist, der sollte hier einmal einen Blick rein werfen.



Ihr habt auch tolle Performance Tipps? Dann schreibt ihn doch in einen Kommentar zu diesem Post!

Slides zu meinen Vorträgen auf der Basta! Konferenz 2015

01.10.2015 00:46:00 | Jürgen Gutsch

ASP.NET auf dem Raspberry PI und Docker

Auf der diesjährigen Basta! Konferenz durfte ich ebenfalls zeigen, wie man ASP.NET 5 auf einem Raspberry PI 2 mit Rasbian (Debian Wheezy) installiert und zum laufen bringt. Als zusätzliches Thema habe ich diesmal Docker mit in den Vortrag genommen und gezeigt, wie man ein eigenes ASP.NET 5 Projekt in einem Docker-Container startet:

http://www.slideshare.net/juergengutsch/aspnet-5-auf-raspberry-pi-docker

HTML 5 Magic

Im zweiten Vortrag ging es um die die Features aus HTML 5, die man nicht auf Anhieb in Form von HTML-Tags sehen kann. Local Storage, File API, Media Capture, Web Worker waren auch unter den Beispielen. Die sechs Folien die ich hier verlinke haben keinen wirklich relevanten Inhalt, außer den Link auf die Beispiele auf GitHub und meine Kontaktinformationen. ;)

http://www.slideshare.net/juergengutsch/html-5-magic

Der direkte Link auf die Beispiele: https://github.com/JuergenGutsch/html5magic/

Regeln | Impressum