Ebben az írásban a programozott tesztekről lesz szó azon egyszerű okból kifolyólag, hogy a manuális részéhez nem értek. Annyit mindenesetre érdemesnek tartok leírni, hogy annak ellenére, hogy mostanában hipszter dolog mindent automatizálni, a manuális tesztelést NEM lehet elhagyni.

No, vágjunk bele egy elmés kérdéssel: miért tesztelünk?

Ha felütünk valamilyen hivatalosnak tűnő könyvet akkor valami olyasmi lesz benne, hogy validálni kell, hogy a (szoftver)termék kielégítse az üzleti igényeket. ez nyilván része a manuális tesztelésnek is (sőt, tulajdonképpen az főleg erről szól), de a programozott/automatizált tesztek esetében is oda kell figyelni erre.

Szükségesnek tartok még kiemelni két másik okot is:

1. A termék egyes alkotóelemei hiba nélkül működnek együtt, szépen fogalmazva jól integrálódnak egymásba, pestiesen szólva meg a “frissen becommitált változtatás nem baszcsizza meg a rendszert”.
2. A tesztelésre felkészített forráskód általában rendelkezik azzal a tulajdonsággal, hogy szépen van megírva, így a későbbiekben fájdalom nélkül kiegészíthető/bővíthető.

A második ponttal menjünk tovább, azzal a felütéssel, hogy a működő (üzleti igényeket kielégítő) szoftver nem szükségszerűen jó is. A legtöbb esetben elmondható, hogy a szoftvert supportálni és/vagy továbbfejleszteni kell a jövőben és bizony ha azt valaki odahekkelte akkor az valódi fájdalom tud lenni. Persze itt megjelenik az a probléma, hogy két szemben álló fél – fejlesztők és a menedzsment – eltérő dolgokat gondolnak fontosnak – minőség és “legyünk kész tegnapra” (ez persze nagyon sztereotip, de sajnos sokszor igaz – tisztelet a kivételnek). Viszont:

Fejlesztési idő alatt a hibák javítása mindig olcsóbb

És itt akár refaktorálást is érthetünk. Általában igaz, hogy ha egyszer egy termék kijutott éles környezetbe onnantól kezdve borzalmasan nehéz fundamentális problémákat megszüntetni. Vagy azért mert sokáig tart, vagy azért mert nem fizetik ki vagy azért mert egyszerűen nincs rá idő. Értsd: az a technológiai adósság amit fejlesztési idő alatt nem fizettünk ki jó eséllyel soha nem lesz behozva.

Most lehet azt hiszitek, hogy elkanyarodtunk a témától, de valójában nem Szimplán az az erőfeszítés ami programozottan tesztelhetővé tesz egy szoftvert tényleges üzleti értéket jelent és hosszútávon megéri a belefektetett munkát.

És még valami:

DEBUG IS A FEATURE

Ez nagyjából a legfontosabb tanulság amit ebben a cikkben leírok. Ha egy szoftver könnyen debuggolható az elképesztő mennyiségű emberórát spórol meg hosszú ÉS rövid távon is. Példa: válasszuk ki az egyszerűbbnek gondolt hibakereső módszert:

1. A konkrét terméken manuálisan előidézve a hibát, rácsatlakozva (Attach to process) debuggolni, kijavítani a hibát, várni, hogy a fordítás után újra felálljon a rendszer majd a fentieket ismételni amíg eredményre jutunk.
2. Programozott tesztet írni, kijavítani a hibát majd futtatni a tesztet anélkül, hogy komolyabban várakozni kelljen (és persze ismételni amíg jó nem lesz)

A választ rátok bízom

Tehát, kimondhatjuk, hogy a tesztelési stratégiánk alapjaiban határozza meg a szoftver életciklusát bármennyire is furcsának hasson ez.

Most nézzük meg milyen teszteket ismerünk:

Automatikus tesztek

Ezek valamilyen külső szoftver segítségével programozottan szimulálják a valós felhasználói interakciót. Van ahol integrációs teszteknek hívják őket, de ez nem igaz (mindjárt). Ezeknek a teszteknek a hatásfoka eltérő technológiánként. Több helyről hallottam, hogy a mobil eszközökre való fejlesztés esetén nagyon hatékonyak, bár az tény, hogy abban az esetben viszonylag kevés komponens játszik szerepet. Ugyanezen okból tisztán kliens oldal alkalmazásoknál is hatékonyak.

Nézzük az előnyöket:

• Valós környezetben folyik a teszt amit pl. videóra lehet venni és később visszanézni
• Nagyon jó smoke tesztekre

A hátrányokat:

• Sokáig tart a futásuk (ez igazából nem hátrány) ezért pl. build folyamatba nem igen lehet beépíteni. Ugyanezért gyakori, hogy éjszaka futnak.
• Kell mögé infrastruktúra (és valaki aki karbantartja)
• Valakinek meg is kell írni illetve ismernie kell az automatizáló keretrendszert, ez általában teljes embert kíván
• Nem megbízhatóak (ez főleg webes tesztekre igaz)
  • Timeout érzékenység – a legtöbb webes automatikus teszt sok időt tölt azzal, hogy várjon HTML elemek megjelenésére
  • Viszonylag gyakori false negatív eredmények

Összegezve: az automatikus tesztek hatékonyak ha jól használjuk őket. Én hajlok afelé, hogy nem kell nagyon sok ilyen teszt, sokszor láttam/látom, hogy százasával (néha ezresével) készülnek, de a hosszú futási idő és a megbízhatatlanság miatt ilyenkor már elvesztik hasznosságukat.

Unit tesztek

Kétféle fejlesztő van: az egyik szereti a unit teszteket a másik nem. Én inkább a nem felé hajlok, de inkább legyenek unit tesztek mint ne (ezt jól megaszontam ).

Egy adott egységnyi forráskódot tesztelnek, ez lehet pl. egy függvényhívás vagy egy feltétel egy ága. Ezeknek az egységeknek a függőségeit kicseréljük vagy egy fake-re (egyszerűsített megvalósítás) vagy mock-ra (valamilyen külső könyvtárral létrehozott ál-objektum ami úgy viselkedik mint az eredeti).

Személy szerint úgy gondolom, hogy a legnagyobb probléma, hogy olyankor is alkalmazzák őket amikor nincs értelme. Bármilyen teszt esetében el kell dönteni, hogy pontosan mit is akarunk tesztelni. Tegyük fel, hogy van egy függvényem ami kap pár paramétert majd meghív mondjuk egy egy tárolt eljárást az adatbázisban ezekkel a paraméterekkel. Ha most emögött kicseréljük az adatelérési réteget akkor elmondhatjuk, hogy nagyjából nem teszteltünk semmit. Más lenne persze a helyzet ha a függvényen belül tényleges logika van.

