martedì 14 marzo 2017

Build: I minuti sono tornati

Se avete attivato la nuova Home Page dell'account sul vostro Visual Studio Team Services, avrete sicuramente notato che il riepilogo dei minuti di build gratuiti è sparito. Il problema è che non solo è stato tolto dalla pagina iniziale, ma non era stato inserito in nessun'altra schermata.

Finalmente, però, abbiamo di nuovo la possibilità di visualizzare il contatore. Per farlo, bisogna andare sulle impostazioni dell'account, sotto Build and Release, Resource limits:

 Festeggiamo! I minuti sono tornati :)

martedì 7 marzo 2017

BugGuardian per ASP.NET Core

C'è un nuovo membro nella famiglia BugGuardian.

Un po' di tempo fa ho rilasciato BugGuardian, una libreria che permette di create un work item di tipo Bug o Task sia su Visual Studio Team Services sia su Team Foundation Server, nel caso in cui la nostra applicazione sollevi un'eccezione non gestita. (Maggiori informazioni qui).

Dopo un po', si sono aggiunte altre due librerie: BugGuardian.WebForms e BugGuardian.MVC. Come dice il nome, la prima è pensata per ASP.NET WebForms e l'altra per ASP.NET MVC, e servono per semplificare ulteriormente l'adozione della libreria a chi utilizza quelle piattaforme. Ma hanno un limite: funzionano solamente con ASP.NET tradizionale, su .Net Framework.

Oggi sono felice di annunciare che l'estensione BugGuardian.AspNetCore è finalmente disponibile.

BugGuardian.AspNetCore è stata sviluppata per supportare specificamente le webapp ASP.NET Core. Aggiunge un middleware all'applicazione che permette di intercettare automaticamente tutte le eccezioni non gestite.
E la cosa positiva è che supporta sia i progetti ASP.NET Core che utilizzano il full Framework sia quelli scritti con NetCore.

Potete trovare il codice sorgente (e tutte le informazioni sulla configurazione della libreria) su GitHub: https://github.com/n3wt0n/BugGuardian.AspNetCore

Il pacchetto è anche disponibile su NuGet: https://www.nuget.org/packages/DBTek.BugGuardian.AspNetCore

Happy Coding :)

lunedì 28 novembre 2016

WorkItems History: la mia prima estensione per VSTS e TFS

Sono davvero felice ed orgoglioso di condividere la prima versione della mia primissima Estensione per Visual Studio Team Services e Team Foundation Server: WorkItems History.


Cos'è
WorkItems History è un'estensione che aggiunge un hub "History" alla sezione Work di VSTS/TFS e permette di visualizzare la cronologia dei work item modificati e/o aggiunti al backlog del progetto.

Perchè
Lavorare in team non è sempre una cos semplice, specialmente quando c'è bisogno di tenere tutte le cose "sotto controllo". Con questa estensione, possiamo avere un po' più di controllo almeno su quello che sta accadendo al nostro lavoro.

Altre info
Ho deciso di rilasciare questa estensione come Software Open Source.
Potete dare un'occhiata alla sua pagina di (https://github.com/n3wt0n/WorkItemsHistory) e, se volete, potete contribuire attivamente al progetto. Fate riferimento alle Contribution guidelines ed al Code of Conduct per maggiori dettagli a riguardo.

Utilizzo, supporto e Feedback
Questa estensione è pubblicamente disponibile attraverso il VS Marketplace, a questo link: https://marketplace.visualstudio.com/items?itemName=DB.WorkItemsHistory

Potete trovare  ulteriori informazioni sull'utilizzo e l'installazione di WorkItems History sul repo GitHub.

Nel caso in cui doveste trovare un bug o un comportamento inaspettato dell'estensione, fatemelo sapere attraverso la pagina Issues su GitHub e cercherò di risolverlo prima possibile!

Attendo i vostri feedback :)

giovedì 17 novembre 2016

Dati e Novità da Connect(); 2016

