La partecipazione dei nostri oggetti ad attività transazionali

Da sempre siamo abituati a utilizzare le transazioni per la memorizzazione delle informazioni su base dati in modo tale da impedire un salvataggio su particolari dipendenze in attività di registrazione complesse, ebbene, talvolta si dimenticano i principi base che devono regolamentare le attività transazionali.

Innanzitutto farei un cappello introduttivo per sottolineare che le operazioni su database sono solo un caso specifico di transazionalità, e, sebbene di laraga diffusione, possiamo definire un’attività transazionale qualsiasi attività che esegue un operazione di persistenza, persistenza che sia secondo il paradigma ACID ovvero:

Atomica

Consistente

Isolata

Durevole

• Atomica significa che tutte le operazioni appartenente al contesto transazionale devono essere considerate come un unica operazione.
• Consistente significa che prima e dopo l’operazione transazionale non siano violate le regole di integrità
• Isolata significa che le attività coninvolte al contestono non abbiano impatti reali fino alla loro conclusione
• Durevole sitgnifica che i dati siano memorizzati in forma durevole (quindi salvati da qualche parte)

L’oggetto che il framework ci fornisce per supportare questo principo è il conosciutissimo TransactionScope che nel caso più semplice è scritto così:

using (TransactionScope ts = new TransactionScope()) {
….
ts.Complete();
}

Inutile dire che la using è una convenzione per la disposizione dell’oggetto TransactionScope al termine della sua reale necessità. Segnalo inoltre che anche se la forma più comune di utilizzo delle TransactionScope sia quella sopra cita è bene tenere a mente che abbiamo a disposizione una gestione più capillare mediante la semplice costruzione dell’oggetto TransactionScope

• TransactionScopeOption.Required (default) – la transazione viene creata solo se occorre
• TransactionScopeOption.RequiredNew – la transazione viene creata comunque
• TransactionScopeOption.Suppress – elimina il blocco corrente al blocco transazionale precedente

I parametri sopra elencati sono necessari qualora abbiamo una complessità tale da dover gestire operazioni transazionali nidificate, e, in tal caso desideriamo gestire il singolo blocco in modo programmatico, ovvero nel caso di RequiredNew obblighiamo l’autonomia del blocco transazionale indipendemente dal precedente e, nel caso di Suppress, obblighiamo che indipendentemente dalla nidificazione il blocco transazionale sia eseguito “al di fuori”.

Preciso che ad oggi qualsiasi attività transazionale viene gestita tramite l’oggetto Distributed Transaction Coordinator introdotto da Windows NT e talvolta in produzione dobbiamo preoccuparci che il serivizio sia correttamente avviato (Da SqlServer 2005 sono state introdotte le lightweight transaction che consentono un considerevole incremento di performance rispetto a MSDTC).

In questo articolo analizziamo comunque tutte le attività transazionali che non hanno necessariamente a che fare con la DbCommand e quindi con ADO.NET ma che abbiano invece una responsabilità differente, ipotizziamo ad esempio il salvataggio su un file che prima scrivere fisicamente il file vogliamo che le informazioni siano in un file tempomporaneo e vogliamo consentire la particpazione del nostro oggetto transazionale a un contesto più ampio, e nel caso specifico faccio riferimento al pattern architetturale Unit Of Work che ci consente di tenere traccia dei cambiamenti fino a un livello da noi definito.

Bene, veniamo alla seconda parte dell’articolo per vedere come far partecipare un nostro oggetto custom al contesto di un TransactionScope. La parte del leone la fa il transaction Manager che internamente è l’oggetto che fisicamente si preoccupa di invocare la Commit (nel caso sia andato tutto bene – metodo Complete, oppure la rollback – disposizione del transaction scope).

Il transaction manager, invoca un oggetto che implementi l’interfaccia IEnlistmentNotification la quale consente di tenere traccia di uno stato ed eseguire la commit solo all’occorrenza, quindi, qualsiasi oggetto che implementa la IEnlistmentNotification è in grado di partecipare ad un particolare contesto transazionale, e, nel caso di Ado.Net Microsoft lo ha implementato al posto nostro, tale funzionalita aimè non è presente nelle operazioni che abbiano però un ambito applicativo differente dai database e quindi per tutte le operazioni che richiedano una gestione particolare.

Ipotizziamo un proxy wcf che vogliamo che effettivamente invochi l’operazione a effettivo termine di tutte le attività dipendenti e che non siano da lui consciute ma dal programma; in questo caso sfrutteremo le partial class per estendere il nostro proxy e implementare dunque la IEnlistmentNotification.

