.NET Development

Upgrade di Service Fabric - Storie di vita vissuta

Alberto Dallagiacoma — Tue, 26 Sep 2017 15:24:00 GMT

Vista la disponibilità della versione 6.0 del runtime di Service Fabric ho aggiornato la mia macchina di sviluppo, ma la cosa non è andata propriamente “liscia”, nonostante abbia usato il Web Platform Installer come ho sempre fatto per le versioni precedenti.
La procedura di setup usa uno script PowerShell chiamato CleanFabric.ps1, che si trova in C:\Program Files\Microsoft Service Fabric\bin\Fabric\Fabric.Code. Lo script elimina l’installazione precedente prima di procedere al setup della nuova versione...

...Se ci riesce!

Nel mio caso, l’upgrade si è bloccato con questo errore:

“Unable to delete C:\Program Files\Service Fabric. Delete manually”

Se bastasse questo, sarebbe troppo facile: purtroppo, alcuni file risultavano in uso da qualche processo sconosciuto.
Il motivo è che il setup di Service Fabric installa due driver ad un livello di Sistema Operativo abbastanza "basso":

KtlLogger.sys KtlLogger: KTL Physical Logger Device Driver (c:\program files\microsoft service fabric\bin\fabric\fabric.code\ktllogger.sys)
LeasLayr.sys LeasLayr: Lease Layer Device Driver (c:\program files\microsoft service fabric\bin\fabric\fabric.code\leaslayr.sys)

Questi driver erano ovviamente in uso da Windows al momento del setup, motivo per cui né il setup stesso, né il sottoscritto sono riusciti ad eliminare la cartella.
L’unica soluzione che ho trovato è stato usare il tool "autoruns.exe" di San Mark Russinovich (https://docs.microsoft.com/en-us/sysinternals/downloads/autoruns): tramite il tool ho disabilitato i drivers, in modo che non vengano attivati in automatico da Windows allo startup.
Ho poi riavviato il PC e eliminato manualmente la cartella senza problemi. A questo punto il setup della nuova versione si è concluso correttamente, riconfigurando correttamente i driver.

Lo posto qui, nel caso possa servire ad evitare qualche mal di pancia... ;-)

Technorati Tags: Service Fabric

Visual NUnit

Alberto Dallagiacoma — Fri, 06 Apr 2012 15:30:00 GMT

E’ più che altro una questione di abitudine, ma mi sono sempre trovato così bene con NUnit, che non mi è mai capitato di usare sul serio MSTest.
Una cosa davvero molto bella che ha MSTest è, ovviamente, la totale integrazione con l’IDE di Visual Studio, cosa che NUnit può avere solo con tool di terze parti, spesso a pagamento (ReSharper in primis).

Ho trovato però Visual NUnit 2010, un add-in molto carino per Visual Studio 2010 che aggiunge un test runner per NUnit all’IDE di Visual Studio 2010. Non è completo come quello di ReSharper, ma per gli “NUnit addicted” è decisamente da provare.

AppFabric 1.1 Cumulative Update

Alberto Dallagiacoma — Thu, 05 Apr 2012 23:05:10 GMT

E’ stata rilasciata una Cumulative Update per Windows Server AppFabric 1.1 che risolve alcune “magagne” qua e là.
Come buona abitudine, consiglio sempre di leggere prima le informazioni sull’update, e poi eventualmente procedere al download.

Mi raccomando!

Technorati Tags: AppFabric

NBuilder

Alberto Dallagiacoma — Tue, 02 Nov 2010 12:41:00 GMT

Me lo segno qui, perché l’altro qualche giorno fa ne avevo bisogno, ma non mi ricordavo né il nome, né il sito… (grazie Luca, per il reminder ).

Tutte le volte che creiamo i nostri unit test, abbiamo anche bisogno di creare le istanze delle classi che saranno poi oggetto dei test.
NBuilder è una libreria che facilita la creazione di test objects, evitandoci di scrivere tutto quel noioso codice in fase di SetUp/TestInitialize di ogni test fixture.

Io l’ho trovata davvero utile! Il download, qui.

Technorati Tags: .NET,Testing

Nuova versione di Castle Windsor (e NHibernate?)

