Sincronizzazione

Sull'argomento ci sono svariati modelli di implementazione e di contro anche svariati algoritmi più o meno complessi in base anche al tipo di sincronizzazione che vogliamo
effettuare. In molti casi questo tipo di pratica può essere banalmente svolta tramite uno script dos schedulato, tuttavia non si ha il pieno controllo della struttura.

Quello che mi serve e quello che rappresenterò non è altro che un sottoinsieme della mia reale necessità, e più schematicamente è rappresentabile secondo quanto segue:
a) Monitoraggio continuo,
b) Copia specifica di cartelle / file
c) Esecuzione di attività server side propedeutiche alla sincronizzazione.
d) Log delle attività
e) bassa o assente iterazione utente

A fronte di questi brevi requisiti, non è difficile intuire che il tutto sarà reso tramite un servizio, depositato sulla macchina che chiameremo host B. La macchina host A
potrebbe essere interpretata come il pc o device con i sorgenti.




A fronte di questi brevi requisiti, non è difficile intuire che il tutto sarà reso tramite un servizio, depositato sulla macchina che chiameremo host B. La macchina host A
potrebbe essere interpretata come il pc o device con i sorgenti.


Ciò detto l'atto in se della sincronizzazione è rappresentato con un banale File.Copy, il più e comprendere come e cosa copiare.

public partial class beeSyncro : ServiceBase
{
    FileSystemWatcher fsw;

    string deployM = @"C:\Users\f.arosio\Deploy_Master";
    string deployS = @"C:\Users\f.arosio\Deploy_Slave";

    string dLog = @"C:\Users\f.arosio\LogFile";

    public beeSyncro()
    {
        InitializeComponent();
        
    }

    protected override void OnStart(string[] args)
    {
        fsw = new FileSystemWatcher();

        fsw.Path = deployM;
        fsw.Filter = "*.dll";
        fsw.IncludeSubdirectories = true;
        fsw.NotifyFilter = NotifyFilters.FileName |
                NotifyFilters.LastWrite | 
                NotifyFilters.CreationTime | 
                NotifyFilters.Size;

        fsw.Created += new FileSystemEventHandler(
                fsw_Created
                );
                        
        fsw.EnableRaisingEvents = true;
        DoWirteLog("Start");
    }

    void fsw_Created(object sender, FileSystemEventArgs e)
    {
        DoWirteLog("Now Copy :" +e.FullPath);
        try
        {
            File.Copy(deployM + @"\" + e.Name, 
            deployS + @"\" + e.Name,true);
        }
        catch (Exception ex)
        {
            DoWirteLog("Copy Failed:" 
            + e.FullPath +" " + 
            ex.Message.ToString().Replace("\r\n",""));
        }
    }

    protected override void OnStop()
    {
        fsw = null;
        DoWirteLog("Stop");
    }

    protected void DoWirteLog(string message)
    {
        TextWriter tw = new StreamWriter(dLog
            +@"\log.log",true);

        tw.WriteLine(DateTime.Now.ToShortDateString() 
            +"|" +DateTime.Now.ToLongTimeString() 
            +"|"+ message);
        tw.Close();
        tw = null;        
    }               
} 

In breve questo è il sorgente che rappresenta il nostro "caso".  Il punto di interesse è dato proprio del FileSystemWatcher, che di suo riesce notificare l'avvenuto cambiamento di una risorsa senza consumeare eccessive risorse di sistema Naturalmente non si sta faecendo ragionamento alcuno su quali file è necessario&nbsp

void fsw_Created(object sender, FileSystemEventArgs e)
{
    DoWirteLog("Now Copy :" +e.FullPath);
    try
    {
        File.Copy(deployM + @"\" + e.Name, 
        deployS + @"\" + e.Name,true);
    }
    catch (Exception ex)
    {
        DoWirteLog("Copy Failed:" 
        + e.FullPath +" " + 
        ex.Message.ToString().Replace("\r\n",""));
    }
}

Questo è il punto , dove possiamo inserire la nostra logica nel caso "si avesse" la necessità di aggiungere granularità al nostro "ben misero Algoritmo".