Tutto sommato la realizzazione di un oggetto transazionabile è oltremodo semplce e qui c’è la definizione dei metodi da implementare:

public interface IEnlistmentNotification
{
void Commit( Enlistment enlistment );
void InDoubt( Enlistment enlistment );
void Prepare( PreparingEnlistment preparingEnlistment );
void Rollback( Enlistment enlistment );
}

Il metodo commit e rollback sono i metodi che verranno richiamati al termine dell’operazione per la persistenza o il rollback mentre una nota speciale vanno per i due metodi Prepare e InDubt che sono coinvolti a quel tipo di transazioni che avvengono in due fasi, mentre InDubt viene eseguito quando tutto sembra essere ok ma qualche Prepare della catena di oggetti ha perso la sua consistenza e quindi sarà nostra premura organizzarci di conseguenza.

Bene, è tutto e rimando alla documentazione ufficiale di MSDN o al più all’uso di reflector per gli esempi anche perchè wordpress in cui ospito il blog non è il massimo per eseguire il post di codice, ma mi organizzerò prima o poi.

WCF e IIS, non solo Http

WCF, è un framework molto potente ed è ad oggi lo standard de facto per i servizi di comunicazione in ambiente .NET, dalla versione 3 con Visual Studio 2005 Microsoft ha messo a disposizone la possibilità di far ospitare i nostri servizi un application server di tutto rispetto come IIS, ma come fare per quei servizi non trasportato sotto http?

La risposta si chiama WAS o meglio Windows Actiovation Services, cioè un estensione di IIS non installata di default che consnte il trasporto sotto tutti i protocolli disponibili con wcf e con qualche accorgimento anche ai canali “custom”.

Per chi volesse provare questa feature, consiglio l’installazione di windows 7 per un ambiente di sviluppo oppure windows server 2008 R2 per un ambiente di test e produzione. Diciamo comunque che giocheremo con un paio di comandi  che i nostri colleghi sistemisti conoscono o dovrebbero conoscere bene.

Per prima cosa l’installazione dei servizi WAS avviene tramite il pannello di controllo e l’aggiunta di funzionalità Windows, nella mia versione in inglese si chiama Windows Communication Foundation Non Http Activation, e la loro installazione è banale alla pari di un’installazione di IIS 7.

Ora dobbiamo aprire la command line ( chi non ha disabilitalo la UAC deve avere concedere i privilegi amministrativi, con il comando run as administratori).

A questo punto è possibile assegnare i vari binding utilizzabili da IIS

%windir%\System32\inetsrv\appcmd.exe set site “Default Web Site” — +bindings.[protocol=’net.pipe’, bindinginformation=*’]

ora ogni applicazione di IIS che lo ospitera i nostri servi non http dovrà avere il suo mapping WAS cioè

%windir%\system32\inetsrv\appcmd set app “Default Web Site/MyApplication” /enabledProtocols:http,net.pipe

e con questo abbiamo finito! Naturalmente è possibile eseguire questa procedura con qualsiasi protocollo di WCF.

Windows 7 Ultimate e Windows 7 Ultimate N

La versione di Windows 7 Ultimate è quella più completa, si possono aggiornare le interfacce in 35 lingue (evidentemente anche a Redmond hanno saputo che in Italia abbiamo un sacco di arabi e cinesi) ma attenzione, molto spesso ho visto nei negozi la versione N di Windows 7 Ultimate, e udite utite, ecco la gabola, un utente si aspetta di avere le funzionalità multimediali e tutte le feature strabilianti incluse nella nuova versione dell’ultimo sistema uscito da Microsoft, ebbene nonostante il costo (che non è proprio a buon mercato) la versione N di Windows non possiede le funzionalità multimediali. Ecco dunque le scuse di Microsoft a questo indirizzo tutte le feature mancanti.

Ora mi permetto anche un commento personale, possibile che a nessuno di Microsoft sia venuto in mente che a un cliente che ha appena installato la versione N gli venga un coccolone al termine dell’installazione?

Purtroppo in rete non esistono molte informazioni a riguardo quindi fate bene attenzione se non avete la banda larga (mi immagino il paesino di montagna) e non avete voglia di scaricare 250 mega di features.

Come utilizzare SSL su IIS 7.5