Itt meg kell említeni a TDD-t (Test Driven Development) ami egyszerre jó és rossz. Jó, mivel kikényszeríti, hogy igenis szépen legyen megcsinálva a forráskód, ugyanakkor könnyű túltolni a dolgokat és olyan absztrakciók jelenhetnek meg amik inkább bajt hoznak mint hasznot. Ez utóbbi eset a tipikus design pattern fetisizmus

Előnyök:

• Kényszerített “szép” felépítés
• Segít egységes forráskódot kialakítani, de ehhez kell az, hogy minden fejlesztő betartsa a szabályokat és ne hekkeljen
• Általában gyorsan lefutnak ezért lehet a build folyamat része és gyorsan fény derül arra, ha valami félrement

Hátrányok

• Refaktorálásnál sok minden eltörhet (ez nem feltétlenül rossz)
• A részegységeket csak magukban teszteli
• Felesleges absztrakciókat vezethet be, de odafigyeléssel ez elkerülhető
• Third party könyvtárakkal néha nehéz az együttműködés, pl EF 6.x hagyományosan nehezen tesztelhető, hacsak nem vezetünk be absztrakciókat felé
• Mi történik ha az alkalmazáslogika több helyen van szétszórva, pl. tárolt eljárások

Összegezve: a unit tesztek hasznosak, ha ésszel használjuk őket.

Integrációs tesztek

Komplett üzleti folyamatokat modelleznek (de nem a konkrét felhasználói felületen) a meglévő komponensekkel. Lényegében ilyenkor egy komplett programot írunk. Kiváló mind az üzleti elvárások validálására és bugfixekre is. A külső függőségeket csak akkor cseréljük le, ha valamiért az nem fontos vagy megakasztaná a teszt futását (pl. logolás, email küldés hagyományosan ilyen).

Előnyök

• Alkalmas komplett üzleti folyamatok leírására
• Könnyen használható bugfixekre
• Teszteli az egyes komponensek együttműködését (ugye integrációs)

Hátrányok

• Sok munka igazán jó keretrendszert építeni
• És ezt gyakran ki is kell egészíteni, karbantartani
• Lényegesen tovább tart a futásuk mint a unit teszteknek (igaz, kevés is elég belőlük)
• Kell tesztkörnyezet amit ki kell építeni és karbantartani

Végezetül gondoljuk át, hogyan írhatunk tesztelhető szoftvert. Igazából nincsen biztosan működő recept, mindössze néhány egyszerű alapelvet kell betartani:

• SOLID elvek
  • Különös tekintettel a Single Responsibility Principle-re
• KISS
  • Az egyszerű mindig jobb
• DRY
  • Újrafelhasználhatóság
• YAGNI
  • Nem kell csillaghajót építeni

]]> https://reiteristvan.wordpress.com/2017/05/15/az-szoftvertesztelesrul/feed/ 0 reiteristvan https://reiteristvan.wordpress.com/2017/05/01/webpackolas-numero-uno/ https://reiteristvan.wordpress.com/2017/05/01/webpackolas-numero-uno/#respond Mon, 01 May 2017 16:19:06 +0000 http://reiteristvan.wordpress.com/?p=1142 …

Pár hete “kicsit” elgurult a gyógyszerem, minek eredményeként az alábbi képen látható kirohanás keletkezett. A véleményemet továbbra is tartom (mindjárt leírom majd, hogy miért), de a helyzet az, hogy ha továbbra is akarok frontend fejlesztéssel foglalkozni (márpedig akarok), akkor kénytelen leszek WebPack ninja rockstar SITH LORD lenni.

Persze ettől még elég távol állok. Na szóval, térjünk vissza az ominózus kirohanásomra (elég explicitre sikerült ):

