Category: Tipy, triky

Hyper-V uvnitř Hyper-V, aneb nested virtualization

Windows 10 Anniversary Update a Windows Server 2016 podporují v Hyper-V tzv. „nested virtualization“, tedy virtualizaci uvnitř jiné virtualizace. Donedávna to bylo pro Hyper-V nemožné a bránilo to například provozování mobilních emulátorů ve virtuálních strojích.

Dnes je ale situace jiná, nested virtualizaci je možné aktivovat pomocí PowerShellu.

  1. Ujistěte se, že máte aktivované Hyper-V a k němu Hyper-V Module for Windows PowerShell.
    1. Dá se nainstalovat přes Programs and Features > Turn Windows features on or off > Hyper-V > Hyper-V Management Tools (mám Windows v angličtině).
  2. Vytvořte v Hyper-V virtuální stroj, jako obyčejně.
    1. Ale musí běžet na Windows 10 Anniversary nebo Windows Server 2016
  3. Spusťte PowerShell na hostitelském počítači (na tom, z něhož budete virtuální stroj spouštět).
  4. Vypište si cvičně seznam virtuálek:
    Get-VM

  5. A aktivujte virtualizaci:
    Set-VMProcessor -VMName <nazev> -ExposeVirtualizationExtensions $true

A to je vše. Nyní stačí jen virtuální stroj spustit a také do něj doinstalovat Hyper-V.

Poznámky

Vypnout nested virtualization:

Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $false

Aktivovat MAC Address Spoofing:

Get-VMNetworkAdapter -VMName <VMName> | Set-VMNetworkAdapter -MacAddressSpoofing On

Ngrok – tunelujeme do localhostu

Jsou situace, kdy se hodí nabídnout svůj localhost na internetu. Třeba když vám na počítači běží chatbot a chcete ho přidat na Skype a otestovat ve skutečném klientovi. Nebo když si nejste jistí, zda mobilní emulátor správně komunikuje s lokální sítí.

V poslední době jsem si oblíbil Ngrok, nástroj, který dokáže takový tunel vykopat. Funguje velmi jednoduše – stáhnete si utilitku pro Windows, Linux nebo Mac, přidáte cestu k ní do PATH a pak jenom v příkazové řádce napíšete:

ngrok http 3678

image

Ngrok vám vygeneruje HTTP i HTTPS adresy a zajistí, že požadavek na ně se přes jeho servery protuneluje na localhost, na port 3678. Na obrázku je také vidět, jak se logují příchozí požadavky.

Tyto adresy nejsou perzistentní, takže jakmile Ngrok restartujete, dostanete nové. Stálé adresy jsou součástí placeného plánu.

Poznámka na konec: vyskakují-li v reakci na požadavky chyby jako „400 Bad Request“, nejspíš máte špatně nastavený Host Header. Řešení je prosté:

ngrok http [port] -host-header="localhost:[port]"

Případně:

ngrok http [port] -host-header=rewrite

UWP: Nezobrazí se Share UI

Tenhle problém dokáže pěkně potrápit. V jedné aplikaci jsem generoval obrázek, spojoval ho s Inkem a následně přes Share contract nabízel ke sdílení třeba do mailové aplikace. V emulátoru i na skutečném telefonu všechno fungovalo, dokud byl připojený debugger, nicméně když jsem aplikaci spustil rovnou ze seznamu, Share UI se nezobrazilo a nevyskočila ani žádná chyba.

Continue reading

Tip: Černá obrazovka u Android emulátoru

Visual Studio nabízí super Android emulátor postavený na Hyper-V (on se tedy dá používat i samostatně, bez VS, ale s ním je to samozřejmě lepší :) ). Stala se mi ale po spuštění taková nemilá věc – místo Androidu se zobrazila jenom černá obrazovka. Virtuální stroj běžel, debug se taky připojil, ale nebylo nic vidět.

Nakonec pomohlo vypnout OpenGL v souboru C:\Program Files (x86)\Microsoft XDE\10.0.10586.0\SKUs\Android\xdesku, odstraněním atributu:

GuestDisplayProvider="VsEmulator.OpenGLGuestDisplay"

UWP: Ikona sdílení

