.
Anmeldung | Registrieren | Hilfe

.NET-Blogs Archiv August 2015

Force heartbeat to change active node in standby or release or to primary one mode

17.08.2015 11:38:00 | Andreas Mehl

If you want manually change your current node to another one you have to execute my following Instructions.

First check if you have the right files Scripts under following directories.

You should have some scripts (probably in /usr/share/heartbeat) called

hb_takeover

hb_standby

 

Connect to your Heartbeat Server which you want to get the active node.

Run following in console to take that node (Heartbeat cluster) to your primary one:

/usr/share/heartbeat/hb_takeover

 

Run following in console to take that node (Heartbeat cluster) in standby mode, so that another one is taking the work. You can run hb_standby on the active node to release resources:

/usr/share/heartbeat/hb_standby

 

Just wait a few milliseconds and you will see your node is in change mode.

Proguard und Realm.IO

14.08.2015 17:08:00 | Martin Hey

In einem Projekt habe ich mal Realm ausprobiert. Dabei handelt es sich um eine alternative Datenbank, die verspricht die Wiederverwendung von Code aufgrund gleicher Model-Klassen sowohl in IOs als auch in Android hoch zu halten.

Detaillierte Erfahrungsberichte dazu kommen sicher in einem späteren Post.

Zunächst gab es eine kleiner Überraschung nach der Aktivierung von Proguard. Der Hersteller gibt folgende Konfiguration an:
-keep class io.realm.annotations.RealmModule
-keep @io.realm.annotations.RealmModule class *
-dontwarn javax.**
-dontwarn io.realm.**
Allerdings erreichte mich dann bei der Ausführung folgende Exception:
java.lang.IllegalArgumentException: class io.realm.internal.d declares multiple JSON fields named c
    at a.a.a.b.a.q.a(Unknown Source)
    at a.a.a.b.a.q.a(Unknown Source)
    at a.a.a.j.a(Unknown Source)
     .....
Heißt, die korrekte Proguard-Konfiguration sollte dieses Package wohl besser auch von der Obfuskierung ausschließen:
##---------------Begin: proguard configuration for Realm  ---------- 
-keep class io.realm.annotations.RealmModule -keep @io.realm.annotations.RealmModule class * -keep class io.realm.internal.** { *; } -dontwarn javax.** -dontwarn io.realm.** ##---------------End: proguard configuration for Realm ----------

Microsoft Stellenangebote: Event- und Marketing Manager, DreamSpark Academic Program, BizSpark Startup Program Specialist

12.08.2015 14:05:15 | Kay Giza