Ahhoz, hogy megértsük, hogy honnan jött ez az egész kicsit felejtsük el a frontendet és nézzük meg az elsődleges skillemhez (C# fejlesztés) kapcsolódó fejlesztői élményt. Visual Studio megnyit, New Project, .NET verzió beállít, Ok, kész. F6, lefordul. Ha adok a projekthez külső függőséget akkor is lefordul. Ha több projektre szedem szét a solution-t akkor is lefordul. Persze könnyű dolga van az IDE-nek, hiszen ami lefordul abból egy csinos kis bináris lesz ami leírja önmagát, így a Visual Studio tudni fogja, hogy merre hány lépés. Nyilván itt is vannak olyan esetek amikor szív az ember, de ez mondjuk az esetek fél százalékának a fele. Pedig tulajdonképpen a folyamat maga egyáltalán nem egyszerű, csak a Microsoft-nál ülő emberek tudják, hogy ha feleslegesen megbonyolítják a dolgot akkor nehéz lesz új fejlesztőket a platformra hozni, ezért mindent megtesznek, hogy a fejlesztői élmény kiváló legyen és a programozó csak a dolgával törődhessen. Ennek meg is van az eredménye, hiszen a Visual Studio a butaságaival együtt is az egyik legnépszerűbb (ha nem A legnépszerűbb) IDE a világon.

És akkor itt van a frontend fejlesztés ahol ugye rögtön nehezíti a dolgunkat, hogy olyan technológiával akarunk alkalmazást írni amit nem igazán erre találtak ki (értsd: HTML + JavaScript + CSS). Ami még rosszabb az az, hogy a platformra (böngésző) nincs egyetlen szervezetnek valós ráhatása, illetve ha lenne is, drasztikusan átformálni szinte lehetetlen, hiszen nem húzhatjuk ki a létező megoldások alól a talajt.

Így aztán az történik, hogy megpróbálunk ruhát adni a szarra, szépen kidíszitjük és próbáljuk elfelejteni, hogy azért így is büdös. Ennek az eredménye a HTML5, a CSS3, a különböző MVVM frameworkök, a TypeScript, az új ECMAScript verziók és sok más amit nem fogok felsorolni.

El is érkeztünk a lényeghez: ahhoz, hogy ez a sok jó cucc működni tudjon mindenféle mágia szükséges ami egybetartja az egészet. Sajnos a mágia világában is a trendek uralkodnak, ennek megfelelően nagyjából kétévente új fasza gyerek jelenik meg a színen: korábban volt a Grunt, majd a Gulp amelyek többé-kevésbé fícsőr parity-ben voltak, majd megjelent a WebPack ami már lényegesen többet tudott náluk (dependency feloldás pl.). Itt egy jó kis összehasonlító írás: link.

A felsorolt eszközökben van egy közös pont: mindegyik open source. Ami egyébként hatalmas királyság, határozottan támogatok mindenféle open source törekvést. Viszont, mivel ezeket az eszközöket egy mindentől független közösség fejleszti, általában nem főállásban ezért a minőség ingadozó lehet. Ezzel együtt is minden tiszteletem ezeké a fejlesztőké, de a WebPack esetében például jól látható, hogy van egy innovatív, sokrétű termék, amit viszont túl nagy erőfeszítés úgy bekonfigurálni, hogy igazán jól működjön. A dokumentáció hiányos vagy már nem érvényes információt tartalmaz és végeredményben komoly mennyiségű időt kell ráfordítani arra, hogy felépítsük a fejlesztői környezetet.

Na de elég a nyavajgásból, csapjunk a lecsóba! Ebben a posztban teljesen az alapoktól fogunk építkezni, egyelőre bármiféle csicsa nélkül, vagyis: legyen dependency feloldás, bundling és minifikáció. Ez nem sok, de tanulságos.

Kezdjük a szokásos npm init-tel:

Majd ha ez megvan hozzuk létre az alábbi mappastruktúrát:

Az ‘app’ tartalmazza majd a javascript forráskódot, az assets-ben a saját CSS definíciók illetve képek lesznek, a dist pedig a bundle kimeneti mappája. Az ‘index.html’ végtelenül egyszerű lesz:

<!DOCTYPE html>
<html>
    <head>
        <title>WebPack Demo Application</title>
    </head>
<body>

<div id="content"></div>

<script type="text/javascript" src="dist/bundle.js"></script>
</body>

Természetesen mivel a bundle.js még nem létezik ezért böngészőben megnyitva konzolhiba lesz a jutalmunk meg persze a nagy büdös semmi Csináljunk is egy app.js nevű file-t az app mappába:

function createComponent(){
    var contentDiv = document.getElementById('content');
    contentDiv.innerHTML = '<h1>Hello WebPack!</h1>';
}
createComponent();

Nem egy nagy tudomány, de a célnak megfelel. A következő lépésünk, hogy telepítjük a WebPack-et: ‘npm i –save-dev webpack’ . Ezután készítsünk egy webpack.config.js nevű filet a package.json mellé, ez az amit a WebPack alapértelmezetten keresni fog:

var path = require('path');

module.exports = {
    entry: './app/app.js',
    output: {
        filename: 'bundle.js',
        path: path.resolve(__dirname, 'dist')
    }
};

Meglehetősen egyértelmű, hogy mi történik, az ‘entry’ szekció tartalmazza azt a filet ahonnan a függőségi gráf kiépítése indul, az output szekció pedig a kimeneti célt tartalmazza. A ‘__dirname’ környezeti változó az aktuális könyvtár elérési útja. Ha most lefuttatjuk a ‘webpack’ parancsot a könyvtárban, akkor el is készül a bundle:  

És a böngészőben is minden úgy működik ahogy szeretnénk:

Folytassuk CSS fileokkal, ezekből is szeretnénk egy bundle-t csinálni. Az ‘assets/css/’ mappába készítsünk egy ‘main.css’ nevű filet a következő tartalommal:

div {
    background-color: red;
}

Egészítsük ki az index.html-t is kicsit:

<!DOCTYPE html>
<html>
    <head>
        <title>WebPack Demo Application</title>
       	<link rel="stylesheet" href="dist/styles.css" />
    </head>
<body>

<div id="content"></div>
<script type="text/javascript" src="dist/bundle.js"></script>
</body>

Telepítsük a szükséges csomagokat az npm segítségével: ‘npm i –save-dev css-loader extract-text-webpack-plugin’.

Ahhoz, hogy a WebPack megtalálja a CSS fileokat azokat be kell importálni függőségként, adjuk is hozzá ezt az ‘app.js’-hez:

import '../assets/css/main.css';

function createComponent(){
    var contentDiv = document.getElementById('content');
    contentDiv.innerHTML = '<h1>Hello WebPack!</h1>';
}

createComponent();

Most pedig egészítsük ki a webpack.config.js-t, hogy a CSS fileokat is feldolgozza:

var path = require('path');
var ExtractTextPlugin = require('extract-text-webpack-plugin');

module.exports = {
    entry: './app/app.js',
    output: {
        filename: 'bundle.js',
        path: path.resolve(__dirname, 'dist')
    },
    module: {
        rules: [
            {
                test: /\.css$/,
                use: ExtractTextPlugin.extract({ use: 'css-loader' })
            }
        ]
    },
    plugins: [
        new ExtractTextPlugin('styles.css')
    ]
};

Ha lefuttatjuk ismét a ‘webpack’ parancsot már egy fokkal bőbeszédűbb lesz:

És persze a böngésző is reflektál a változásokra:

Mi van akkor, ha valamilyen third party könyvtárat, pl. Bootstrap-et akarok használni? Hasonló a felállás, először ugye a telepítéshez ‘npm i bootstrap’ parancs kell, majd a könyvtárat szintén be kell hivatkozni az előbb mutatott módon:

import 'bootstrap/dist/css/bootstrap.css';
import '../assets/css/main.css';

function createComponent(){
    var contentDiv = document.getElementById('content');
    contentDiv.innerHTML = '<h1>Hello WebPack!</h1>';
}

createComponent();

Itt a hivatkozás a node_modules mappára relatív történik, ez automatikusan bekerül a lehetséges mappák közé ahol a webpack a függőségeket keresi. Ha most lefuttatjuk a ‘webpack’ parancsot akkor elkezdhetjük vakarni a fejünket:

Ugye a Bootstrap nem csak CSS fileokat tartalmaz, hanem hoz magával mindenféle egzotikus dolgot is, például fontokat. Csakhogy a WebPack jelen állapotában nem tudja mit kezdjen ezekkel, így összefossa magát. Ez volt az a pont, ahol a dokumentáció megszívatott, ugyanis ott simán be volt hivatkozva a Bootstrap, csak elfelejtették megmondani, hogy az nem lesz elég. Persze értelmes hibaüzenetre sem fussa, pedig ebben az esetben egyértelműen kezelhető lenne a dolog, sőt igazából minden esetben oda is írta, hogy “You may need an appropriate loader” ami azt jelenti, hogy olyan pluginra van szükség ami elbír ezekkel a file típusokkal.

Oldjuk is meg, a ‘file-loader’ npm csomagra lesz szükség, és azt hiszem nem kell elmagyaráznom, hogy mit csinál  Ezt még be is kell kötni a WebPack konfigba, a következő módon:

var path = require('path');
var ExtractTextPlugin = require('extract-text-webpack-plugin');

module.exports = {
    entry: './app/app.js',
    output: {
        filename: 'bundle.js',
        path: path.resolve(__dirname, 'dist')
    },
    module: {
        rules: [
            {
                test: /\.css$/,
                use: ExtractTextPlugin.extract({ use: 'css-loader' })
            },
            {
                test: /\.(png|jpe?g|gif|svg|woff|woff2|ttf|eot|ico)$/,
                use: 'file-loader'
            }
        ]
    },
    plugins: [
        new ExtractTextPlugin('styles.css')
    ]
};

 Ezután már szépen lefut a webpack:

Utolsó napirendi pont a minifikálás ami a legkevésbé lesz fárasztó, ugyanis alapértelmezetten van a WebPack telepítésünkben ilyen képesség mégpedig az Uglify plugin személyében. Mindössze ki kell egészíteni a konfigurációt:

const webpack = require('webpack');
var path = require('path');
var ExtractTextPlugin = require('extract-text-webpack-plugin');

module.exports = {
    entry: './app/app.js',
    output: {
        filename: 'bundle.js',
        path: path.resolve(__dirname, 'dist')
    },
    module: {
        rules: [
            {
                test: /\.css$/,
                use: ExtractTextPlugin.extract({ use: 'css-loader' })
            },
            {
                test: /\.(png|jpe?g|gif|svg|woff|woff2|ttf|eot|ico)$/,
                use: 'file-loader'
            }
        ]
    },
    plugins: [
        new ExtractTextPlugin('styles.css'),
        new webpack.LoaderOptionsPlugin({
            minimize: true,
            debug: false
        }),
        new webpack.optimize.UglifyJsPlugin({
            beautify: false,
            mangle: {
                screw_ie8: true,
                keep_fnames: true
            },
            compress: {
                screw_ie8: true
            },
            comments: false
        })
    ]
};

 Újabb webpack futtatás után látható, hogy bizony csökkentek a fileméretek:

Nos hát mára ennyi lenne a műsor legközelebb csinálunk külön fejlesztői/release konfigurációkat, illetve elTypeScriptesítjük magunkat.

]]> https://reiteristvan.wordpress.com/2017/05/01/webpackolas-numero-uno/feed/ 0 reiteristvan 1o7dyu Capture.PNG 1.PNG 2 3 4 5 6 https://reiteristvan.wordpress.com/2017/02/27/hogyan-csereljuk-le-a-ceges-lock-screen-t/ https://reiteristvan.wordpress.com/2017/02/27/hogyan-csereljuk-le-a-ceges-lock-screen-t/#respond Mon, 27 Feb 2017 14:00:54 +0000 http://reiteristvan.wordpress.com/?p=1131 …

