Der letzte Beitrag hat die grundsätzliche Motivation adressiert, die Microsoft Extensions einzusetzen – und zwar insbesondere auch, wenn man das klassische .NET Framework weiter nutzen will. Die Bereitstellung von Konfiguration ist dafür ein sehr gelungenes Beispiel: Microsoft Extensions Configuration ist – meiner Meinung nach – dem klassischen System.Configuration in jeder Beziehung vorzuziehen. Von System.Configuration …

Im Artikel Quo Vadis, .NET? habe ich auf die Microsoft Extensions hingewiesen und darauf, dass diese auch mit klassischen .NET Framework-Anwendungen nutzbar sind. Allerdings stellt sich die Frage, warum man das tun sollte. In diesem Beitrag möchte ich genau diese Frage beantworten. Die Rolle der Microsoft Extensions Das klassische .NET Framework stellt dem Anwendungsentwickler mit

Microsoft krempelt die .NET-Welt gerade kräftig um. Neue Begriffe, die man noch nicht einordnen kann, Gerüchte um Abkündigungen (die nicht zutreffen!), und die Frage, was das alles konkret bedeutet, sind die logische Folge. Um zu verstehen, was da gerade passiert – und warum – lohnt sich ein Blick in die Vergangenheit. Blick in die Vergangenheit

Microsoft hat es auf der Build angekündigt: Die Weiterentwicklung von .NET findet in .NET Core statt: There will be just one .NET going forward, and you will be able to use it to target Windows, Linux, macOS, iOS, Android, tvOS, watchOS and WebAssembly and more. (link) (Quelle: Microsoft) Die nächste Version wird .NET 5 heißen

Azure Functions sind ein ideales Mittel, um asynchron ausgeführte Hintergrundverarbeitung, Batchverarbeitungen, klassische CRON-Jobs und ähnliches in Azure umzusetzen. Sie bieten flexible Trigger, ein einfaches Programmiermodell, sowie skalierbaren und kosteneffizienten Betrieb und Monitoring über AppInsight. Oder wie es Microsoft formuliert: Mit Functions von serverlosem Computing profitieren. Erstellen Sie Ihre Apps ganz einfach mit simplen, serverlosen Funktionen,