Come tutti sappiamo le connessioni https ovvero con certificati SSL sono sempre lente è quindi opportuno circoscrivere la protezione PGP solo sulle parti realmente sensibili, come l’autenticazione cardspace, l’invio di una password o l’effettiva parte transazionale come l’invio delle informazioni sensibili. A questo proposio ricordo che esiste una normativa ben precisa per la memorizzazione di informazioni sensibili sui propri utenti, e tale normativa, essenzialmente obbliga lo sviluppo di una parte che autorizza espressamente la memorizzazione e l’uso dei dati forniti e l’hash delle password, per quest’ultimo compito asp.net con il proprio provider model fornisce diversi algoritmi di hash che possono essere configurati via web.config.

Torniamo dunque alla spiegazione dell’impostazione SSL su IIS 7. La versione di Windows che uso io è in inglese per tradizione .

1. Creare un nuovo sito 
   
2. Creare un certificato di test oppure importare un certificato regolarmente autorizzato.
   
   Fare doppio click sull’icona di creazione di un nuovo certificato
    
   Premere il link di creazione di un certificato con firma autogenerata
   
   inserire un nome che distingua il nostro certificato e premere ok
   
   Nell’elenco dei certificati compare il nostro nuovo certificato
3. Abilitare il binding Https
   
   
   Selezionare il pulsante Add
   
   Aggiungere dunque il protocollo https e selezionare il certificato che abbiamo creato

Questa è tutta la procedura necessaria per aver avviato ill supporto http al nostro sito, naturalmente in fase di navigazione avendo creato un certificato di test è necessario autorizzare la navigazione con un certificato di fonte anonima.

Et voilà ora è possibile interagire sulla porta 443 in SSL.

naturalmente è possibile anche utilizzare la vecchia utility makecert.exe eseguibuike dal prompt dei comandi di Visual Studio.

Inutile dire che ogni applicazione ASP.NET che si rispetti, sia anche con MVC necessiti del proprio application pool, in modo da non interferire nei processi di altri siti esistenti.

Office 2010

Ho provato stasera la technical preview di Office 2010 e sono devvero stupito per la quantità di cose che in Microsoft hanno aggiunto. Ciò che mi è piaciuto è che ho voluto iniziare l’installazione alla grande facendo un update da Office 2007 e come per magia l’installazione è andata importando tutto quello che già avevo a buon fine ma ho dovuto rimuovere i Pin dalla taskbar di windows 7 in quanto i collegamenti sono cambiati.

Sono stato impressionato da Outlook 2010 che ha un interfaccia devvero divertentente mi propongo dunque di pubblicare un video con una anteprima

Perchè è stato fatto un progetto apposito di unity per silverlight? La risposta è semplicissima non esiste il supporto a System.Configuration quindi voilà il team di P&P ha confezionato una versione di unity in un unico assembly che con un unica referenza possiamo configurare la nostra dependency injection per MVVM.

Il futuro dell’AOP

L’inversion of Control è gettonata da un paio d’anni e si vedono in produzione sistemi che usano estensivamente questo tipo di pattern, analogamente, però l’interception con Unity fa la sua sporca figura perchè è possibile con pochissime linee di codice wrappare completamente il policy application block e definire i CallHandler (ICallHandler) e impostare le posi di interception mediante attributi.

Ormai ci siamo i paradigmi stanno cambiando velocemente e con EL 5 le novità non mancano e probabilmente sarà anche da valutare l’ipotesi di adottare nuovi approcci architetturali il futuro è alle porte e su codeplex già esiste un progetto fantastico il Common Service Locator

http://www.codeplex.com/CommonServiceLocator

Le differenze nel paradigma stanno in questi spezzoni di codice

Oggi:

DatabaseFactory.CreateDatabase(“mia istanza”)

oppure

Container.Resolve<Database>(“mia istanza”)

Il futuro

   1: new TypeRegistration<Database>(

   2:     () => new SqlDatabase(

   3:                 ConnectionString,

   4:                 Container.Resolved<IDataInstrumentationProvider>(Name)))

   5:     {

   6:         Name = Name,

   7:         Lifetime = TypeRegistrationLifetime.Transient

   8:     };

oppure

   1: var configurator = new UnityContainerConfigurator(Container);

   2:

   3: EnterpriseLibraryContainer.ConfigureContainer(

   4:     configurator,

   5:     configurationSource);

Silverlight 3 altre novità (parte 3 di 6)