Read more ›

]]> Az alábbi kis program lecseréli a munkahelyen ránk erőltetett lock screen-t a Bing napi képére (cicás/kutyás/naplementés). Task Schedulerben napi futásra beütemezve máris színesebb lesz az életünk. A fordításhoz NewtonSoft.Json nuget csomag szükséges. Természetesen futtatása nem ajánlott, hiszen a céges policy az céges policy

using System;
using System.Collections.Generic;
using System.IO;
using System.Net.Http;
using Microsoft.Win32;
using Newtonsoft.Json;

namespace LogMeOutPolicyScreen
{
    class Program
    {
        private const string BingUrl = "http://www.bing.com";
        private const string BingDailyImage = "http://www.bing.com/HPImageArchive.aspx?format=js&idx=0&n=1&mkt=en-US";
        private const string PersonalizationEntryKey = @"SOFTWARE\Policies\Microsoft\Windows\Personalization";
        private const string LockScreenImageKey = "LockScreenImage";
        private const string ScreenImagePath = @"C:\Windows\Web\Screen";

        static void Main()
        {
            RegistryKey personalizationKey = Registry.LocalMachine.OpenSubKey(PersonalizationEntryKey, true);

            if (personalizationKey == null)
            {
                return;
            }

            string newImage = DownloadDailyBingImage();

            personalizationKey.SetValue(LockScreenImageKey, newImage);
        }

        private static string DownloadDailyBingImage()
        {
            using (HttpClient client = new HttpClient())
            {
                string dailyImage = client.GetStringAsync(BingDailyImage).Result;
                DailyImageResponse response = JsonConvert.DeserializeObject<DailyImageResponse>(dailyImage);

                string imageUrl = $"{BingUrl}/{response.Images[0].Url}";
                byte[] imageBytes = client.GetByteArrayAsync(imageUrl).Result;

                string imagePath = $"{ScreenImagePath}\\{Guid.NewGuid()}.jpg";

                File.WriteAllBytes(imagePath, imageBytes);

                return imagePath;
            }
        }
    }

    public sealed class DailyImageResponse
    {
        [JsonProperty("images")]
        public List<DailyImageEntry> Images { get; set; }
    }

    public sealed class DailyImageEntry
    {
        [JsonProperty("url")]
        public string Url { get; set; }
    }
}

]]> https://reiteristvan.wordpress.com/2017/02/27/hogyan-csereljuk-le-a-ceges-lock-screen-t/feed/ 0 reiteristvan

Alapfelállás: Visual Studio 2015 és két korábbi DotNet Core SDK (003* verzióval). A VS 2017 RC-t leszedtem, hiszen úgyis jön a végleges változat, majd azt használom. A cikk szerint nekem az “rc4 build 004771” kell amire egyelőre csak a GitHub oldalról van hivatkozás, a hivatalosnak tekinthető letöltő oldalról csak a 003* verziók érhetőek el.

Szóval, SDK telepítve, parancssorból dotnet –version jó adatot ad vissza örülés, a sablonok is felmásztak szépen (lásd a cikket). Viszont, ezt csak péntek reggel munka előtt csináltam, gondolván, hogy hétvégére felkészülök ne kelljen már szerencsétlenkedni vele. Eljön a szombat, kiadom szépen a parancsot, hogy készítsen nekem egy react/redux projektet mire visszakapom, hogy ez nem fog menni, mert ilyen sablon nincs. Biztos elgépeltem. Nem. Nézem a dotnet verziót, mire kiderül, hogy szépen visszaállt a korábbira. Sdk a helyén pedig, csak a verzió nem stimmel. Nem baj, biztos lehet váltani parancssorból. Lófaszt. Biztos én vagyok hülye, próbálok mindenféle kicsavart változatban keresni. Semmi. Dokumentációban semmi. Végső elkeseredésemben átnyálazom GitHub-on a forráskódot. Ott sincs semmi. Továbbra is lehet, hogy csak én nem találom, de úgy tűnik, hogy csak akkor lehet explicit megadni a dotnet verziót HA elkészült a projekt, de nem futtathatom a CLI-t nekem tetsző környezetben. Furcsa, ha esetleg valaki tudja a megoldást ne restellje beírni a kommentek közé.