Mercoledì 16 novembre 2016, Microsoft ha dimostrato all'evento Connect(); 2016 la sua vision sul futuro dello sviluppo software con soluzione che sono indirizzate and ogni sviluppatore, ogni tipo di applicazione ed ogni piattaforma.

Gli speaker hanno anche condiviso diversi dati piuttosto interessanti riguardo l'adozione di prodotti e servizi:
  • Più di 20 milioni di installazioni di Visual Studio 2015 (con la Community edition gratuita che rappresenta oltre 14 milioni sul totale)
  • 1 milione di utenti mensili attivi (MAU, monthly active users) su Visual Studio Code.
  • 4.6 milioni di utenti registrati su Visual Studio Team Services
  • Più di 25.000 sviluppatori di 1.700 aziende diverse hanno contribuito al .NET Core e altri repository open source relativi, con quasi il 2/3 dei contributi che sono esterni a Microsoft.
  • 1 milione di membri Visual Studio Dev Essentials
  • Gli utenti Xamarin sono aumentati di circa mezzo milione dall'acquisizione, segnando un incremento del 3x rispetto al tasso di crescita precedente
  • 20.000 registrazioni per la preview privata di SQL Server on Linux, di cui più del 50% sono Fortune 500
  • 1.6 milioni di account Azure SQL Databases con più di 100 miliardi di query al giorno
  • Più di 120.000 nuove sottoscrizioni Azure al mese
  • Approssimativamente 1 VM Azure ogni 3 è Linux
  • L'utilizzo di Microsoft Graph è cresciuto del 35% mese su mese nello scorso anno
  • 47.000 third party applications basate su Microsoft Graph e più di 1 miliardo di transazioni API
  • Più di 400 milioni di dispositivi hanno installato Windows 10
Brian Harry ha scritto un blog post molto interessante (è leggibile qui) con tutti gli annunci relativi alle novità di TFS e VSTS. Dateci un'occhiata!


lunedì 5 settembre 2016

A proposito della Build di Xamarin (di nuovo)

In aprile, in uno dei miei post (leggilo qui) avevo spiegato come non fosse più necessario aggiungere lo step "Xamarin License" per effettuare la build di una soluzione Xamarin con gli Hosted Agents.

A partire da ora, non è più necessario includere quello step su qualsiasi build Xamarin, sia che si tratti di agenti installati on premises sia con gli agenti Hosted.

Infatti, come riportato sulle note di rilascio del nuovo update di Visual Studio Team Service: 

The Xamarin License step is no longer necessary and has been removed from the build templates shipped with VSTS and TFS 15. As part of this effort we will also deprecate the task. All build definitions that use this task should be updated to remove it in order to prevent any disruption when the task is finally removed.

Buone build a tutti ;)

venerdì 29 aprile 2016

A proposito della Build di Xamarin con gli Hosted Agent di VSTS

Venerdì scorso (22/04/2016) durante un'evento organizzato da DotNetToscana ho avuto modo di parlare, tra le altre cose, della build di applicazioni sviluppate con Xamarin utilizzando gli Hosted Agent di Visual Studio Team Services

Per poter far funzionare il tutto, nella build definition ho dovuto inserire due task relativi alla Xamarin License: uno che attivava la licenza ed un altro che, dopo la compilazione, la disattivava. 

E proprio riguardo a questi due task, c'è una piccola grande novità: ora non sono più necessari
Con il deploy che hanno fatto qualche giorno fa, infatti, gli Hosted Build Agent hanno già una loro licenza interna che viene attivata automaticamente nel momento in cui devono compilare i progetti Xamarin. 

Riepilogando, se avete o dovete fare delle build definition per Xamarin (ed usate gli Hosted Agent) ora non dovete più aggiungere i task di attivazione e disattivazione della licenza. 

Buona build a tutti :)


martedì 5 aprile 2016

Disponibili BugGuardian.MVC e BugGuardian.WebForms