Pokud implementujete Share Contract ve Windows 10 (konkrétně UWP), musíte sdílení nějakým způsobem vyvolat. Pokud si zvolíte tlačítko na panelu CommandBar, brzy zjistíte, že XAML přímo ikonu pro sdílení nenabízí („ReShare“ není ono). Nezbývá tedy než vyhrnout rukávy a zabrousit do fontu Segoe MDL2 Assets:

<AppBarButton Label="Share" Click="Share_Click">
   <AppBarButton.Icon>
      <FontIcon FontFamily="Segoe MDL2 Assets" Glyph="&#xE72D;"/>
   </AppBarButton.Icon>
</AppBarButton>

Ten totiž obsahuje spoustu zajímavých ikon, které se používají napříč Windows 10.

segoe-ui-mdl2

Tip: Jak vynutit schválení oprávnění pro Azure AD

Modelová situace: Používám webovou aplikaci, která volá API Microsoft Graph a čte data z Office 365. V Azure Active Directory si řekla o sadu oprávnění (třeba čtení a zápis mého kalendáře a e-mailové schránky) a já jsem je schválil při prvním přihlášení.

Za půl roku se API rozšířilo a přibylo nové oprávnění, třeba například čtení kalendářů místností. Autor aplikace jej v Azure Active Directory přidal, nicméně můj uživatelský profil s ním nepočítá – schválil jsem před půl rokem něco jiného.

Tato situace je běžná i při vývoji – měním postupně scope aplikace, přidávám nová oprávnění potřebuji testovat, jak se chovají, nechci pořád dokola odebírat aplikaci z AD a znovu ji přidávat.

Jak z toho ven?

&prompt=consent

Tento parametr stačí přidat k URL přihlašovací stránky Azure Active directory.

prompt-consent

Znovu stránku načíst, přihlásit se a objeví se nové „consent“ okno, kde už budou i nová oprávnění, která postupně do aplikace přibyla:

ad-opravneni Hotovo.

Testování Office add-inů na Macu

Doplňky Office už na Macu fungují. Co když ale chcete testovat aplikaci, kterou ještě nemáte ve Storu? Jde to, ale není to úpně intuitivní.

Microsoft minulý týden na Buildu oznámil, že doplňky Office fungují i v klientských aplikacích pro Mac OS. Uživatelé si tak mohou do svých Wordů, Excelů i PowerPointů instalovat doplňky z Office Storu, o nichž vývojáři prohlásili, že jsou připravené a funkční pro Mac. Aby to ale mohli s čistým svědomím udělat, musí je nejprve na jablečné platformě otestovat. Klasický sideloading přes sdílenou složku nebo app catalog, které známe z Windows, použít nejdou a nezbývá než se uchýlit k ruční práci.

Vezměte svůj soubor s manifestem (<cokoliv>.xml) a nahrajte ho do složky:

/Users/<username>/Library/Containers/com.microsoft.Word/Data/Documents/wef

Pokud wef neexistuje, je potřeba ji ručně vytvořit třeba pomocí mkdir.

A pak nakopírovat soubor třeba takto:

cp manifest.xml /Users/<username>/Library/Containers/com.microsoft.Word/Data/Documents/wef

Po spuštění Wordu (v tomto případě, pro Excel by se jenom v cestě nahradil název za com.microsoft.Excel) pak najdeme add-in v sekci „Developer Add-ins“.

image

Mazání příliš hlubokých adresářů

Tůně diskového prostoru našich počítačů mohou být hluboké a třeba takové Node.js se dokáže svou návazností balíčků zavrtat pořádně hluboko pod hladinu Céčka (nebo Déčka, /home, či jakkoliv jinak pojmenováváte svůj adresářový root).

node-packages

Na Windows to může zajít dokonce tak daleko, že vám systém nedovolí s takto hlubokou strukturou manipulovat, protože „Cesta je příliš dlouhá“.

image

Jak se potom nežádoucí složky zbavit? Způsobů je několik, mně se osvědčil tento:

  1. Otevřít cmd.
  2. Přejít dovnitř této složky, na co nejhlubší úroveň.
  3. Napsat:
    subst j: .

    (včetně tečky na konci).

  4. Otevřít v Průzkumníku jednotku J.
  5. Smazat složku.

Jakmile je hotovo, stačí virtuální jednotku J zase odebrat:

subst j: /d

V podstatě jsme právě vytáhli soubory z hlubin trošku víc na světlo a díky tomu nám systém dovolil je smazat.

Dokumentace k subst.