B terv, újratelepítem a 004771-et az egyszer már bevált. Repair gyorsan lefut, parancssorban ott virít a megfelelő verziószám. Indítok egy Powershell-t, beírom megint a parancsot, megint semmi, ilyen sablon nincs. Nem baj, gondoltam a repair kitakarította a template raktárat, de a biztonság kedvéért azért megnézem, hogy milyen verzión vagyok. Visszaállt 003*-ra. Hajtépés.

C terv, velem nem csesztek ki, leszedem a másik két fent lévő RC Sdk-t. Lőn. Működik. Örülés.

Új projekt elkészült, és egyébként most erről nem írtam de az előregyártott sablonok rohadt jók, szépen be van állítva minden, teljesen enterspájz ready az egész, csak ajánlani tudom. DE. Visual Studio megnyit, Add Existing Project, nem addig-a, ez a project nem lesz jó ide. Mint kiderült, az új projekt sablonok csak VS 2017 alá jók, ami számomra totálisan érthetetlen. Oké, hogy új DotNetKór, de ha már van támogatás rá VS2015-ben akkor miért nem lehet visszafelé is kompatibilisnek lenni? Nem érzem, hogy technológiai akadálya lenne. Meg eleve furcsa, hogy ugyan csinálhatok Core projektet VS2015-ben is, de akkor ezek szerint van olyan projekt típus ami már nem kompatibilis vele. Ilyenkor mi van? Lehet, hogy lesz egy update ami majd megoldja ezt a problémát, de akkor tessék már ezt szinkronba hozni a csillivilli fasza cuccok kiadásával.

Amúgy, megoldás ami ugyan fapados, de egyelőre működik: a kliens oldali fejlesztéshez nem használok Visual Studio-t, arra úgyis jobb a Code, de így meg igazából ugyanott vagyok ahova bármely másik sablonkezelővel eljutottam volna.

És ami igazán szomorú, hogy maga az egész DotNetCore mocskosul király, csak amikor órákig szopatnak a tooling hiányosságai akkor lekonyul kicsit az ember mosolya. Mindenesetre még türelmes vagyok, jó dolgok készülnek, csak ki kell várni.

Vágjunk is bele, az első páciens a .NET fejlesztők kedvence lesz: mi a különbség érték- és referencia típusok között? Erre a sablon totálisan PC válasz szokott jönni:

Az értéktípusok a stack-en, a referenciatípusok a heap-en jönnek létre.

Ez a válasz, amellett, hogy hibás, totálisan semmitmondó is. Nagyjából bármelyik C# könyvben megtalálható valamilyen formában, viszont értéke ilyen formában nincs.

Mi az a stack és heap?

Ez például egy tök jó kérdés, mert ez már nem szokott benne lenni a könyvekben. Az első, amit le kell szögezni, hogy ez a két fogalom egyáltalán nem .NET specifikus, bármelyik platformon értelmezve vannak, pontosabban nem is a platformon, hanem a számítógépen.

Kezdjük a heap-el, mert az egyszerű, pongyolán megfogalmazva ez nem más mint a nyers memória ami a számítógépbe dugott RAM lapkákban él. Egyelőre ennyit erről, ide még visszatérünk.

A stack SOKKAL érdekesebb dolog. Ismét pongyolán kezdünk, kis türelmet kérek. Amikor a számítógép végrehajt egy programrészt (hívjuk ezt most függvénynek), lefoglal egy memóriaterületet az adott függvény lokális adatainak. Ez a memóriaterület nem más mint a stack. A stack nevéhez méltóan ténylegesen egy verem adatstruktúra ami LIFO (Last-in-first-out) módon működik. Amikor a függvény futása véget ér ez a memóriaterület is megszűnik létezni, így nem kell törődni a memória menedzsmenttel. Nem beszélve arról, hogy a stack-en való adattárolás villámgyors.

Nézzük meg, hogy mit jelent ez a gyakorlatban, először IL szinten. Ehhez a TryRoslyn-t fogjuk használni, ami kényelmes valós idejű IL-re fordítást tesz lehetővé. Vegyük az alábbi forráskódot, ami összead két számot és az eredményt eltárolja egy harmadik változóban:

static void Main()
{
    int x = 10;
    int y = 20;
    int z = x + y;

    Console.ReadLine();
}

Ebből az alábbi IL generálódik:

    .method public hidebysig static
        void Main () cil managed
    {
        .maxstack 2
        .locals init (
            [0] int32,
            [1] int32,
            [2] int32
        )

        IL_0001: ldc.i4.s 10
        IL_0003: stloc.0
        IL_0004: ldc.i4.s 20
        IL_0006: stloc.1
        IL_0007: ldloc.0
        IL_0008: ldloc.1
        IL_0009: add
        IL_000a: stloc.2
        IL_000b: call string [mscorlib]System.Console::ReadLine()
        IL_0010: pop
        IL_0011: ret
    }

Az IL önmaga is egy stack alapú assembly szerű nyelv, igazából a generált kód nagyon hasonlít koncepciójában a valóban lefutó assembly kódra, azt is megnézzük mindjárt. A .locals lista felsorolja a függvényen belüli lokális változókat, amelyeket majd az indexükkel ér el. A programunk tényleges első sora rögtön egy nagyon érdekes dolog, az ldc.i4.s utasítás egy 32 bites előjeles egész számot helyez el a stackben. Ami érdekes benne az az, hogy itt rögtön egy jópofa optimalizálást láthatunk, a .s ugyanis azt jelenti, hogy a szám amit a verembe teszünk egy 8 bites előjeles egész szám vagyis a nem túl gyakran használt .NET adattípus a System.SByte. A fordító észlelte, hogy egy alacsony értéket használunk és ennek megfelelően elvégezte az optimalizálást, ugyanis az ldc.i4.s jobb performanciával teljesít, mint a “rendes” 32 bites számot a verembe helyező ldc.i4 utasítás.

Az stloc.X az X indexen felvett lokális változóba tölti a veremben lévő legfelső értéket, tehát egyúttal el is távolítjuk azt. Ugyanezt megtesszük a másik változóval is, majd jöhet az összeadás. Az add utasítás kiveszi a veremből a felső két értéket amelyeket az stloc párjával az ldloc-kal töltöttünk be, összeadja őket, majd visszahelyezi az eredményt a verembe.