Una importante novità è nella versione 3 è la possibilità di fare dialogare diverse istanze del plugin con pochissime linee di codice, e a tale proposito di passare tra “sender” e “receiver” un semplice messaggio di testo in modo che vi sia uno scambio di messaggi tra istanze di plugin che risiedono nella stessa macchina, cioò di cui stiamo parlando sono le local connections.

 
 

Ciò che occorre è creare delle istanze di alcuni oggetti e assegnare un nome di tipo stringa alla nostra connessione e utilizzare il namespace System.Windows.Messaging , gli oggetti sono 2

 
 

LocalMessageReceiver per la parte server

LocalMessageSender per la parte client

 
 

Nell’esempio allegato si potrà vedere come ciò che scriviamo in un textbox è perfettamente visibile in un textblock in una istanza completamente diversa del plugin, vale anche nella modalità out of browser

 
 

Le porzioni di codice sono tutte nel costruttore

 
 

Parte clent

private readonly LocalMessageSender _sender;

 
 

public MainPage()

{

InitializeComponent();

_sender = new LocalMessageSender(“myreceiver”);

 
 

myTextBox.KeyUp += ((sender, args) =>

{

_sender.SendAsync(args.Key.ToString());

}

);

 

}

 
 

Parte server

_receiver = new LocalMessageReceiver(“myreceiver”);

_receiver.MessageReceived += ((sender, args) =>

{

myText.Text += args.Message;

}

);

try

{

_receiver.Listen();

}

catch (ListenFailedException exception)

{

MessageBox.Show(string.Format(“Il local connection receiver non può essere instanziato\n{0}”,

exception.Message));

}

 
 

 
 

Gli effetti che si possono effettuare sono notevoli con un codice banale. L’unica menzione è che la spedizione dei messaggi deve essere fatta in modalità asincrona altrimenti impatterebbe sull’istanza del browser.

 
 

 
 

Vediamo ora le novità per i DataBinding

 
 

Per prima cosa finalmente in Microsoft hanno implementato il supporto per il binding su elementi visuali

 
 

{Binding ElementName=mioElemento, Path=MiaProprietà} che già usiamo estensivamente in WPF e a cui siamo abbituati in ambito smart client.

 
 

Anche nel caso di Silverlight 3 è stato implementata la possibilità di collegare le fonti dati al CollectionViewSource che equivale al BindingNavigatore nelle applicazioni SmartClient in Windows Form, sacrificando la possibilità di effetuare il grouping. Anche in questo caso il codice è semplicissimo

 
 

myDataSource.Source = new DataProvider().Employees;

myDataSource.Filter += ((sender, args) =>

{

 
 

}

);

myListBox.ItemsSource = myDataSource.View.SourceCollection;

 
 

Naturalmente il codice del mio UserControl istanzia al suo interno una ClooectionView che effettua il dispatch degli elementi tramite la propria View, per fare questo ho ipotizzato anche un filtro che nel nostro esempio è vuoto in quanto suggerisco i video di Beth Massi su WindowsClient per approfondimenti sullaCollectionView e il databinding (consideriamo che il grouping non è supportato su Silverlight!)

 
 

Questo è il link del codice nell’esempio dove troviamo sia il binding che le local connections http://www.4shared.com/file/145868837/8115df4/SiverlightLocalConnections.html

 
 

Ricordo anche che per le cose rapidissime nel Silverlight toolkit è presente anche il mitico DataGrid, che personalmente non amo molto ma consente di sviluppare le cose con una rapidità impressionante.

 
 

In linea di massima mi chiedo, che senso ha sviluppare ancora applicazioni Windows Form? Secondo me per quando riguarda il codice nuovo, quindi quello prodotto da zero, la risposta è non ha alcun senso.

 
 

Ho fatto come Marzullo mi sono fatto una domanda e mi sono dato una risposta, va bè!

Aspect Oriented Programming AOP con c# ed Enterprise Library

L’AOP ha decisamente preso piede in tutti i contesti in cui sia necessario effettuare attività di sviluppo di livello enterprise , vuoi per la manutenibilità del codice prodotto, vuoi per la semplificazione delle operazioni di test e per la necessità di adottare soluzioni architetturali di una certa robustezza. Enterprise Library ci viene in aiuto fornendo 2 Application Block per queste esigenze: Policy Application Block e Unity AB. I layer architetturali forniscono sempre una grande scalabilità nelle struttura applicativa del codice con lo sforzo iniziale di stratificare correttamente le logiche e l’IO.

 
 

Per capire meglio di cosa stiamo parlando è opportuno fare un piccolo esempio introducendo appunto policy applcation block che ha anche un’età superiore di Unity, tale breve esempio anche se non fa parte delle più recenti tecnologie sarà moloto utile a scopo didattico.

 
 

