.
Anmeldung | Registrieren | Hilfe

.NET-Blogs Archiv Februar 2016

Liste der Visual Studio Code Extensions und Themes - Februar 2016 Report

26.02.2016 12:17:23 | Kay Giza

Ich habe wieder eine Liste aller verfügbaren Extensions für Visual Studio Code erstellt: Stand 26.02.2016. Im Monatsvergleich zu Januar 2016 ergab sich folgende Änderungen: Über 100 neue Extensions sind dazu gekommen, was ein Plus von 29 Prozent zum Januar ausmacht. Rund 10 neue Themes sind dazu gekommen... [... Eine vollständige Liste aller VS Code Extensions in diesem Blogeintrag auf Giza-Blog.de]

This post is powered by www.Giza-Blog.de | Giza-Blog.de: RSS Feed
© Copyright 2006-2016 Kay Giza. All rights reserved. Legal

Cortana fuer Entwickler: Eigene Apps mit Cortana erweitern

23.02.2016 09:31:48 | Kay Giza

Du möchtest Unterhaltungen mit einer App führen? Fragen und Anweisungen aussprechen und der Computer antwortet auf natürliche Art und Weise? Diese Art der Kommunikation und noch vieles mehr sind Teil von echtem 'Personal Computing'. Heute am 23.02.2016 um 18.15 Uhr... [... mehr auf Giza-Blog.de]

This post is powered by www.Giza-Blog.de | Giza-Blog.de: RSS Feed
© Copyright 2006-2016 Kay Giza. All rights reserved. Legal

SourceTree und 'ssh-agent' ist fehlgeschlagen mit Code -1: System.NullReferenceException

19.02.2016 09:02:00 | Martin Hey

Seit ich Git als SCM benutze, verwende ich auch SourceTree, um mir das Ganze etwas grafischer darstellen zu lassen. Bisher war ich auch ziemlich zufrieden und glücklich damit.

Aber dann kam das Update auf Version 1.8 und es änderte sich einiges. Neben der Änderung der Nutzungsbedingungen, die zwar im Blog deutlich hervorgehoben, aber irgendwie im Installationsprozess für mich nicht ersichtlich war, trat seitdem bei jedem Start von SourceTree folgender Fehler auf:

'ssh-agent' ist fehlgeschlagen mit Code -1: System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
()
Ich brauche wohl nicht zu erwähnen, dass es mit der Vorversion problemlos ging.

Mein Lösungsweg:
a) das System-Git mal wieder auf einen aktuellen Stand bringen
und
b) im SourceTree unter Tools ⇨ Optionen ⇨ Git auf den Button "Benutze System Git" klicken

Schon werde ich wieder nach meinem Kennwort für den SSH-Key gefragt und alles läuft wie vorher.

Wie gut kennst Du dich mit Visual Studio Code aus? Jetzt TechRewards Punkte sichern!

18.02.2016 16:47:46 | Kay Giza

Wenn Du Visual Studio Code bereits im Einsatz hast oder ausprobiert hast, dann empfehle ich Dir das Microsoft TechRewards-Quiz: 'Wie gut kennst du dich mit Visual Studio Code aus?'. Das Quiz geht noch bis... [... mehr auf Giza-Blog.de]

This post is powered by www.Giza-Blog.de | Giza-Blog.de: RSS Feed
© Copyright 2006-2016 Kay Giza. All rights reserved. Legal

10 ways to extend your Razor views in ASP.​NET core - the complete overview

17.02.2016 17:00:00 | Jürgen Gutsch

Currently there are many ways to extend or to organize your Razor views in ASP.NET Core MVC. Let us start with the very basics and let us go to the more complex ways. If your are familiar with previous ASP.NET MVC Frameworks you'll definitely know most of this. But almost all of that "old" stuff is still possible in ASP.NET Core MVC. Some of them listed below shouldn't be used anymore and some of that stuff is completely new in ASP.NET Core MVC. With this post I'm going to try to write down all options to organize and extend MVC Views.

#1: Typed Views