Láttuk tehát, hogy hogyan működik a verem az IL szintjén, de mehetünk lejjebb is, most nézzük meg, hogy milyen assembly forráskód generálódik ebből:

02912E5B  xor         edx,edx
00BB2E5D  mov         dword ptr [ebp-40h],edx
00BB2E60  xor         edx,edx
00BB2E62  mov         dword ptr [ebp-3Ch],edx
00BB2E65  xor         edx,edx
00BB2E67  mov         dword ptr [ebp-44h],edx
00BB2E6A  nop
            int x = 10;
00BB2E6B  mov         dword ptr [ebp-3Ch],0Ah
            int y = 20;
00BB2E72  mov         dword ptr [ebp-40h],14h
            int z = x + y;
00BB2E79  mov         eax,dword ptr [ebp-3Ch]
00BB2E7C  add         eax,dword ptr [ebp-40h]
00BB2E7F  mov         dword ptr [ebp-44h],eax  

            Console.ReadLine();
00BB2E82  call        6CE47098

Felteszem, hogy nem minden olvasóm ismeri vagy használja aktívan az assembly-t (én sem, csak szakbarbár módjára), úgyhogy próbálok csak a lényegre szorítkozni. Az assembly szintjén a processzorban lévő tárolókat, úgynevezett regisztereket használunk, amelyek alapvetően egy értéket képesek tárolni (ez nem teljesen igaz, de most lényegtelen). Vannak általános célú regiszterek mint az eax, és vannak speciális regiszterek is. Ilyen spec. regiszter az esp ami a stack-pointer (az e extended-et jelent) és az aktuális verem tetejére mutat. Az ebp regisztert a program futásának elején az esp-re szokás állítani, majd a későbbiekben ennek segítségével lehet navigálni a veremben. Itt persze kis csalás van, mert így úgy tehetünk, illetve vehetünk elemet a veremből, hogy nem távolítjuk el azt.

A program elején azt látjuk, hogy a mov utasítással az ebp-40h  (a hexadecimális 40 egész véletlenül 64 tízes számrendszerben) címen lévő dword (double word vagyis 32 bit) méretű memóriaterületre mozgatja az edx regiszter értékét amelyet az első sorban a xor edx,edx utasítással nulla értékre állítottunk (ez a leggyorsabb módja egy regiszter nullázására, a xor mindig gyorsabb mint a mov).

Gyakorlatilag tehát annyit csinálunk, hogy memóriát foglalunk három 32 bites értéknek, vagyis nem tettünk mást, mint felvettük a három lokális változót és az értéküket nullára állítottuk. Innentől már tényleg egyszerű az egész, bemozgatjuk X értékét az eax regiszterbe, majd az add utasítással hozzáadjuk az Y értékét, végül az eredményt bemásoljuk a Z változónak fenntartott memóriaterületre.

Nagyjából lehet most már fogalmunk, arról, hogy mi a verem, illetve, hogy hogyan működnek a lokális  értéktípusú változók.

A cikk elején azt mondtam, hogy a jól ismert válasz:

Az értéktípusok a stack-en, a referenciatípusok a heap-en jönnek létre.

hibás. Ugyanis, valójában mindkét állítás cáfolható. Referenciatípus stack-en? Van ugyanis egy speciális referenciatípus: a string. Vegyük a következő C# forráskódot:

static void Main()
{
    string s1 = "alma";
    string s2 = new String('a', 12);

    Console.ReadLine();
}

Erre én azt mondom, hogy s2 a heapen létezik, s1 pedig …? Nézzük a generált IL-t:

    .method public hidebysig static
        void Main () cil managed
    {
        .maxstack 2
        .locals init (
            [0] string,
            [1] string
        )

        IL_0001: ldstr "alma"
        IL_0006: stloc.0
        IL_0007: ldc.i4.s 97
        IL_0009: ldc.i4.s 12
        IL_000b: newobj instance void [mscorlib]System.String::.ctor(char, int32)
        IL_0010: stloc.1
        IL_0011: call string [mscorlib]System.Console::ReadLine()
        IL_0016: pop
        IL_0017: ret

Rögtön az elején ott van az “alma” string, amelyet az ldstr utasítás helyez el a verem tetején majd ezt tárolja az első lokális változóban. Ez bizony akárhogy is nézzük nem úgy néz ki mintha a heapen lenne. A másik string már érdekesebb, először elhelyezzük a veremben a 97 (ami a kis ‘a’ betű) és 12 értékeket, majd ezzel a két paraméterrel meghívjuk a System.String egyik konstruktorát. Itt a newobj gondoskodik arról, hogy a konstruktor által létrehozott objektumra mutató referencia bekerüljön a verembe, majd ez a referencia tárolódik a második lokális változónkban.

Még mindig van tovább, assembly time! Ez lett:

    10:             string s1 = "alma";
00E12E66 8B 05 0C 23 94 03    mov         eax,dword ptr ds:[394230Ch]
00E12E6C 89 45 C4             mov         dword ptr [ebp-3Ch],eax
    11:             string s2 = new String('a', 12);
00E12E6F 6A 0C                push        0Ch
00E12E71 33 C9                xor         ecx,ecx
00E12E73 BA 61 00 00 00       mov         edx,61h
00E12E78 E8 1B 26 84 6B       call        6C655498
00E12E7D 89 45 BC             mov         dword ptr [ebp-44h],eax
00E12E80 8B 45 BC             mov         eax,dword ptr [ebp-44h]
00E12E83 89 45 C0             mov         dword ptr [ebp-40h],eax

Az “alma” értékadás a következőképpen történt: van egy speciális memóriaszegmens, a ds vagyis data segment. Itt tárolódnak többek között az olyan beégetett értékek mint az “alma”. A ds-ből előszedjük a string címét ami ismét egy 32 bites érték. Nézzük a másik oldalt. Ebben az esetben a call 6C655498  sor fontos, ugyanis ez meghívja a paraméter által mutatott függvényt, jelen esetben ez nem más mint a string konstruktora, majd a visszakapott címet szintén eltárolja a veremben.

Technikailag ugyan az első string nem teljesen van a veremben, hiszen fizikailag máshol létezik, ugyanakkor nem is tekinthető teljesen referenciatípusnak sem.

Innen folytatjuk a következő részben a boxinggal amikor fény derül arra, hogy mi történik ezzel a hibrid string objektummal és, hogy mikor lesz egy értéktípusból referenciatípus.

]]> https://reiteristvan.wordpress.com/2016/05/01/interjukerdesek-demisztifikalva-ertek-es-referenciatipusok-1/feed/ 5 reiteristvan https://reiteristvan.wordpress.com/2015/11/01/tiszta-kod-miert-rossz-a-var/ https://reiteristvan.wordpress.com/2015/11/01/tiszta-kod-miert-rossz-a-var/#comments Sun, 01 Nov 2015 15:00:41 +0000 http://reiteristvan.wordpress.com/?p=1023 …