Oggi sono veramente felice di poter annunciare il rilascio di 2 moduli addizionali per BugGuardian.

Per chi non lo conoscesse, BugGuardian è una libreria che permette di creare in modo molto semplice dei work item di tipo Bug su un account Visual Studio Team Services o su un Team Foundation Server 2015 on-premises nel caso in cui l'applicazione sollevi un'eccezione non gestita (Unhandled Exception).

Per supportare nel modo migliore l'integrazione di questa libreria con i progetti web, da oggi sono disponibili BugGuardian.MVC and BugGuardian.WebForms.

BugGuardian.MVC (GitHub, NuGet) è un estensione di BugGuardian scritta specificamente per supportare ed integrarsi con le applicazioni Asp.net MVC. 
Aggiunge degli Action Filter alle tue applicazioni in modo da poter intercettare automaticamente tutte le eccezioni non gestite.

BugGuardian.WebForms (GitHub, NuGet), invece, è un modulo aggiuntivo per BugGuardian scritto specificamente per supportare le applicazioni Asp.net WebForms.

Queste due nuove librerie sono entrambe basate sulla nuova versione 1.3.0 di BugGuardian (anch'essa rilasciata da pochissimo) e supportano progetti che utilizzano il .Net Framework v4.0 e superiori.

Com'è per BugGuardian, queste due librerie aggiuntive sono Open Source; guardate pure il codice su GitHub.

Se doveste avere dubbi o problemi durante l'utilizzo di queste nuove librerie, fatemelo sapere attraverso le rispettive  Issues page di GitHub e cerchero di fixare il problema prima possibile!

Di nuovo, Voglio ringraziare il mio amico e "collega" MVP Marco Minerva (@marcominervaGitHub) per il supporto ed i suggerimenti.

giovedì 20 agosto 2015

Benvenuto BugGuardian

Qualcuno avrà probabilmente notato che negli ultimi mesi ho scritto solo qualche post qui sul blog. Questo per due motivi principali

Il primo è che, come alcuni già sanno, qualche mese fa mi sono trasferito in un altro paese, piuttosto lontano, con una cultura ed una lingua piuttosto differenti, dove ho iniziato una nuova avventura. Questo ha inevitabilmente preso molto del mio già risicato tempo libero.

Il secondo motivo per cui non sono stato molto attivo qui, che è anche la ragione di questo post, è che ho lavorato ad un nuovo progetto che ho rilasciato oggi: BugGuardian.

Cos'è BugGuardian
BugGuardian è una libreria Open Source, scritta in C# Shared Project, che permette di creare in modo molto semplice dei work item di tipo Bug su un account Visual Studio Online o su un Team Foundation Server 2015 on-premises nel caso in cui l'applicazione sollevi un'eccezione non gestita (Unhandled Exception).
Può essere ovviamente usata anche con delle invocazioni manuali nei blocchi di try/catch per tenere traccia delle eccezioni gestite.

Questa libreria supporta applicazioni scritte con il .Net Framework v4.0 e superiori e può essere usata in moltissimi tipi di progetto, tra cui:
  • Asp.net
  • Asp.net MVC
  • WPF
  • Windows 8 / 8.1 Apps
  • Windows Phone 8 / 8.1 Apps
  • Universal App
  • Universal Windows Platform Apps (Windows 10)
  • ecc
Come ho detto, si tratta di un OSS quindi potete trovare tutti i sorgenti pubblicati su GitHub.

Per poterla installare ed usare senza necessariamente doverla compilare manualmente, ho pubblicato il pacchetto su NuGet. È sufficiente cercare BugGuardian nella Package Manager GUI o eseguire il seguente comando Package Manager Console:
Install-Package DBTek.BugGuardian

Utilizzo, supporto e Feedback
Per trovare linee guida ed esempi sull'utilizzo della libreria consultate la documentazione del progetto. Inoltre nella cartella TestApps dei sorgenti ci sono alcuni esempi di utilizzo con i tipi di applicazione più comuni.

Ad ogni modo, solo per fare un esempio di quanto sia semplice utilizzarla, questo è il codice di cui avrete bisogno per gestire un'eccezione e creare il relativo Bug su VSO / TFS:

using (var creator = new DBTek.BugGuardian.Creator())
{
    creator.AddBug(myException);
}

Se avete dei dubbi o dei problemi durante l'utilizzo di questa libreria, fatemelo sapere attraverso la  Issues page di GitHub e cerrchero di fixare il problema prima possibile!

Attendo i vostri feedback :)