Giusto per capire introdurre meglio l’ambito di discussione stiamo introducendo ciò che in gergo architetturale viene chiamato Separation of Concerns. Supponiamo dunque di avere un livello di business che deve semplicemente eseguire operazioni aritmetiche con due numeri.

 
 

public class MyAspectClass

{

public int Multiply(int a, int b)

{

try

{

return a + b;

}

catch (Exception e)

{

if (ExceptionPolicy.HandleException(“MyExceptionPolicy”, ex))

{

throw;

}

}

}

 
 

public int Subtract(int a, int b)

{

try

{

return a – b;

}

catch (Exception ex)

{

if (ExceptionPolicy.HandleException(“MyExceptionPolicy”, ex))

{

throw;

}

}

}

}

 
 

Come si può facilmente vedere è necessario ripetere la stessa gestione delle eccezioni in entrambi i metodi di moltiplicazione e sottrazione cioè è questo tipo di concern è chiamato comunemente aspect o cross-cutting concern.

 
 

Implementiamo dunque il Weaving cioè l’iniezione di codice nella nostra classe, che si può ottenere che differenti modalità cioè a compile time o a runtime. Questo tipo di comportamento con il più recente application block Unity viene chiamato Interception e probabilmente dedicherò un post apposito a unity per parlare dell’interception e come può essere utilizzato con davvero poche linee di codice.

Per prima cosa definimo il comportamento cioè quello che in gergo viene chiamato advice cioè
un intercettore che che sarà posto metà tra il chiamante e il chiamato e che effetturà delle azioniall’ingresso e all’uscita di quando un pezzo di codice viene processato.Modificheremo allora le policy sui due metodi che abbiamo scritto in prcedenza in modo tale da omettere la gestione delle eccezioni( naturalmente questo è solo un esempio di come tutti gli aspetti ripetitivi possano essere iniettati a livello applicativo). Andremo dunque a effettuare un Marshalling sulla nostra semplice classe e a decorare i metodi con alcune policy, la nostra classettina diventerà dunque:

 
 

public class MyAspectClass: MarshalByRefObject

{

[ExceptionCallHandler("MyExceptionPolicy")]

public int Multiply(int a, int b)

{

return a + b;

}

[ExceptionCallHandler("MyExceptionPolicy")]

public int Subtract(int a, int b)

{

return a – b;

}

}

 
 

 
 

La decorazione dei metodi sarà configurata con una policy che si chiamaMyExceptionPolicy definita altrove e nella fattispecie configurata tramite file .config.

Ovviamente il codice risulta molto più sentetico e leggibile, ma scriveremo la regola di gestione delle eccezioni solo una volta con una netta facilità di manutenzione. Possiamo a questo punto individuare un problema, cioè che se per caso avremmo necessità di cambiare il nome della nostra policy di gestione dell’eccezione dovremmo andare a mano a modificare i punti in cui questa eccezione è richiamata con un notevole dispendio di tempo e la possibilità di perderci qualcosa per strada che non è detto che emerga nei test unitari.

Un’altro metodo decisamente più efficace è quello di intercettare gli handler su una classe in modo da non dover passare tramite l’uso di attributi questo metodo è chiamato interception e fa la parte del leone nel più recente application block che è Unity.

Per fare queste cose definendo dele policy che accppiano regole e handler, in modo che se una avviene una determinata regola viene scatenato l’handler relativo.

 
 

A questo punto per definire meglio le regole di applicazione delle policy come nella tabella che segue:

 
 

Regola	Descrizione
Assembly	consente di definire il target di una classe sulla base del nome dell’assembly
Custom Attribute	consente di definire il target di una classe sulla base del di un particolare tipo di attributo
Member name	consente il target di un particolare membro di classe
Method signature	target su un particolare metodo
Namespace	target di un namespace
Parameter Type	target su un singolo tipo di parametro
Property	target su una proprietà
Return Type	target sul valore di ritorno di un metodo
Tag attribute	Target sul nome di un attributo
Type	target su un tipo

 
 

 
 

Supponiamo di voler creare una regola che controlii l’espirazione di un oggetto, faremo così:

 
 

[ConfigurationElementType(typeof(CustomMatchingRuleData))]

public class MyTimeOfDayRule : IMatchingRule