Derzeit suchen wir bei uns in der Abteilung einige neue Kolleginnen und Kollegen. Meine Abteilung ist die Developer Experience & Evangelism (DX) -Group innerhalb der Microsoft Deutschland. U.a. sind derzeit diese Stellen bei uns im Team vakant. Bei Interesse bitte direkt auf der Webseite bewerben oder mich gerne kontaktieren... [... 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

Assembly Referenzen in ASP.NET 5 Projekten

10.08.2015 00:28:00 | Jürgen Gutsch

Letzte Woche wurde ich wieder einmal gefragt, ob es denn nicht möglich sei Assembly Referenzen in ASP.NET 5 Projekten zu Setzen.

Generell gilt: ASP.NET 5 Projekte arbeiten mit NuGet Packages und .NET Core Projekte wirklich ausschließlich. Der Grund ist, das eine publizierte ASP.NET 5 Anwendung selber ein NuGet Package ist. (Ich hatte in ASP.NET 5 allgemein darüber geschrieben.)

Das heißt eigene Assemblies, oder Assemblies von Drittanbietern, die nicht als NuGet Package kommen, müssen erst als für NuGet verpackt werden, um eingebunden werden zu können.

Aber wie sieht das mit Projekten aus die ausschließlich auf das .NET Framework basieren?

Hier müsste ich doch auch auf Bibliotheken referenzieren können, die mir das .NET Framework bietet.

Um das zu lösen, müssen wir uns die Project.json mal genauer ansehen:

{
    "webroot": "wwwroot",
    "userSecretsId": "aspnet5-WebApplication2-0c645fea-dc43-43cd-9b0a-855d168f0c72",
    "version": "1.0.0-*",

    "dependencies": {
        "EntityFramework.SqlServer": "7.0.0-beta5",
        "EntityFramework.Commands": "7.0.0-beta5",
        "Microsoft.AspNet.Mvc": "6.0.0-beta5",
        "Microsoft.AspNet.Mvc.TagHelpers": "6.0.0-beta5",
        "Microsoft.AspNet.Authentication.Cookies": "1.0.0-beta5",
        "Microsoft.AspNet.Authentication.Facebook": "1.0.0-beta5",
        "Microsoft.AspNet.Authentication.Google": "1.0.0-beta5",
        "Microsoft.AspNet.Authentication.MicrosoftAccount": "1.0.0-beta5",
        "Microsoft.AspNet.Authentication.Twitter": "1.0.0-beta5",
        "Microsoft.AspNet.Diagnostics": "1.0.0-beta5",
        "Microsoft.AspNet.Diagnostics.Entity": "7.0.0-beta5",
        "Microsoft.AspNet.Identity.EntityFramework": "3.0.0-beta5",
        "Microsoft.AspNet.Server.IIS": "1.0.0-beta5",
        "Microsoft.AspNet.Server.WebListener": "1.0.0-beta5",
        "Microsoft.AspNet.StaticFiles": "1.0.0-beta5",
        "Microsoft.AspNet.Tooling.Razor": "1.0.0-beta5",
        "Microsoft.Framework.Configuration.Abstractions": "1.0.0-beta5",
        "Microsoft.Framework.Configuration.Json": "1.0.0-beta5",
        "Microsoft.Framework.Configuration.UserSecrets": "1.0.0-beta5",
        "Microsoft.Framework.Logging": "1.0.0-beta5",
        "Microsoft.Framework.Logging.Console": "1.0.0-beta5",
        "Microsoft.VisualStudio.Web.BrowserLink.Loader": "14.0.0-beta5"
    },

    "commands": {
        "web": "Microsoft.AspNet.Hosting --config hosting.ini",
        "ef": "EntityFramework.Commands"
    },

    "frameworks": {
        "dnx451": {},
        "dnxcore": {}
    },

    "exclude": [
        "wwwroot",
        "node_modules",
        "bower_components"
    ],
    "publishExclude": [
        "node_modules",
        "bower_components",
        "**.xproj",
        "**.user",
        "**.vspscc"
    ],
    "scripts": {
        "prepublish": [ "npm install", "bower install", "gulp clean", "gulp min" ]
    }
}

Zuerst haben wir den Bereich mit den “dependencies”, in den die ASP.NET 5 Packages hinterlegt werden. Würde man mit beiden Frameworks arbeiten, würden dort Packages hinterlegt werden, die für beide Frameworks gültig sind, also eine .NET Framework Assembly und eine .NET Core Assembly bereitstellen. Wenn man unter “frameworks” allerdings genauer schaut, sieht man die lehren Objekt-Literale die hinter dem jeweiligen Framework stehen. Genau hier ist noch mehr machbar.

Wir haben hier die Möglichkeit weitere Referenzierungen vorzunehmen. Zum einen wie oben auf NuGet Packages und zum anderen auf Assemblies aus dem .NET Framework:

"frameworks": {
    "dnx451": {
        "dependencies": {
            "Nunit": "2.6.4"
        },
        "frameworkAssemblies": {
            "System.Drawing": "4.0.0.0"
        }
    },
    "dnxcore" : {}
}

Wir können hier also explizit für das jeweilige Framework, spezielle Referenzierungen vornehmen. Nehmen wir das .NET Core raus, kann die Referenz auch problemlos direkt oben unter “dependencies” referenziert werden.

Das Ergebnis im Solution Explorer kann sich sehen lassen:

image

Wie sieht es mit Projektreferenzen aus?

Ich habe spaßeshalber eine klassisches DLL Projekt mit .NET 4.5.1 (mit dem Namen DnxLibrary) hinzugefügt und im ASP.NET 5 Projekt referenziert. Das funktioniert einwandfrei. Die Frage ist nur: Wieso. Denn das Projekt sieht in der project.json aus wie eine NuGet Referenz:

"dnx451": {
    "dependencies": {
        "Nunit": "2.6.4",
        "DnxLibrary": "1.0.0-*"
    },
    "frameworkAssemblies": {
        "System.Drawing": "4.0.0.0"
    }
}

Im Solution Explorer erhalten wir ein anderes Symbol. Schaut man sich die Eigenschaften dieser Referenz im Eigenschafts-Fenster an, verweist diese Referenz auf eine project.json unter <SolutionFolder>\wrap\<LibraryName>\ In dieser project.json wird dann auf die Assembly verwiesen.

Diese Library wird für ASP.NET 5 Projekte also erst Mal gewrapt. Beim publizieren wird dann die Library tatsächlich mit NuGet gepackt und zur Verfügung gestellt:

image

Fazit

Alles ist irgendwie ein NuGet Package, mit Ausnahme von .NET Framework Assemblies. Class Library Projekte können problemlos als Projektreferenz eingebunden werden.

Lediglich einzelne Assemblies müssen manuell gepackt werden, um referenziert werden zu können.

ASP.NET Web API aktivieren

05.08.2015 01:28:00 | Jürgen Gutsch

Die Einbindung von MVC wahr schon sehr einfach. Noch einfacher ist es, Web API zu aktivieren. In diesem Teil möchte ich zeigen wie die viel genutzte, minimale ASP.NET Konfiguration mit Web API erweitert werden kann um REST APIs bereit zu stellen.

1. Wie benötigen die gleichen NuGet Referenzen wir für MVC auch:

"Microsoft.AspNet.Mvc": "6.0.0-beta5",

Die Web API und das Routing stecken nun in der MVC Assembly und nutzen die gleichen Techniken

2. In der Methode ConfigureServices() müssen die Abhängigkeiten für Web API im IoC Container registriert werden:

services.AddMvc();

3. Und am Ende in der Methode Configure() müssen wir noch die Middleware für MVC nutzen:

app.UseMvc();

Was fällt auf? Ganz klar, dass ist die gleiche Konfiguration wie für MVC, lediglich das Routing habe ich hier weggelassen. Web API ist also nun ein fester Bestandteil von ASP.NET MVC.

Ausprobieren

Ist die Konfiguration erledigt, können wir die die erste Web API schreiben (Auch hier nutze ich wieder den ICountryService aus den vergangenen Beiträgen):

using Microsoft.AspNet.Mvc;
using System.Collections.Generic;

[Route("api/[controller]")]
public class CountryController : Controller
{
    private readonly ICountryService _countryService;
    public CountryController(ICountryService countryService)
    {
        _countryService = countryService;
    }
    
    [HttpGet]
    public IEnumerable<Country> Get()
    {
        return _countryService.All();
    }
   
    [HttpGet("{id}")]
    public IEnumerable<Country> Get(string id)
    {
        return _countryService.All().Where(x => x.Code.Equals(id));
    }
}

Auch hier fällt auf, dass wir nicht von ApiController ableiten, sondern von der gleichen Basisklasse die auch MVC-Controller nutzen. Der einzige Unterschied, zwischen Web API und ASP.NET MVC ist mit ASP.NET 5 also lediglich die Rückgabe. Wird eine View erzeugt und zurückgegeben, so haben wir ASP.NET MVC wird keine View, wird die Rückgabe nach JSON serialisiert und es handelt sich um eine Web API. Über die HTTP Methoden Get, Post, Put können dann die weiteren Zugriffsmöglichkeiten auf die API festgelegt werden.

image

Der gesamte Code und die vergangenen Beispiele, können auf Github angesehen werden: https://github.com/juergengutsch/aspnet5

WebApiCompatShim

In einem neuen Visual Studio 2015 Projekt finden wir noch weiter Web API spezifische Einstellungen auskommentiert in der startup.cs. Zum einen werden unter ConfigureServices() noch WebApiConventions registriert:

services.AddWebApiConventions();

Und in der Methode Configure() wird unter UseMvc noch eine Web API Route hinzugefügt:

app.UseMvc(routes =>
{
    routes.MapRoute(
        name: "default",
        template: "{controller=Home}/{action=Index}/{id?}");

    // Uncomment the following line to add a route for porting Web API 2 controllers.
    routes.MapWebApiRoute("DefaultApi", "api/{controller}/{id?}");
});

Diese Angaben sind mit ASP.NET 5 nicht mehr möglich, sondern dienen der einfachen Portierung von Web API 2 nach ASP.NET 5. Dafür muss allerdings eine weitere NuGet Referenz genutzt werden:

"Microsoft.AspNet.Mvc.WebApiCompatShim": "6.0.0-beta5"

Durch diese Referenz steht unter anderem dann auch wieder ein ApiController zur Verfügung. Ich würde aber empfehlen neue Web APIs ohne diesen Overhead zu schreiben.

ASP.NET MVC 6 Aktivieren

04.08.2015 01:09:00 | Jürgen Gutsch

Ausgehend von dem minimalen ASP.NET 5 Projekt, mit dem ich in den letzten Beiträge gearbeitet habe, ist die Aktivierung von MVC 6 ist sehr einfach, im Grunde sind es ja nur drei kleine Schritte die zu machen sind:

1. Als erste benötigen wir zwei neue NuGet Referenzen:

"Microsoft.AspNet.Mvc": "6.0.0-beta5"
"Microsoft.AspNet.Mvc.TagHelpers": "6.0.0-beta5",

2. In der Methode ConfigureServices müssen die Abhängigkeiten für MVC im IoC Container registriert werden:

services.AddMvc();  

3. Und am Ende müssen wir noch die Middleware noch einbinden und die Route für die MVC festlegen:

app.UseMvc(routes => 

    routes.MapRoute( 
        name: "default"
        template: "{controller=Home}/{action=Index}/{id?}"); 
});