Voglio ringraziare il mio amico e "collega" Marco Minerva (@marcominerva) per il supporto, la pazienza e la Code Review.

lunedì 27 luglio 2015

Deployare una Web App su Azure con la nuova Build di Visual Studio Online

In questo post vedremo come fare, iniziando da 0, a deployare una nostra soluzione su una Web App di Azure utilizzando la nuova Build di Visual Studio Online.
Per farlo, useremo esclusivamente il portale web di VSO.

Collegare Azure a VSO
Innanzitutto bisogna "far sapere" a Visual Studio Online che abbiamo un account Azure che vogliamo utilizzare come endpoint di deploy per la nostra soluzione.
Per farlo, dobbiamo andare nella parte dei setting del progetto (cliccando sull'apposito bottone  presente in alto a destra, dopo essere entrati nella pagina del progetto), cliccare sulla tab "Services", poi su "Add new Service Connection" ed infine su "Azure".


A questo punto si aprirà un popup dove dovremo inserire l'ID della sottoscrizione Azure che contiene o conterrà la web app da pubblicare, un nome (anche se il campo si chiama "Subscription Name", non è necessario usare il nome della sottoscrizione, si tratta di un campo di testo libero che ci servirà per identificare la sottoscrizione nel caso ne collegassimo più di una a VSO) e le modalità di autenticazione.
È possibile utilizzare sia un certificato (reperibile tramite il portale di Azure) sia direttamente le credenziali.

Fatto questo, la nostra subscription di Azure e il nostro account Visual Studio Online saranno collegati (almeno su questo team project).

Creare la build definition
Ora che abbiamo impostato la connessione tra VSO ed Azure, spostiamoci nella sezione Build del progetto e creiamo una nuova build definition di tipo deployment.


Siccome vogliamo deployare su Azure, nella sezione "Deployment" scegliere "Azure Website" come indicato nell'immagine.

Verrà create una nuova build definition con alcuni step da configurare.

Vediamo passo passo come procedere.


Il primo step rappresenta il vero e proprio processo di Build. È completamente configurabile, ma la cosa più importante è quella di definire il file di soluzione che dovrà essere utilizzato come source della build. Va selezionato nella casella indicata dalla freccia rossa.

Nel secondo step vanno inseriti i criteri di esecuzione post-build degli Unit Test. Se non abbiamo degli unit test (male...) oppure non vogliamo eseguirli (male anche questo :) ) possiamo eliminare questo step cliccando sulla "X" che compare spostanto il mouse su questo step.

Il terzo step è quello che ci interessa di più in quanto è quello che si occupa di fare il deploy del risultato della Build verso la nostra web app su Azure.


Qui troviamo un menu a discesa in cui, se l'associazione della sottoscrizione Azure è andata a buon fine, troviamo le nostre sottoscrizioni collegate a VSO e possiamo scegliere quella che faà da target per il deploy.
Nella casella successiva, denominata "Web App Name" dobbiamo inserire manualmente il nome della Web App di destinazione. Come vedete in realtà si tratta anche in questo caso di una Combo Box, ma al momento attuale le Web App già esistenti non vengono caricate automaticamente (non dimentichiamo che questa nuova build è ancora in preview).

