In Sirverlight non esiste nativamente il modo per ottenere le informazioni sull’utente connesso a Windows. Quello che si può fare é utilizzare del codice ASP lato server e poi recuperare le informazioni da Silverlight.

Nel nostro container ASP che host il controllo Silverlight aggiungiamo qualcosa del tipo:

....

    void Page_Load()
    {
      this.UsernameField.Value = User.Identity.Name;
    }

  ...

....

    void Page_Load()
    {
      this.UsernameField.Value = User.Identity.Name;
    }

  ...

Nel body invece mettiamo un controllo nascosto per contenere i nostri dati:

  ...

  ...

  ...

  ...

Lato Silverlight leggiamo, quando ci occorre, il volore del tag input:

public string GetUser()
{
  HtmlDocument doc = HtmlPage.Document;
  if (doc == null)
  {
    return string.Empty;
  }
  HtmlElement elm = doc.GetElementById("UserField");
  if (elm == null)
  {
    return string.Empty;
  }
  return elm.GetAttribute("value");
}

A volte capita di dover accedere con un’applicazione web a servizi hostati in un dominio esterno. Questo si risolve nella maggioranza dei casi impostando in maniera corretta il file [clientaccesspolicy.xml](http://msdn.microsoft.com/en-us/library/cc197955(VS.95).aspx "clientaccesspolicy").

Nel caso in cui però il Web Service in questione non sia hostato da un vero e proprio web server ma da un’applicazione .NET (sia essa console o form) si deve ovviare al problema della Cross Domain Policy in manera più fantasiosa ((poi dicono che gli informatici non hanno fantasia 🙂 )) .

_

_Quello che sto per descrivere é un modo semplice per simulare la presenza del file clientaccesspolicy.xml quando si ha a che fare con un ServiceHost.

Supponendo di avere già il Web Service funzionante (MyService), quello che resta da fare é far implementare ad esso un’interfaccia del tipo:

[ServiceContract]
public interface IPolicyRetriever
{
    [OperationContract]
    [WebGet(UriTemplate = "/clientaccesspolicy.xml")]
    Stream GetSilverlightPolicy();
}

[ServiceContract]
public interface IPolicyRetriever
{
    [OperationContract]
    [WebGet(UriTemplate = "/clientaccesspolicy.xml")]
    Stream GetSilverlightPolicy();
}

Inquesta interfaccia specifichiamo che il servizio deve rispondere quando viene interrogato l’Uri /clientaccesspolicy.xml.

Il gioco è fatto.

Basta ora implementare il service in un modo simile a questo:

public Stream GetSilverlightPolicy()
{
       string result = @

                              ";
      WebOperationContext.Current.OutgoingResponse.ContentType = "application/xml";
      return new MemoryStream(Encoding.UTF8.GetBytes(result));
}

public Stream GetSilverlightPolicy()
{
       string result = @

                              ";
      WebOperationContext.Current.OutgoingResponse.ContentType = "application/xml";
      return new MemoryStream(Encoding.UTF8.GetBytes(result));
}

e creare il ServiceHost dove aggiungere i due endpoint.

class Program
    {
        static void Main(string[] args)
        {
            Uri baseAddress = new Uri("http://localhost:9090");
            // Create the ServiceHost.
            using (ServiceHost host = new ServiceHost(typeof(MyService), baseAddress))
            {
                // Enable metadata publishing.
                ServiceMetadataBehavior smb = new ServiceMetadataBehavior();
                smb.HttpGetEnabled = true;
                smb.MetadataExporter.PolicyVersion = PolicyVersion.Policy15;
                host.Description.Behaviors.Add(smb);
                host.AddServiceEndpoint(typeof(IMyService), new BasicHttpBinding(), new Uri("http://localhost:9090/myservice.svc"));

                host.AddServiceEndpoint(typeof(IPolicyRetriever), new WebHttpBinding(), "").Behaviors.Add(new WebHttpBehavior());

                host.Open();
                Console.ReadLine();
                host.Close();
            }
        }
    }

class Program
    {
        static void Main(string[] args)
        {
            Uri baseAddress = new Uri("http://localhost:9090");
            // Create the ServiceHost.
            using (ServiceHost host = new ServiceHost(typeof(MyService), baseAddress))
            {
                // Enable metadata publishing.
                ServiceMetadataBehavior smb = new ServiceMetadataBehavior();
                smb.HttpGetEnabled = true;
                smb.MetadataExporter.PolicyVersion = PolicyVersion.Policy15;
                host.Description.Behaviors.Add(smb);
                host.AddServiceEndpoint(typeof(IMyService), new BasicHttpBinding(), new Uri("http://localhost:9090/myservice.svc"));

                host.AddServiceEndpoint(typeof(IPolicyRetriever), new WebHttpBinding(), "").Behaviors.Add(new WebHttpBehavior());

                host.Open();
                Console.ReadLine();
                host.Close();
            }
        }
    }

Ecco fatto; il nostro client potrà accedere al WebService senza problemi.

Lo ammetto: non é certo la cosa più complicata del mondo eliminare le righe duplicate in un database; quando serve però non viene mai in mente un modo per farlo. Questo post lo categorizzo quindi come mio promemoria!

Perché (semi-)duplicati? Parto dall’esempio pratico: aggiungere una chiave ad una tabella già piena di dati. Ovviamente, per la legge di Murphy, i valori dei campi che dovrebbero diventare chiave non saranno mai tutti diversi. Voglio quindi eliminare dalla tabella i record con chiavi uguali, preservandone solo una copia per ognuno.

Poniamo che la nostra tabella di chiami table1 con campi field1,field2,field3 (la fantasia nel dare i nomi é il mio forte). Vogliamo far diventare field1 e field2 chiave primaria. Per eliminare i duplicati eseguiamo:

SELECT * FROM db.table1 as t2 WHERE (t2.field1,t2.field2,t2.field3) not in ( SELECT t1.field1,t1.field2, min(t1.field3) FROM db.table1 as t1 group by t1.field1,t1.field2)

Fatto! Come preannunciato niente di emozionante… 😉

Ovviamente la regola min(t1.field3) puo' essere cambiata a piacimento per conservare il record piu' conveniente ai fini dell’applicazione.