Erstellt man ein neues Projekt mit dem Visual Studio 2015 ist das natürlich bereits erledigt, da es Teil des Projekttemplates ist.

Ausprobieren

Ist das erledigt, können wir die die erste MVC Seite anlegen:

Es reicht zum ausprobieren eine ganz einfacher HomeController, mit einer kleinen Index-Action, die erst Mal nur die View zurückgibt:

using Microsoft.AspNet.Mvc; 
public class HomeController : Controller 

    [HttpGet] 
    public ActionResult Index() 
    { 
        return View(); 
    } 
}

Die Komplexität der View halten wir ebenfalls vorerst mal in Grenzen:

<html> 
    <head> 
    <title>Hallo Welt</title> 
    </head> 
    <body> 
        <h1>Hallo Welt</h1> 
    </body> 
</html>

Das Ergebnis ist das erwartete:

image

Ich würde jetzt gerne noch sehen wollen, ob DI und Razor jetzt tatsächlich auch tun, oder ob es tatsächlich schon so einfach war. Ich erweitere den Controller nun so weit, dass ich den ICountryService aus den vergangenen Beiträgen Injiziere und die Liste mit Ländern an die View übergebe:

public class HomeController : Controller 

    private readonly ICountryService _countryService; 
    public HomeController(ICountryService countryService) 
    { 
        _countryService = countryService; 
    } 
    
    [HttpGet] 
    public ActionResult Index() 
    { 
        return View(_countryService.All()); 
    } 
}

Die View muss die Daten nun auch verarbeiten:

@using System.Collections.Generic 
@model IEnumerable<Country> 
    
<html> 
    <head> 
    <title>Hallo Welt</title> 
    </head> 
    <body> 
        <h1>Hallo Welt</h1> 
        @if(Model.Any()){ 
            <ul> 
            @foreach(var country in Model){ 
                <li>(@country.Code) @country.Name</li> 
            } 
            </ul> 
        } 
    </body> 
</html>

Et voilá:

image

Irgendwie genial, oder? Kaum Konfiguration, wenig Code und dann so eine Wirkung ;) Im Ernst: Der Beweis dass, ASP.NET 5 ein leichtgewichtiges Framework ist, ist damit erbracht. Damit das auch jeder nachvollziehen kann, habe ich den Code der letzten Beiträge und von diesem Beitrag auf GitHub geladen. So kann das jeder selber nachvollziehen.

Regeln | Impressum