A very basic View without any dynamic stuff is not very common. Even in Visual Studio it is not really visible, because you usually get a running per-configured web, if you start a new project. It is simply a HTML page with *.cshtml as the file extension. You can use Razor syntax, HtmlHelpers and UrlHelpers here to make your HTML code more dynamic. You can use the ViewBag Object or the ViewData collection to pass Data from your Controller action to your View. But this data are not typed and you don't really know whether the data exist in this list or what type the data are.

To use typed date in your view, you need to define a model to use in your view.

@model ExtendViews.ViewModels.AboutModel

<!-- usage: --->
@Model.FullName

This is pretty common for ASP.NET MVC developers, even the next topic is a known and pretty basic way:

#2: Layouts

Almost equal to the MasterPages in ASP.NET WebForms, there is a central way to define the basic layout of your Razor view. This is done with a _Layout.cshtml, which is located in the Views\Shared\ folder. This file usually contains the HTML header, body tags and all the things which are shared between all of your Views.

You can also nest layout views to have a basic layout and different per area on your web site. To use a Layout you need to call it by its name without the file extension:

@{
    Layout = "_Layout";
} 

This call needs to be in the first lines of your views. But you don't need to define the Layout in every view, if you already have defined a default Layout. This is already done, if you start a new ASP.NET Core project in Visual Studio. There is a _ViewStart.cshtml in the Views folder where the default Layout is set-up.

Inside the _Layout.cshtml there is a mothod callRenderBody(), which calls the rendering ov the current view at this location:

@RenderBody()

Place this method call at that location where where your view should be rendered.

#3: Sections

Sometimes you need to create HTML code in your view, which should be rendered on another location than the main parts of the view. This can be done with Sections. Sections are named areas in your view and usually used to put JavaScripts from your views in to a separate location, e.g. at the end of the page.

To define a section for some JavaScripts just call the Section you want to render somewhere in the _Layout.cshtml:

@RenderSection("scripts", required: false)

With the flag required you are able to define whether the sections is needed or optional. Now you can use the section in your view:

@section scripts
{
    <script>
        $(function() {
            // some more js code here;
        });
    </script>
}

If you use nested layouts, you probably need to nest this areas. This means you need to call the RenderSection() inside a Section:

@section scripts
{
	@RenderSection("scripts", required: false)
}

#4: PartialViews

To reuse parts of your views you can extract this parts and put it into a new Razor view. This view doesn't have an own Action in the controller. This thing is called a PartialView. A PartialView should be placed in the same folder as the View which uses the PartialView or even in the Views\Shared\ folder.