Alberto Dallagiacoma — Tue, 24 Aug 2010 15:06:00 GMT

Giusto ieri è stata rilasciata la nuova versione 2.5 di Castle Windsor; tra le tante novità, il supporto a .NET 4.0 e Silverlight.

Bene; supponiamo di voler aggiornare un progetto esistente basato su NHibernate, in modo che usi anche l’ultima versione di Castle Windsor.
Prima della versione 2.1.x di NHibernate, la cosa non era semplicissima, dato che era presente una reference diretta agli assembly Castle.Core e Castle.DynamicProxy, quindi l’unica strada percorribile era::

Scaricare il codice sorgente di NHibernate.
Scaricare la versione di Castle Windsor desiderata.
Copiare gli assembly Castle.Core e Castle.DynamicProxy nelle cartelle di build di NH sostituendo gli assembly esistenti.
Ricompilare NHibernate.

Dalla versione 2.1.x di NHibernate, le cose si sono semplificate, visto che è stata rimossa la dipendenza diretta da Castle. In questo caso quindi, basta ricompilare la ProxyFactory per Castle, in questo modo:

Scaricare il codice sorgente di NHibernate.
Cambiare le references a Castle nel progetto NHibernate.ByteCode.Castle e ricompilarlo.
Fare il deploy di NHibernate.ByteCode.Castle con le references aggiornate.

Visto che NHibernate non ha la reference diretta all’assembly della ProxyFactory, ma viene caricata quella indicata nella proprietà proxyfactory.factory_class, è abbastanza facile gestire la cosa semplicemente copiando nella cartella di output del progetto i files della versione di ProxyFactory desiderata.

Technorati Tags: .NET,NHibernate,Castle

Castle Scheduler

Alberto Dallagiacoma — Mon, 14 Jun 2010 16:25:52 GMT

La suite CastleProject si arricchisce di un nuovo componente: Castle Scheduler.
Si tratta di un Job Scheduler simile al forse più famoso Quartz.NET, porting della omonima libreria Java.
Ovviamente, l’integrazione con Castle Windsor è piuttosto semplice.

Merita un’occhiata.

Technorati Tags: .NET,Castle

Servizi Windows autoinstallanti

Alberto Dallagiacoma — Sun, 09 May 2010 23:25:46 GMT

E’ noto che per installare un Windows Service bisogna ricorrere al tool InstallUtil, che si occupa di eseguire tutte le configurazioni necessarie affinche il nostro eseguibile possa essere gestito come servizio di sistema.

Spesso si trovano eseguibili che possono operare come servizi di sistema semplicemente invocandoli con particolari parametri sulla linea di comando, ad esempio:

MyService.exe –installservice
MyService.exe -uninstallservice

Per aggiungere una funzionalità simile al nostro Windows Service, basta andare a curiosare all’interno di InstallUtil.exe con il fido Reflector, per accorgersi che in realtà il tool non fa altro che passare gli argomenti in ingresso sulla riga di comando alla classe ManagedInstallerClass:

Nulla ci vieta di fare la stessa cosa all’interno del nostro codice, quindi, dopo aver aggiunto la reference all’Assembly System.Configuration.Install, possiamo aggiungere due metodi che si occupano di installare o disinstallare il servizio:

using System.Reflection;
using System.Configuration.Install;

private readonly string _serviceExe = Assembly.GetExecutingAssembly().Location;

private void InstallService()
{
    ManagedInstallerClass.InstallHelper(new string[] { _serviceExe });
}

private void UninstallService()
{
    ManagedInstallerClass.InstallHelper(new string[] { "/u", _serviceExe });
}

Fatto questo, basta controllare quali parametri sono stati specificati sulla linea di comando ed agire di conseguenza:

if (args.Length > 0 && (args[0].StartsWith('-') || args[0].StartsWith('/')))
{
    switch (args[0].Substring(1).ToLower())
    {
        case "installservice":
            InstallService();
            break;
        case "uninstallservice":
            UninstallService();
            break;
    }
}

In questo modo, possiamo fare il deploy del nostro servizio senza essere dipendenti da InstallUtil.

Technorati Tags: .NET,Windows Services

NHibernate in applicazioni desktop