Ecco quindi alcuni consigli e note:
  • Se inseriamo un nome di una web app che non esiste nella nostra sottoscrizione e che non esiste nella region selezioanta, verrà creata su Azure nella region selezionata
  • Se inseriamo un nome di una web app che non esiste nella nostra sottoscrizione ma che esiste già in quella region, verrà restituito un errore in fase di deploy
  • Se inseriamo un nome di una web app che esiste già nella nostra sottoscrizione ma che è in una region diversa, verrà restituito un errore in fase di deploy
  • Se inseriamo un nome di una web app che esiste già nella nostra sottoscrizione e che si trova nella region selezionata, il deploy utilizzerà quella web app e la aggiornerà

Quindi attenzione a quello che scriviamo :)

I due step rimanenti danno la possibilità di indicizzare e pubblicare i simboli della nostra applicazione (consigliato per poter avere informazioni aggiuntive in caso di eccezioni non gestite) e di pubblicare gli artifact risultati dalla build.

Quando abbiamo impostato tutti i parametri, possiamo salvare la nostra build definition assegnandole un nome.


Possiamo anche modificare i vari parametri di default navigando nelle varie tab per personalizzare la build secondo le nostre esigenze.

Deployamo!
Una volta completate le personalizzazioni, è il momento di lanciare la compilazione e di verificare che il processo di deploy vada a buon fine.

Per lanciare la build, utilizziamo il bottone "Queue build" presente nella toolbar della build definition oppure nel menu contestuale della build stessa.


Quando clicchiamo su quel bottone, il sistema accoderà una build su un agente di compilazione presente sui nostri server oppure in un datacente Microsoft (nel caso in cui abbiamo scelgto di utilizzare la build "hosted")
In ogni caso il progesso sarà visibile nella console real time presente sul web.

Prima verranno eseguiti i task di build e di test:


Poi, al successo di entrambi, il deploy verso azure:


Quando tutto sarà finito, avremo la nostra applicazione funzionante e deployata su Azure. Facile!

martedì 16 giugno 2015

Creare un Reader RSS in una Partial View di Umbraco 7

Ci sono molti modi di creare ed includere un reader RSS in una pagina di Umbraco: usare un custom controller, usare delle marco XSL, ecc...

Ma se volessimo usare solamente una Partial View MVC senza sviluppare un controller custom?

Beh, è veramente semplice raggiungere questo obiettivo con solo pochissime righe di C#

@inherits Umbraco.Web.Mvc.UmbracoTemplatePage
@using System.ServiceModel
@using System.ServiceModel.Syndication
@using System.Xml
@{
 string url = "http://your_blog_rss_url";
 XmlReader reader = XmlReader.Create(url);
 SyndicationFeed feed = SyndicationFeed.Load(reader); 
 reader.Close(); 
}

@foreach(var feedItem in feed.Items)
{ 
 <div class="col-md-6">
  <article>
   <div class="date">
    <span class="day">@feedItem.PublishDate.Day</span>
    <span class="month">@GetMonthName(feedItems[i].PublishDate.Month)</span>
   </div>
   <h4 class="heading-primary"><a href="@feedItem.Links[4].Uri">@feedItems[i].Title.Text</a></h4>
   <p>@(feedItem.Summary.Text + "... ") <a href="@feedItem.Links[4].Uri" class="read-more">read more <i class="fa fa-angle-right"></i></a></p>
  </article>
 </div>
}

Come potete vedere, sono bastate alcune righe di codice ed abbiamo il nostro Reader RSS. A questo punto è necessario semplicemente includere questa partial view nella pagina che ci interessa per vedere il nostro feed RSS.
Ovviamente è possibile cambiare il layout, quello nell'emepio è solo quello che ho usato io per il mio progetto.

Solo 2 note:
  1. Io ho usato "feedItem.Links[4].Uri" per recuperare l'url del blog post, questo funziona se si usa blogger come hoster. Se invece utilizzate altre piattaforme di blogging, dovrete scorrervi la collection Links per scoprire dov'è l'url che vi serve.
  2. Il "@GetMonthName" è solamente un Helper che converte il "numero" del mese nel suo nome.