A PartialView can also be a typed view (but don't have to) to get data from the parent View:

@model IEnumerable<UserModel>
@if (Model.Any())
{
    <ul>
        @foreach (var user in Model)
        {
            <li>@user.FullName</li>
        }
    </ul>
}

This PartialView needs a list of users from the parent view

@{ await Html.RenderPartialAsync("Users", Model.Users);}

If your PartialView doesn't have a model defined, you don't need to pass the second parameter.

#5: ViewComponents

This is new in ASP.NET Core

Sometimes you need to have something like PartialView, but with some more logic behind. In the past there was a way to use ChildActions to render the results of controller actions into a view. In ASP.NET Core MVC there is a new way (which I already showed in this post about ViewCmponents) with ViewComponents. This are a kind of mini MVC inside MVC, which means they have an own Controller, with an own single action and a view. This ViewComponents are completely independent from your current view, but also can get values passed in from your view.

To render a ViewComponent you need to call it like this:

@Component.Invoke("Top10Articles");

Please have a look at my previews post about ViewComponent to learn how to create your own.

#6: HtmlHelpers

You can extend the Razor syntax by creating your own extension methods on the HtmlHelper class:

public static class HtmlHelperExtensions
{
    public static HtmlString MyOwnHtmlHelper(this HtmlHelper helper, string message)
    {
        return new HtmlString($"<span>{message}<span>");
    }
}

This is pretty useful to create reusable parts of your view, which includes some more logic than a PartialView. But even better than HtmlHelper extensions are the new TagHelpers. HtmlHelpers are still a valid option to extend your Views.

#7: TagHelper

This is pretty new in ASP.NET Core.

This little helpers are extensions of your view, which are looking like real HTML tags. In ASP.NET Core MVC you should use this TagHelpers instead of the HtmlHelpers because they are more cleaner and easier to use. Another huge benefit is Dependency Injection, which can't be used with the HtmlHelpers, because the static context of extension methods. TagHelpers are common classes where we can easily inject services via the constructor.

A pretty simple example on how a TagHelper could look like:

[TargetElement("hi")] 
public class HelloTagHelper : TagHelper 
{ 
    public override void Process(TagHelperContext context, TagHelperOutput output) 
    { 
        output.TagName = "p"; 
        output.Attributes.Add("id", context.UniqueId); 

        output.PreContent.SetContent("Hello "); 
        output.PostContent.SetContent(string.Format(", time is now: {0}",  
                DateTime.Now.ToString("HH:mm"))); 
    } 
}

This guy defines a HTML Tag called "hi" and renders a p-tag and the contents and the current Time.

Usage:

<hi>John Smith</hi>

Result:

<p>Hello John Smith, time is now: 18:55</p>

ASP.NET Core MVC provides many built in TagHelpers to replace the most used HtmlHelpers. E. g. the ActionLink can now replaced with an Anchor TagHelper:

@Html.ActionLink(“About me”, “About”, “Home”)

The new TagHelper to create a link to an action looks like this:

<a asp-controller=”Home” asp-action=”About”>About me</a>

The result in both cases is a clean a-Tag with the URL to the about page:

<a href=”/Home/About”>About me</a>

As you can see the TagHelpers feel more than HTML and they are easier to use and more readable inside the Views.

#8: Dependency Injection

This is new in ASP.NET Core too.

The biggest improvement to extend your view is dependency injection. Yes, you are able to use DI in your View. Does this really make sense? Doesn't it mess up my view and doesn't it completely break with the MVC pattern? (Questions like this are currently asked on StackOverflow and reddit)

I think, no. Sure, you need be careful and you should only use it, if it is really needed. This could be a valid scenario: If you create a form to edit a user profile, where the user can add its job position, the country where he lives, his city, and so on. I would prefer not to pass the job positions, the country and the cities from the action to the view. I would prefer only to pass the user profile itself and I only want to handle the user profile in the action. This is why it is pretty useful in this case to inject the services which gives me this look-up data. The action and the ViewModel keeps clean and easy to maintain.

Just register your specific service in the method ConfigureServices in the Startup.cs and use one line of code to inject it into your view:

@inject DiViews.Services.ICountryService CountryService;

No you are able to use the ContryService in your View to fill a SelectBox with list of countries.

I wrote more about Dependency Injection in ASP.NET Core this posts).

#9: Functions

I never used functions in real ASP.NET MVC projects. I only used it with a the razor engine in an Umbraco web. Anyway, this is another possibility to extend your views a little bit. Maybe you have some a more complex view logic, in this case you can write C# methods in an functions area inside your view:

@functions
{
    public string ReverseString(string input)
    {
        return String.Join("", input.Reverse());
    }
}

#10: Global view configuration

Last but not least, there is a separate razor file you can use to configure some things globally. Use the _ViewImports.cshtml to configure usings, dependency injections and many more which should be used in all Views.

Conclusion

There are many ways to extend our views. some of them are known from previous MVC versions and some of them are new. Some of them shouldn't be used anymore because there are new or better ways. But you are free to decide which feature you want to use to get your problems solved.

Did I forget something? Please drop me a comment, to tell me what I need to add. If you miss something what you used in previous MVC versions, this is possibly not longer working in ASP.NET Core MVC (e.g. ChildActions). Anyway, feel free to ask me :)

Dependency Injection in ASP.​NET Core - a quick overview

16.02.2016 17:00:00 | Jürgen Gutsch

With ASP.NET Core Dependency Injection is now a first class citizen in ASP.NET. All parts of the ASP.NET Stack are using the same DI container. In this post I'm going to show you, how to configure the DI container and how to use it.

Let's first create a new and pretty simple service to use in the examples. As always in my examples it is a CountryService which provides a list of countries. We also need an interface for this service, let's create it too:

public class CountryService : ICountryService 
{ 
    public IEnumerable<Country> All() 
    { 
        return new List<Country> 
        { 
            new Country {Code = "DE", Name = "Germany" }, 
            new Country {Code = "FR", Name = "France" }, 
            new Country {Code = "CH", Name = "Switzerland" }, 
            new Country {Code = "IT", Name = "Italy" }, 
            new Country {Code = "DK", Name = "Danmark" } , 
            new Country {Code = "US", Name = "United States" }
        }; 
    } 
} 

public interface ICountryService 
{ 
    IEnumerable<Country> All(); 
} 

public class Country 
{ 
    public string Code { get; internal set; } 
    public string Name { get; internal set; } 
}

Register the services

We now need to add this ContryService to the DI container. This needs to be done in the Startup.cs in the method ConfigureServices:

services.AddTransient<ICountryService, CountryService>();

This mapping between the interface and the concrete type defines, that everytime you request a type of IContryService, you'll get a new instance of the CountryService. This is what transient means in this case. You are also able to add singleton mappings (using AddSingleton) and scoped mappings (using AddScoped). Scoped in this case means scoped to a HTTP request, which also means it is a singleton while the current request is running. You can also add an existing instance to the DI container using the method AddInstance.

These are the almost complete ways to register to the IServiceCollection:

services.AddTransient<ICountryService, CountryService>();            
services.AddTransient(typeof (ICountryService), typeof (CountryService));
services.Add(new ServiceDescriptor(typeof(ICountryService), typeof(CountryService), ServiceLifetime.Transient));
services.Add(new ServiceDescriptor(typeof(ICountryService), p => new CountryService(), ServiceLifetime.Transient));

services.AddSingleton<ICountryService, CountryService>();
services.AddSingleton(typeof(ICountryService), typeof(CountryService));
services.Add(new ServiceDescriptor(typeof(ICountryService), typeof(CountryService), ServiceLifetime.Singleton));
services.Add(new ServiceDescriptor(typeof(ICountryService), p => new CountryService(), ServiceLifetime.Singleton));

services.AddScoped<ICountryService, CountryService>();
services.AddScoped(typeof(ICountryService), typeof(CountryService));
services.Add(new ServiceDescriptor(typeof(ICountryService), typeof(CountryService), ServiceLifetime.Scoped));
services.Add(new ServiceDescriptor(typeof(ICountryService), p => new CountryService(), ServiceLifetime.Scoped));

services.AddInstance<ICountryService>(new CountryService());
services.AddInstance(typeof(ICountryService), new CountryService());
services.Add(new ServiceDescriptor(typeof(ICountryService), new CountryService()));

If you have a lot of services to register, you should create a extension method to the IServiceCollection to keep the Startup.cs clean. The same way is used by default for MVC and many other tools you want to use in your project:

services.AddMvc();

This extension method add all the services to the IServiceCollection which are needed by the MVC MiddleWare.

public static class ServiceCollectionExtensions
{
    public static IServiceCollection RegisterServices(
        this IServiceCollection services)
    {
        services.AddTransient<ICountryService, CountryService>();
        // and a lot more Services

        return services;
    }
}

The method RegisterServices looks now much more cleaner:

public void ConfigureServices(IServiceCollection services)
{
    // Add framework services.
    services.AddMvc();

    services.RegisterServices();
}

Usage

Now we can request an instance of an CountryService almost everywhere in our ASP.NET Core application. For example in a MVC controller:

public class HomeController : Controller 
{ 
    private readonly ICountryService _countryService; 

    public HomeController(ICountryService countryService) 
    { 
        _countryService = countryService; 
    } 
    // … 
}

New in ASP.NET Core MVC is, that we can also inject this service into a MVC view. The following line defines the injection in a Razor view:

@inject DiViews.Services.ICountryService CountryService;

The first part after the @inject directive defines the interface. The second part is the name of the variable which holds our instance.

To inject a service globally into all Views, add this line to the _ViewImports.cshtml. In a complete new ASP.NET Core project, there is already a global injection defined for ApplicationInsights:

@inject Microsoft.ApplicationInsights.Extensibility.TelemetryConfiguration TelemetryConfiguration

We are now able to use the instance in our view:

@if (countryService.All().Any()) 
{ 
    <ul> 
        @foreach (var country in CountryService.All().OrderBy(x => x.Name)) 
        { 
            <p>@country.Name (@country.Code)</p> 
        } 
    </ul> 
}

We can also use this service to fill select fields with the list of countries:

@Html.DropDownList("Coutries", CountryService.All() 
    .OrderBy(x => x.Name) 
    .Select(x => new SelectListItem 
    { 
        Text = x.Name, 
        Value = x.Code 
    }))

DI is also working in MiddleWares, TagHelpers and ViewComponents. You could use DI in TagHelpers to create reusable CountryList or whatever you want:

public class CountryListTagHelper : TagHelper
{
    private readonly ICountryService _countryService;

    public CountryListTagHelper(ICountryService countryService)
    {
        _countryService = countryService;
    }

    public string SelectedValue { get; set; }


    public override void Process(TagHelperContext context, TagHelperOutput output)
    {
        output.TagName = "select";
        output.Content.Clear();
        foreach (var country in _countryService.All())
        {
            var seleted = "";
            if (SelectedValue != null && SelectedValue.Equals(country.Code, StringComparison.CurrentCultureIgnoreCase))
            {
                seleted = " selected=\"selected\"";
            }
            var listItem = $"<option value=\"{country.Code}\"{seleted}>{country.Name}</option>";
            output.Content.AppendHtml(listItem);
        }
    }
}

This TagHelper could be used like this:

<country-list selected-value="@Model.Country"></country-list>

Conclusion

You are able to use DI almost everywhere in your application (Except in HtmlHelpers, because this are extension methods.) and you can use every servce which is registered in the IServiceCollection, even the services which are registerd by ASP.NET Core. This also means all the contexts, all the environment and even the logger. This helps a lot to keep a ASP.NET Core application clean, leightweight, maintainable and testable.

Ein kleiner Einblick, wie Microsoft Windows 10 entwickelt

15.02.2016 09:56:20 | Kay Giza

Bei seinem Besuch in der Microsoft-Konzernzentrale in Redmond hat mein Kollege Sebastian Klenk die die Gelegenheit genutzt, Gerald Haslhofer zu interviewen. Gerald leitet ein Software-Entwicklungsteam, das für eine Handvoll Features in Windows 10 verantwortlich ist. Unter anderem für Windows Spotlight, das Nutzern täglich neue, beeindruckende Bilder auf dem Sperrbildschirm anzeigt. Sebastian hat ein rund 12 Minuten langes Interview mit Gerald geführt... [... mehr auf Giza-Blog.de]

This post is powered by www.Giza-Blog.de | Giza-Blog.de: RSS Feed
© Copyright 2006-2016 Kay Giza. All rights reserved. Legal

Code Coverage Reports für UnitTests in Android Studio

10.02.2016 12:02:00 | Martin Hey

Android Studio unterstützt automatisiertes Testen bereits out-of-the-box. Dabei wird grundsätzlich zwischen verschiedenen Arten von Tests unterschieden. Eine detaillierte Beschreibung findet man im Testing-Abschnitt der Doku.

Nach dem Durchführen der Tests erhält man einen Testreport und (sofern aktiviert) auch einen mit JaCoCo erzeugten Coverage-Report. Allerdings war das Android-Studio-Team hier nicht ganz so konsequent, denn die Coverage-Reports werden für UnitTests nicht erzeugt. Hier spiegeln sich lediglich die Android-Tests wider.

Wie kann man nun erreichen, dass meine ganz normalen Unit-Tests mit JUnit auch einen solchen Coverage-Report erzeugen. In meinem Projekt habe ich nämlich lediglich JUnit-Tests und ich mocke den ganzen Android-Kram mit Hilfe von Robolectric und Mockito - was zugegebenermaßen dafür sorgt, dass ich keine Integrationstests habe, aber dafür eben die Funktionen sauber getestet sind ohne dass ich ich auf einen Emulator verlassen muss.