Alberto Dallagiacoma — Thu, 10 Dec 2009 17:50:25 GMT

Ho sempre notato che la maggior parte degli esempi e della documentazione che si trova in rete su NHibernate riguarda applicazioni web, e per me che ho sempre dato precedenza ad applicazioni Smart Client, è stato un problema, almeno all’inizio.

Fortunatamente, il solito Ayende è corso in nostro aiuto: su MSDN magazine è stato pubblicato un suo articolo che tratta l’utilizzo di NHibernate in un’applicazione WPF, spiegando con quali tecniche gestire la concorrenza, il databinding e la Session in un contesto molto diverso da quello web quale è l’applicazione desktop.
Articolo interessante che merita una lettura: lo trovate qui.

Technorati Tags: .NET,NHibernate

Linq2NHibernate, FirstOrDefault e… I Dire Straits

Alberto Dallagiacoma — Wed, 05 Aug 2009 14:50:00 GMT

Tutti conosciamo i Dire Straits, vero? Bene.

La miglior formazione dei Dire Straits, a mio avviso, è stata quella composta da:

Mark Knopfler (voce e chitarra solista)
John Illsley (basso)
Hal Lindes (chitarra ritmica)
Alan Clark (tastiere)
Terry Williams (batteria)

Se provassimo a mappare il tutto in un modello ad oggetti, potremmo scrivere:

public class Band  {         public int BandId { get; set; }         public IList<Player> Members { get; set; }  } public class Player {         public int PlayerId { get; set; }         public string FirstName { get; set; }     public string LastName { get; set; }     public Band Band { get; set; } }

E ora che abbiamo Linq2NHibernate possiamo scrivere una cosa del tipo:

using (ISession session = SessionHelper.OpenSession())  {     Band myBand = session.Linq<Band>().Expand("Members")                     .Where<Band>(bnd => bnd.BandId == 1)                     .FirstOrDefault<Band>();     Console.WriteLine("Nome band: {0}, numero di componenti: {1}",          myBand.Name,          myBand.Members.Count);  }

L'output però non è quello che ci aspettiamo:

Nome band: Dire Straits, numero di componenti: 1

La causa è nel codice SQL generato da Linq2NHibernate, che, da Profiler, risulta essere questo:

exec sp_executesql N'SELECT top 1 this_.BandId as BandId4_1_,  this_.Name as Name4_1_, members2_.BandId as BandId3_,  members2_.PlayerId as PlayerId3_, members2_.PlayerId as PlayerId2_0_,  members2_.FirstName as FirstName2_0_, members2_.LastName as LastName2_0_, members2_.BandId as BandId2_0_  FROM dbo.Band this_      left outer join dbo.Player members2_ on          this_.BandId=members2_.BandId  WHERE this_.BandId = @p0',N'@p0 int',@p0=1

In pratica, la chiamata a FirstOrDefault() aggiunge quel TOP 1 all’SQL generato, che fa sì che venga ritornata solo una riga ritornata dal DB, falsando il conteggio.
I modi per risolvere la questione sono due:

Tornare ad usare la Criteria API :).
Sostituire FirstOrDefault<Band>() con ToList<Band>()[0].

In questo modo, la clausola TOP sparisce e i Dire Straits tornano ad essere cinque:

Nome band: Dire Straits, numero di componenti: 5

Technorati Tags: .NET,NHibernate,Linq

Rilasciato NHibernate 2.1.0

Alberto Dallagiacoma — Mon, 20 Jul 2009 09:49:53 GMT

E’ stata rilasciata la versione 2.1.0 di NHibernate. Qualche novità:

1. Supporto diretto a SQL Server 2008 (MSSql2008Dialect); NHibernate può usare i tipi di dato Date, Time, DateTime2, DateTimeOffset.

2. Nuovi ID Generators.

3. Executable HQL. E’ possibile scrivere una cosa del tipo:

using (ISession session = GetSession())

    using (ITransaction tx = session.BeginTransaction())

        session.CreateQuery("delete from MyEntity").ExecuteUpdate();

        tx.Commit();

4. Rimozione della dipendenza da Castle.DynamicProxy2 (informazioni qui e qui).

In ogni modo, la lettura del file releasenotes.txt è sempre consigliata.