public sealed class UserRepository : IUserRepository
{
    public IEnumerable<User> GetUsers()
    {
        // ..
    }
}

public sealed class UserServices
{
    private readonly IUserRepository _userRepository;

    public UserServices(IUserRepository userRepository)
    {
        _userRepository = userRepository;
    }

    public void ManipulateUsers()
    {
        var users = _userRepository.GetUsers();
    }
}

public void ManipulateUsers()
{
    var users = _userRepository.GetUsers().ToList();
}

Szóval, a fent leírt eset a következőt csinálja: ha a Razor kódban megjelenik a Html.AntiForgeryToken() sor, akkor két dolog történik: az oldal HTML kódjában keletkezik egy rejtett input mező és ezzel párhuzamosan egy cookie is kimegy a válasszal amelynek élettartama a session-re korlátozódik. Ez a két token együtt utazik majd vissza amikor bemegy a – mondjuk – kitöltött űrlap és a megcélzott függvényen lévő ValidateAntiforgeryToken attribútum összehasonlítja ezt a két tokent az általa ismertekkel, így megerősítve, hogy valóban megfelelő forrásból érkezett az adat.

Ezek a dolgok mind szerveroldalon történnek, mivel a Razor kód is ott fordul át “rendes” HTML-re. SPA esetén egy kicsit más a helyzet, mivel a HTML mind kliens oldalon létezik, a szerver nem fog belenyúlni. Találnunk kell tehát egy olyan megoldást, ami biztonságos ugyanakkor könnyen használható.

A kész forráskódot letölthetitek innen: http://1drv.ms/1V9wbZj

Szerveroldalon marad tehát a validálás, ehhez ugyanazt az infrastruktúrát fogom használni, mint amit az MVC beépítetten, csak rakok köré pár dolgot. Az alapkoncepció a következő lesz: készítek egy végpontot az API-mban, ami visszaad egy token-t, illetve egy sütit, ezáltal hozzájutok a nekem kellő adatokhoz. Ez a rész elég egyszerűen megvalósítható, arra kell figyelni, hogy cookie tokent csak a session kezdetén kapunk, utána ugyanazt fogjuk használni a session élettartama alatt, illetve új token generálásakor meg kell adnunk a cookie tokent a generáló függvénynek. Ha ekkor még nincs cookie token (tehát ez az első kérés), akkor üres string megy be:

[HttpGet]
[Route("antiforgerytoken")]
public HttpResponseMessage GetAntiForgeryToken()
{
    HttpResponseMessage response = new HttpResponseMessage(HttpStatusCode.OK);

    HttpCookie cookie = HttpContext.Current.Request.Cookies["xsrf-token"];

    string cookieToken;
    string formToken;
    AntiForgery.GetTokens(cookie == null ? "" : cookie.Value, out cookieToken, out formToken);

    AntiForgeryTokenModel content = new AntiForgeryTokenModel
    {
        AntiForgeryToken = formToken
    };

    response.Content = new StringContent(JsonConvert.SerializeObject(content), Encoding.UTF8, "application/json");

    if (!string.IsNullOrEmpty(cookieToken))
    {
        response.Headers.AddCookies(new[]
        {
            new CookieHeaderValue("xsrf-token", cookieToken)
            {
                Expires = DateTimeOffset.Now.AddMinutes(10),
                Path = "/"
            }
        });
    }

    return response;
}

A válaszhoz hozzácsapjuk azt a tokent, ami eredetileg az űrlapba ágyazódna. Ezzel a résszel meg is vagyunk, következő lépés a kliens oldal lesz. Az Angular nagyon praktikusan támogat ún. direktívákat amelyek lehetővé teszik, hogy egy HTML elemet viselkedéssel ruházzunk fel, ez nekünk nagyon jól jön, mivel így egyetlen sorral be tudjuk szúrni a megfelelő helyre a tokent. A direktíva maga hívja meg az előbb készített végpontot és egy rejtett input mezőben fog megjelenni a HTML forrásban:

(function() {
    'use strict';

    function antiForgeryDirectiveController(appService) {
        var directive = this;

        directive.antiForgeryToken = '';

        directive.activate = function () {
            appService.getAntiForgeryToken().then(function(data) {
                directive.antiForgeryToken = data.antiForgeryToken;;
            });
        };

        directive.activate();
    }

    function antiForgeryTokenDirective() {
        return {
            scope: {},
            controllerAs: 'directive',
            template: '<input id="__antiForgeryToken" name="antiForgeryToken" type="hidden" value="{{directive.antiForgeryToken}}" />',
            controller: [ 'appService', antiForgeryDirectiveController ]
        }
    }

    angular.module('demoApp').directive('antiforgerytoken', antiForgeryTokenDirective);
})();

Az appService tartalmazza az API hívásokat. Innentől kezdve nagyon egyszerű dolgunk van, csak be kell szúrnunk a direktívánkat ahova szeretnénk:

</pre>
<form>
<div></div>
<fieldset>
<div class="control-group"><label class="control-label" for="email">Email</label>
<div class="controls"><input id="email" class="input-xlarge" name="email" type="text" placeholder="" /></div>
</div>
<div class="control-group"><label class="control-label" for="password">Password</label>
<div class="controls"><input id="password" class="input-xlarge" name="password" type="password" placeholder="" /></div>
</div>
<div class="control-group">
<div class="controls"><button class="btn btn-success">Log In</button></div>
</div></fieldset>
</form>
<pre>

Egyetlen lépés maradt kliens oldalon, mégpedig a direktívával beszúrt token visszaküldése a szervernek. A cookie automatikusan hozzácsapódik a kérésekhez, ezt viszont nekünk kell megtennünk. Újabb Angular fícsőrt használunk fel, készítünk egy http interceptort, amely – ha az aktuális lap forráskódja tartalmazza – egy HTTP fejlécben továbbítja a tokent a szervernek:

(function() {
    'use strict';

    function antiForgeryInterceptor() {
        return {
            request: function($config) {
                var antiForgeryTokenField = document.getElementById('__antiForgeryToken');
                if (antiForgeryTokenField) {
                    var xsrfToken = antiForgeryTokenField.value;
                    $config.headers['XSRF-TOKEN'] = xsrfToken;
                }

                return $config;
            }
        };
    }

    angular.module('demoApp').service('antiForgeryInterceptor', antiForgeryInterceptor);
})();

Az utolsó lépés a szerveroldali ellenőrzés, ehhez egy filtert készítünk, ami egyszerűen meghívja a korábban használt beépített anti-XSRF szolgáltatást a süti és fejléc tokenekkel:

public sealed class ValidateAntiForgeryTokenFilter : ActionFilterAttribute
{
    private const string XsrfHeader = "XSRF-TOKEN";
    private const string XsrfCookie = "xsrf-token";

    public override void OnActionExecuting(HttpActionContext actionContext)
    {
        HttpRequestHeaders headers = actionContext.Request.Headers;
        IEnumerable xsrfTokenList;

        if (!headers.TryGetValues(XsrfHeader, out xsrfTokenList))
        {
            actionContext.Response = new HttpResponseMessage(HttpStatusCode.BadRequest);
            return;
        }

        string tokenHeaderValue = xsrfTokenList.First();

        CookieState tokenCookie = actionContext.Request.Headers.GetCookies().Select(c => c[XsrfCookie]).FirstOrDefault();

        if (tokenCookie == null)
        {
            actionContext.Response = new HttpResponseMessage(HttpStatusCode.BadRequest);
            return;
        }

        try
        {
            AntiForgery.Validate(tokenCookie.Value, tokenHeaderValue);
        }
        catch (HttpAntiForgeryException)
        {
            actionContext.Response = new HttpResponseMessage(HttpStatusCode.BadRequest);
        }
    }
}

Ezt a filtert pedig használhatjuk az MVC-ben megszokott módon.

Sebaj, a Resharper felajánlotta, hogy átállítja a projektet C# 6-ra, amit meggondolatlanul meg is engedtem neki, viszont úgy határoztam, hogy nekem mégis a C# 5 kell. Kérdés, hogyan állítom vissza a verziót? Megoldás: klikk a projekten (sima bal klikk), majd Properties fül megnyitása és ott lesz egy C# Language Level property ahol kiválaszthatjuk a megfelelő fordítót. A VS 2013 Default értéke a C# 5.

Utólag kiderült, hogy a Resharper a névtér behivatkozáskor sunyi módon hozzáadta a projekthez magát a projektet referenciaként, így fordításkor egyrészt megtalálja az eredeti függvényt, másrészt ugyanennek a függvénynek a hivatkozott referenciában lévő változatát is, ezzel jó kis kavarodást okozva. A megoldás természetesen a referencia eltávolítása. Jópofa bug ez, és ami zavaró, hogy simán reprodukálható, illetve az, hogy ez csak egyetlen interfész kiegészítésén keletkezik (névleg az IPrincipal), van más extension mehod is a projektben, azokkal ilyen nem fordult elő. Két különböző gépen is próbáltam és folyamatosan csinálja.

A probléma a legfrissebb Resharper-t is érinti, rémlik, hogy korábbi verziók is csináltak ilyesmit.

Vágjunk  hát bele, először telepítsük a Microsoft.AspNet.WebApi.Owin nuget csomagot, ami magával hozza az Owin core csomagot is. Itt álljunk meg és nézzük meg a nuget update fület, mivel alapértelmezetten a WebApi.Owin egy egész major verzióval le van maradva a core csomag terén, így azt frissítsük gyorsan (jelenleg ez a 3.0.1 verziót jelenti).

Második lépésként az App_Start mappába (máshova is lehet én ide raktam) tegyünk egy Startup.cs nevű osztályt, ami majd az Owin belépési pontja lesz. Lehet máshogy is hívni, elvileg a Startup.cs lenne az amit az Owin keres (erről mindjárt), de igazából ez most mindegy. Az én Startup.cs-m így néz ki, csak az a minimum konfiguráció van benne ami a Web API működéséhez kell.

public class Startup
{
    public void Configuration(IAppBuilder app)
    {
        HttpConfiguration httpConfiguration = new HttpConfiguration
        {
            DependencyResolver = new WebApiUnityDependencyResolver(UnityDependencyRegistrations.RegisterDependencies())
        };

        WebApiConfig.Register(httpConfiguration);

        app.UseWebApi(httpConfiguration);
    }
}

A DependencyResolver a szokásos módon működik, én egy az egyben használom amit eddig is, minden olyan DI könyvtár működni fog ami Web API-val működött, nem igényel semmilyen extra beállítást. A UnityDependencyRegistrations.RegisterDependencies() saját gyártmány, akárcsak a WebApiUnityDependencyResolver, elöbbi legyárt egy unity konténert a megfelelő típusregisztrációkkal, utóbbi meg a normál dependency resolver (gyakorlatilag egy az egyben ugyanaz ami az asp.net oldalon a tutorialban van).

Ezen a ponton majdnem kész vagyunk, ideje kivágni a felesleget. A Global.asax.cs-ből szedjük ki a

GlobalConfiguration.Configure(WebApiConfig.Register);

sort, mivel innentől kezdve a Web API infrastruktúránkat az Owin fogja vinni.

Most jön a vicces rész. Mivel az alkalmazásunk nem tudja hogy kell Owin-t futtatni, ezért hozzá kell adnunk még egy nuget csomaghoz a projekthez, ez a Microsoft.Owin.Host.SystemWeb ami egyébként fel fogja frissíteni az Owin core-t ha eddig nem tettük még meg. Na most, az volt a mondás, hogy az Owin majd jól megtalálja a Startup.cs-t, vagy ha nagyon szorgalmas az ember akkor rakja rá az OwinStartup attribútumot és akkor minden fasza lesz. Nos, hölgyeim és uraim minket rútul becsaptak, a kis piszok cseszik megtalálni, ha ezen a ponton elindítjuk az alkalmazást akkora sárga halál lesz belőle mint a szél. Viszont! Informatív hibaüzenetet kapunk, valódi megoldással, névlegesen fel kell venni egy appSetting-et a web.config-ba, a következő módon (fully qualified name kell):

<add key="owin:AppStartup" value="MyProject.MyStartup, MyProject"/>

Készen is vagyunk, lehet owinozni amennyit csak szeretnénk. Ami plusz jó az egészben, hogy az átállás lehet fokozatos, például ha a global.asax.cs-ben meghagytuk az authentikációs logikát akkor az továbbra is működőképes marad.