Nach stundenlangem Suchen in ähnlich gelagerten Problemen auf Stackoverflow bin ich dann in den Kommentaren auf ein Plugin gestoßen, das mein Build-Script genau mit den erforderlichen Funktionalitäten erweitert wird - und seit der Version 0.2.1, welche derzeit bereits als Snapshot vorliegt werden auch Intermediates ignoriert, die "$$" im Dateinamen haben.

Microsoft will seine Rechenzentren im Ozean versenken

09.02.2016 09:08:58 | Mathias Gronau

Ein erheblicher Teil der Energie, die ein Rechenzentrum benötigt, wird durch die Kühlung verbraucht. Die Kühlung erfolgt meist durch Wasser. Was liegt also näher, als das ganze Rechenzentrum im Wasser zu bauen? Das hat sich bereits im Februar 2013 auch Microsoft Research gedacht und hat begonnen, mit Project Natick ein Rechenzentrum zu entwerfen, das unter Wasser funktioniert und dadurch quasi im Kühlmittel zu Hause ist. Die Platzierung der Rechenzentren im Wasser hat noch einen weiteren Vorteil: etwa die Hälfte der Menschen lebt in Küstennähe. Derzeit werden die Rechenzentren meist in dünn besiedelten Gegenden gebaut, wo die Kosten geringer sind. Würden sich die Rechenzentren in der Nähe der Menschen befinden, wäre die Datenübertragung schneller, da die Daten nicht über weite Strecken transportiert werden müssten. Im August 2014 war es dann so weit: bei einem Meeting in Redmond wurde das Projekt offiziell aus der Taufe gehoben, auch wenn davon noch nichts an die Öffentlichkeit drang. Ein Jahr später war der erste Prototyp fertig, er wurde Leona Philpot genannnt. In dem mit Stickstoff gefüllten Stahltank steckte ein Serverrack. Der Stahltank wurde etwa einen Kilometer von der Küste entfernt in 10 Metern Tiefe versenkt. Es folgten lange Testreihen, die im November 2015 abgeschlossen wurden. Daraufhin wurde der Tank wieder geborgen und im Dezember nach Redmond transportiert, wo er überprüft und aufgefrischt werden soll. Dass das Projekt damit noch nicht am Ende ist, dürfte jedem klar sein. Die New York Times berichtet, dass die Arbeiten an einem dreimal größeren Tank bereits begonnen haben. Sicherlich sind vor dem kommerziellen Einsatz dieser Technologie noch viele Hürden zu nehmen, aber es wäre sicher eine tolle Sache, wenn das Projekt schließlich zum Erfolg führen würde. Microsofts Planungen sind ehrgeizig: Die Tanks sollen fünf Jahre in Betrieb bleiben, bevor die dann veraltete Hardware ausgetauscht werden soll. Vier solcher Zyklen sollen die Tanks überstehen, bevor sie zum Recycling auf den Schrottplatz kommen.

Azure Stack: Die Vorteile der Public Cloud fürs firmeneigene Rechenzentrum

03.02.2016 11:27:30 | Mathias Gronau