{

private readonly DateTime _beginTimeSpan;

private readonly DateTime _endTimeSpan;

 
 

public MyTimeOfDayRule(NameValueCollection configValues)

{

_beginTimeSpan = DateTime.Parse(configValues["BeginTimeSpan"]);

_endTimeSpan = DateTime.Parse(configValues["EndTimeSpan"]);

}

 

#region IMatchingRule Members

 
 

bool IMatchingRule.Matches(MethodBase member)

{

DateTime currentTime = DateTime.Today;

return (currentTime >= _beginTimeSpan && currentTime <= _endTimeSpan);

}

 
 

#endregion

}

 
 

 
 

Naturalmente in casi reali spesso vengono definite molte regole che saranno testate a runtime mediante la seguente catena logica

 
 

 
 

 
 

Ora per utilizzare la nostra regola IMatchingRule dobbiamo configurare anche un handler che esegua delle operazione a fronte del match, EL fornisce anche una serie di handler predifiniti che sono in grado di comunicare con gli altri application block, essi sono:

 
 

Nome classe	Descrizione
AuthorizationCallHandler	Utilizza Security application Block come handler
CachingCallHandler	Utilizza Caching Application Block come handler
ExceptionCallHandler	Utilizza Exception Handling Application Block come handler
LogCallHandler	Utilizza Logging Application block
PerformanceCounterCallHandler	Consente la registrazione di dati di performance
ValidationCallHandler	Utilizza Validation Application Block come handler

 
 

Naturalmente è possibile definire il nostro handler e pertanto avremo dovremo implementare l’interfaccia ICallHandler per crere una classe che si comporti da da Handler, vediamone un esempio:

 
 

public class CreateFileHandler: ICallHandler

{

private readonly string _fileName;

 
 

#region ICallHandler Members

 
 

public CreateFileHandler(NameValueCollection configValues)

{

_fileName = configValues["FileName"];

}

 
 

public IMethodReturn Invoke(IMethodInvocation input, GetNextHandlerDelegate getNext)

{

FileStream stream = File.Create(_fileName);

input.InvocationContext["CreatedFileStream"] = stream;

IMethodReturn msg = getNext()(input, getNext);

FileStream returnStream = msg.InvocationContext["CreatedFileStream"] as FileStream;

if (returnStream != null)

try

{ returnStream.Close();}

catch {}

if (stream != null)

try { stream.Close(); }

catch { }

return msg;

}

 
 

public int Order { get; set; }

 
 

#endregion

}

 
 

E’ abbastanza intuibile come venga collocato mediante l’interfaccia ICallHandler nella catena delle chiamate illustrata prima

 
 

Non ci resta che assemblare il tutto medinte il PolicyInjector

 
 

public class MyAspectClass : MarshalByRefObject

{

[ExceptionCallHandler("MyExceptionPolicy")]

[ValidationCallHandler]

[RangeValidator(typeof(Int32), "0",

RangeBoundaryType.Inclusive, "0", RangeBoundaryType.Ignore,

MessageTemplate = "Value must be greater than zero.") ]

public int Multiply(

[RangeValidator(typeof(Int32), "0",

RangeBoundaryType.Inclusive, "0", RangeBoundaryType.Ignore,

MessageTemplate = "Value must be greater than zero.")]

int a,

[RangeValidator(typeof(Int32), "0",

RangeBoundaryType.Inclusive, "0", RangeBoundaryType.Ignore,

MessageTemplate = "Value must be greater than zero.")]

int b

)

{

return a + b;

}

 
 

[ExceptionCallHandler("MyExceptionPolicy")]

public int Subtract(int a, int b)

{

return a – b;

}

}

 
 

Ora configuriamo il tutto tramite l’utility di configurazione e provvediamo alla costruzione della nostra classe in questo modo

static void Main(string[] args)

{

MyAspectClass c = PolicyInjection.Create<MyAspectClass>();

c.Multiply(0, 5);

 
 

Console.ReadLine();

}

 
 

Il codice dell’esempio è scaricabile da qui: http://www.4shared.com/file/145800910/ef751dad/Policy_application_block.html

Abilitazione porta su servizi wcf in produzione

Abilitare l’ACL sulla porta tramite il comand

Netsh http add urlacl url=:8001/MioServizio">http://<mioserver>:8001/MioServizio

oppure

netsh urlacl url=http://+:8001/MiServizio user=domain\user

Analogamente è possibile seguire il comando remove per rimuovere dall’acl

In questo modo si possono mantenere le policy per consentire l’accesso in produzione al nostro servizio ospitato su IIS 7 o 7