Microsoft stellt die erste Technical Preview (TP) von Azure Stack seit dem 29. Januar 2016 zur Verfügung. Mit der neuen, hybriden Cloud-Plattform Azure Stack sind die Unternehmen in der Lage, Dienste der Microsoft Cloud-Plattform Azure im eigenen Rechenzentrum einsetzen. Dabei profitieren sie von der Skalierbarkeit und dem effizienten Management einer Public-Cloud-Lösung, ohne auf die Kontrollmöglichkeiten eines eigenen Rechenzentrums verzichten zu müssen. Einheitliche Benutzerportale und Entwicklungstools für Azure Stack und Azure ermöglichen Anwendern hybride Cloud-Szenarien mit geringerem Installationsaufwand: Sie können ihre Apps je nach Bedarf mit Azure Stack im eigenen Rechenzentrum oder in der Azure Public Cloud entwickeln und bereitstellen. Skalierbare Infrastruktur-Dienste der Public Cloud für das eigene Rechenzentrum Azure Stack bringt die bewährten Public-Cloud-Dienste in die Rechenzentren der Unternehmen: von virtuellen Maschinen unter Windows oder Linux über privaten Netzwerken mittels IPSec-VPN oder ExpressRoute bis hin zu Blob Storage für SQL Server- und SharePoint-Anwendungen. Die Unternehmens-IT kontrolliert dabei den gesamten Service-Delivery-Prozess. Einheitliche App-Entwicklung mit Technologien Ihrer Wahl, auch mit Open Source Nach dem Motto „write once, deploy to Azure or Azure Stack“ können Entwickler noch effizienter Apps programmieren und bereitstellen – unabhängig davon, ob sie auf Azure oder Azure Stack laufen. Sowohl für traditionelle als auch für Apps, die nativ in der Cloud ausgeführt werden, wird gegen die gleichen Schnittstellen (APIs) programmiert. Das ist sowohl mit Microsoft- als auch klassischen Open-Source-Technologien möglich – von .NET bis hin zu Java und Node.JS-Entwickler, die auf Visual Studio als Entwicklungsumgebung setzen, können die IDE auch für Azure Stack wie gewohnt nutzen. Azure Stack erleichtert Transformation der Unternehmens-IT in die Cloud Genau wie Azure ist Azure Stack eine Plattform für die Entwicklung und Bereitstellung von Geschäftsanwendungen. Für beide gilt: standardisierte Architektur, gleiches Benutzerportal sowie einheitliche Technologien für die Entwicklung der Apps. Peter Arbitter, Senior Director Cloud & Enterprise Business Group bei Microsoft Deutschland, erklärt: „Azure Stack erleichtert Unternehmen nicht nur die Bereitstellung von Anwendungen über das eigene Rechenzentrum bei zunehmender Flexibilität und Skalierbarkeit. Es ermöglicht ihnen auch, Anwendungen jederzeit ohne großen Aufwand in die Public Cloud zu bringen – in dem Umfang und Tempo, die am besten zu ihren Geschäftsprozessen und Compliance-Anforderungen passen. Damit bieten wir ihnen als weltweiter Provider von Cloud-Technologien eine Vielfalt an Wahlmöglichkeiten für die Umsetzung von private, public und hybriden Cloud-Szenarien, die bisher im Markt einzigartig ist.“ Mit der Technical Preview lädt Microsoft Unternehmenskunden mit eigenem Rechenzentrum ein, die Vorteile einer hybriden Cloud-Umgebung zu testen. Für den Start mit Azure Stack hat Microsoft auf GitHub bereits zahlreiche Templates für den Azure Resource Manager sowie OS-Images bereitgestellt, die in den kommenden Monaten weiter ergänzt werden.

Neues Visual Studio Code Insider-Programm: Visual Studio Code – Insiders

02.02.2016 13:44:17 | Kay Giza

Ab 1. Februar 2016 - Visual Studio Code - ein neues Insider-Programm. Willkommen Visual Studio Code – Insiders als eigenständiges und parallel zu Visual Studio Code laufendem Release. as heißt, ab sofort kann man sich parallel, zu dem normalen und stabilen Visual Studio Code, durch Teilnahme am Insider-Programm... [... mehr auf Giza-Blog.de]

This post is powered by www.Giza-Blog.de | Giza-Blog.de: RSS Feed
© Copyright 2006-2016 Kay Giza. All rights reserved. Legal

Bing Continuous Delivery – Engineering Story

01.02.2016 09:13:53 | Christian Binder

Real World : Continuous Delivery bei Bing

Interessante Aspekte aus dem Engineering und der “DevOps Culture” z.B.:

Inner Loop: The loop that spans ideation through code commit, and most often centers on an engineer writing the code for a given feature. Because engineers require an idea from which to design and build a feature, this loop also includes prototyping, crowd-sourced feature engagement and feasibility studies.

Outer Loop: This is the loop that gets committed code out to Production. Because a feature is not really finished until we have successfully navigated live user trials, our experimentation-centered culture requires that we consider the cost of flighting features within this loop.

http://stories.visualstudio.com/bing-continuous-delivery/

Chris

Regeln | Impressum