How to force browser to updated the Silverlight package from client?

Where developing an application in Silverlight you will need to create more than one version of the application. Each new version of the application will require each client to clear the cache (CTRL+F5). Normally, you don’t want the application to be downloaded each time.  Because of this, you will not configure the package to expire after a specific period of time.
But what happens when you have a new version of the application? You cannot tell to the clients to clear the cache.
A simple solution for this problem is to version your assemblies. When you deploy on IIS server a new version of the application with the assembly version updated, the new version of your application will be automatically download from the server.
If you don’t know how to version your assemblies you can visit the following link: http://vunvulearadu.blogspot.ro/2012/05/how-to-change-version-of-our-solution.html
Don’t forget to update the assembly version each time when you make a deploy.

Read More

The provided URI scheme 'file' is invalid; expected 'http'

Zilele acestea lucram pe un proiect Silverlight si m-am trezit intr-un anumit moment ne-am trezit cu urmatoarea eroare:

The provided URI scheme 'file' is invalid; expected 'http'

in momentul in care se genera URL serviciului consumat de catre aplicatie Silverlight. ChannelFactory nu stia ce sa faca cu un path non HTTP care nu era de forma HTTP, in conditiile in care acesta era configurat sa lucreze pe HTTP.
Dupa ce am sapat putin, am observat ca adresa care se adresa care se genera avea urmatoarea forma "/MyService/service1.svc", iar in momentul cand se incerca generarea unui endpoint se obtinea o adresa de forma "file://C:[somePath]/MyService/service1.svc".

var endpointAddress = new EndpointAddress("/MyService/service1.svc");

Problema aparea de la modul in care era rulata solutie. In loc sa se ruleze proiectul web, care continea solutie Silverlight, se rula de fapt proiect Silverlight, acesta ruland din locatia file://....
Odata schimbat proiectul care se rula din cel de SL in cel web problema s-a rezolvat.

Read More

One way to persist objects in isolated storage

In unele cazuri avem nevoie sa stocam date in isolated storage. In cazul in care numarul de date pe vrem sa le stocam nu este foarte mare, putem sa le serializam direct si sa le salvam sub forma unui fisier in isolated storage.
In exemplul de mai jos, datele le-am serializat folosind DataContractSerializer. Din aceasta cauta, clasele pe care vrem sa le salvam trebuie sa fie decorate cu atributul DataContract, iar fiecare proprietate pe care dorim sa o salvam trebuie decorata cu atributul DataMember.

[DataContract]
class Foo
{
   [DataMember]
   public string Name { get; set; }
   public int Age {get; set; }
}

In exemplul dat mai sus o sa salvam doar proprietatea Name.
Mai jos puteti sa gasiti o clasa generica care salveaza un obiect dat. In metodele Save si Load as fi putut sa trimit ca si parametru numele la fisier, dar am ales ca numele de fisier sa se genereze pe baza tipului. Se poate si in alte moduri.

public class IsolatedStorageRepository<TItem>
   {
       public void Save(TItem item)
       {
           using (IsolatedStorageFileStream fileStream = IsolatedStorageFile.GetUserStoreForApplication()
                                                           .OpenFile(GetFileName(), FileMode.Create))
           {
               new DataContractSerializer(typeof(TItem))
                       .WriteObject(fileStream, item);
           }
       }
       public TItem Load()
       {
           IsolatedStorageFile storageFile = IsolatedStorageFile.GetUserStoreForApplication();
           if (!storageFile.FileExists(filename))
           {
               return default(TItem);
           }

           using (IsolatedStorageFileStream fileStream = storageFile.OpenFile(GetFileName, FileMode.Open))
           {
               return (TItem)new DataContractSerializer(typeof(TItem)).ReadObject(fileStream);              
           }
       }

       private string GetFileName()
       {
           string typeName = typeof (TItem).ToGenericFullName();
           typeName = typeName.Replace('<', '_');
           typeName = typeName.Replace('>', '_');

           return typeName;
       }
   }

Metoda ToGenericFullName imi returneaza numele unui obiect. Pentru a vedea implementarea acestei clase puteti sa intrati pe link-ul urmator: http://vunvulearadu.blogspot.com/2012/03/how-to-get-friendly-format-for.html

List<Foo> fooList = new List<Foo>();
// populate list
IsolatedStorageRepository repository = new IsolatedStorageRepository<List<Foo>>();
// Save list
repository.Save(fooList);
// Load list
repository.Load();

Solutia se poate implementa in diferite moduri. Aceasta este doar o varianta.
Enjoy!.

Read More

One way to use Dispatcher in a Silverlight application

Daca suntem intr-o aplicatie MVVM folosind Siverlight, in unele situatii o sa avem nevoie Dispatcher pentru a executa cod pe UI thread.
O varianta este de a trasmite o instanta la Dispatcher prin constructor sau cand se face apelul la o metoda data.

public class Context()
{
   ...
   Context(Dispatcher dispatcher)
{
   _dispatcher = dispatcher;
}
..
{
   _dispatcher.BeginInvoke( () => { ... } );
}
}

O alta varianta destul de des intalnita este sa se obtina o referinta la Distapcher direct prin apelul:

Deployment.Current.Dispatcher

Ambele variante functioneaza fara nici o problema. Problema este ca clasele care folosesc acest Dispatcher o sa fie coupled. Aceasta problema se poate observa cel mai usor in momentul in care se scriu teste. Daca testele o sa reluze din brower de exemplu, pana la sfarsitul testelor, threadul de UI o sa fie blocat de rularea acestora, din aceasta cauza nu o sa se ajunga ca codul apelat prin Dispatcher sa fie executat. Pe langa acest lucru in teste dorim sa putem controla cand se ruleaza acest cod.
O varianta este sa ne definim o interfata pentru dispatcher-ul de UI, prin intermediul careia sa se poata rula cod pe UI thread. In acest mod, nu o sa mai fie coupled dispatcher-ul de restul aplicatiei. Iar in cazul in care dorim ca codul sa fie executat pe un alt thread sau in alt mod o sa fie nevoie sa ne implementam diferit acesta clasa( de exemplu pentru teste).

public interface IUiDispatcher
{
   void Invoke(Action action);
}
public class UiDispatcher : IUiDispatcher
   {
       private readonly Dispatcher _dispatcher;

       public UiDispatcher(Dispatcher dispatcher)
       {
           _dispatcher = dispatcher;
       }

       public void InvokeOnUiThread(Action action)
       {
       // Verificam daca suntem pe UI thread.
       if( _dispatcher.CheckAccess())
       {
           action.Invoke();
       }
       else
       {
           _dispatcher.BeginInvoke(action);
       }
   }
}

Enjoy!

Read More

WCF and Silverlight - How to add custom information to a message header

In acest post am discutat despre cum se pot pune informatii in header-ul unui mesaj care este trimis prin WCF. In cazul in care incercati sa folositi aceasta solutie pentru un client pe Silverlight, o sa observati ca desi serverul adauga proprietatiile in header-ul mesajului acestea nu ajung la client, chiar daca pe sarma sunt adaugate.
Din Silverlight nu avem acces la toate proprietatiile care sunt trimise in header. Avem acces doar la cateva proprietati. De exemplu una din propietati este StatusCode. Acesta are valoarea 200 daca apelul s-a terminat cu success.
Datele care le punem in header pentru un client Siverlight, trebuie sa fie puse ca un nou Header. Mai jos gasiti cum puteti adauga un nou header de pe server, iar clientul cum il poate accesa. Al doilea parametru pe care l-am setat cu empty string reprezinta namespace URI pentru header-ul nostru.

public class ServerTokenInspector : IDispatchMessageInspector
   {
       public void BeforeSendReply(ref Message reply, object correlationState)
       {
           reply.Headers.Add(MessageHeader.CreateHeader("ServerToken", string.Empty, Guid.NewGuid()));
       }

       public object AfterReceiveRequest(ref Message request, IClientChannel channel, InstanceContext instanceContext)
       {
           return null;
       }
   }

   public class ServerTokenClientInspector : IClientMessageInspector
   {
       public void AfterReceiveReply(ref Message reply, object correlationState)
       {
           if (reply.Headers.FindHeader("ServerToken", string.Empty) >= 0)
           {
               Guid token = reply.Headers.GetHeader<Guid>("ServerToken", string.Empty);
           }
       }

       public object BeforeSendRequest(ref Message request, IClientChannel channel)
       {
           return null;
       }
   }

Enjoy!

Read More

WCF - How to add custom information to a message header

De obicei intr-o aplicatie client-server folosim WCF pentru a putea comunica intre client si server. WCF este un framework destul de complex si desi este usor de integrat intr-o aplicatie, cand dorim sa facem ceva mai complex putem sa ne trezim pierduti intre tot felul de documentatii si carti despre WCF.
In acest post o sa prezint cum putem adauga in header-ul mesajului care se trimite la client un continut custom( date suplimentare).
O sa pornim de la urmatarea cerinta: fiecare mesaj care vine de la server trebuie sa vina insotit de un token unic a serverului.
O solutie la aceasta problema ar putea fi ca fiecare mesaj( contract) pe care il primim de la server sa fie incapsulat intr-o clasa de tip Response care contina tokenul nostru. Aceasta solutie este destul de buna, dar ce ne facem daca avem nevoie sa adaugam alte date pe langa token? O sa fie nevoie sa facem update imediat la clienti, servicile pe care le expunem prin WCF trebuie versionate si alte probleme de acest gen. Plus ca raspunsul pe care il primim de la server ar trebui sa contina doar datele pentru operatiea( actiunea) care vrem sa se execute. Altfel o sa fim nevoiti de fiecare data sa verificam daca raspunsul contine token-ul sau sa facem un wrapper peste apel. Toate aceste lucruri duc la o crestere a complexitati plus apare si un smel.
Toate aceste date, care contin statusul la server, tokenul de identificare si orice alte date pot sa fie adaugate in headerul mesajului. Trebuie avut doar grija ce fel de date punem. Informatile care se adauga in header trebuie sa fie informatii comune tuturor mesajelor si nu specifice unei singure operatii.
Acest comportament se obtine destul de simplu daca implementam interfata IDispatchMessageInspector. Prin intermediul acestei interfete putem sa modificam continutul unui mesaj inainte sa fie trimis la client. Avem doua metode pe care trebuie sa le implementam:

• AfterReceiveRequest - metoda care este apelata automat dupa ce o cerere a ajuns pe client, dar inante ca ea sa fie executata
• BeforeSendReply - metoda care este apelata chiar inainte ca raspunsul sa fie trimis la client

In cazul in care pe una din actiuni nu vrem sa facem nimic, putem returna null, sau lasam metoda goala. Primul parametru este de tip Message si ne permite sa accesam si/sau modificam mesajul primit sau trimis de la client in orice fel. Prin intermediul la Message avem access atat la header cat si la proprietatea message.Properties. Aceasta colectie de propietati de format (cheie,valoare) ajunge in header-ul mesajului. Valorea poate sa fie orice obiect serializabil, iar cheia este de tip string. Clientul ca sa poata accesa aceste propietati trebuie explicit sa acceseze aceasta colectie( este nevoie ca si clientul sa implementeze un comportament asemanator). Comunicarea intre cei doi o sa functioneze chiar daca clientul nu stie( verifica) aceste propietati. Doar ca nu le v-a putea accesa.

internal class TokenDispatchMessageInspector : IDispatchMessageInspector
    {
        public object AfterReceiveRequest(ref Message request, IClientChannel channel, InstanceContext instanceContext)
        {
            request.Properties["ServerToken"] = "SomeValue";

            return null;
        }

        public void BeforeSendReply(ref Message reply, object correlationState)
        {
           
        }
    }

Odata ce am facut acest lucru este nevoie sa ne definim un OperationBehavior sub forma unui atribut, pe care o sa il putem folosi la contractele sau operatiile pentru care avem nevoie de acest comportament. Prin intermediul interfetei IOperationBehavior, putem sa facem si alte actiuni precum validarea unei operatii. Noi avem nevoie doar sa ne inregistram inspectorul de mesaje definit mai sus( de fapt sa il adaugam in lista de message inspectors).

    public class TokenHeadersOperationBehaviorAttribute : Attribute, IOperationBehavior
    {
        public void AddBindingParameters(OperationDescription operationDescription, BindingParameterCollection bindingParameters)
        {
        }

        public void ApplyClientBehavior(OperationDescription operationDescription, ClientOperation clientOperation)
        {
        }

        public void ApplyDispatchBehavior(OperationDescription operationDescription, DispatchOperation dispatchOperation)
        {
            TokenDispatchMessageInspector inspector = new TokenDispatchMessageInspector();
            dispatchOperation.Parent.MessageInspectors.Add(inspector);
        }

        public void Validate(OperationDescription operationDescription)
        {
        }
    }

Pentru operatiile la care avem nevoie de acest comportament, ajunge sa le decoram cu atributul nostru.

    "[ServiceContract]"
    internal class MyService:IMyService
    {
     "[OperationContract]"
        [TokenHeadersOperationBehaviorAttribute]
        public Response OperationOne()
        {
            ...
        }
    }

Urmatorul pas este sa ne declaram behaviorul nostru. Acest lucru se face din fisierul de configurare( dar se poate face si din cod):

<system.ServiceModel>
<extensions>
      <behaviorExtensions>
        <add
          name="endpointTokenMessageInspector"
          type="Example.TokenDispatchMessageInspector, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null"
        />
      </behaviorExtensions>
    </extensions>
...
    <behaviors>
  <endpointBehaviors>
        <behavior name="tokenBehaviorMessageInspector">
          <endpointMessageInspector />
        </behavior>
      </endpointBehaviors>
    </behaviors>
...
<service name="Test" ...>
     <endpoint
          address="/Test"
          binding="wsHttpBinding"
          behaviorConfiguration="tokenBehaviorMessageInspector"
          contract="Test.IMyService"
        />
</service>
</system.ServiceModel>

In acest moment avem configurat serverul. In cazul in care dupa ce faceti configurarile in fisierul de configurare, vedeti ca servicul nu pornteste, va recomand sa adaugati pe rand fiecare linie de configurare. In cazul in care configurarea la serviciu o faceti din cod, va puteti definii propiul endpointBehavior implementand interfata IEndpointBehavior.
Am terminat cu serverul, aproape acelasi lucru trebuie sa il facem pe server, tot ce difera este ca in loc sa implementam interfata IDispatchMessageInspector o sa fie nevoie sa ne folosim de interfata IClientMessageInspector. Aceasta contine doua metode asemanatoare:

• BeforeSendReply - metoda apelata inainte ca un mesaj sa fie trimis la server
• AfterReceiveReply - metoda apelata dupa ce se primeste un raspuns de la server

Pe client avantajul folosirii acestei interfete este ca o putem folosii si intr-o aplicatie Silverlight. Pe client, in assembly-urile care formeaza core-ul de la Silverlight oricat am cauta nu o gasim niciodata IDispatchMessageInspector.

    internal class TokenDispatchMessageInspector : IClientMessageInspector
    {
        public object BeforeSendRequest(ref Message request, IClientChannel channel)
        {
            return null;
        }

        public void AfterReceiveReply(ref Message reply, object correlationState)
        {
            string serverToken = reply.Properties["ServerToken"] as string;
        }
    }

Pentru inregistrarea acestui comportament pe client trebuie sa face aceiasi pasi ca si pe server( definirea unui endpoint custom in care sa specificam behaviorul nostru).
Enjoy!

Read More

Debug Silverlight application - breakpoint not hit

In cazul in care lucrati cu o aplicatie Silverlight si vreti sa faceti debug s-ar putea sa va treziti nici un brake point nu este atins. Cele mai comune cauze la aceasta probleme sunt:

• proiectul web care contine XAP nu este setat sa permita debug si la Silverlight. Acest lucru se poate activa in felul urmator: click dreapta pe proiectul web care contine xap-ul. Sub tabul Web in zona de Debuggers, verificati sa fie selectat si Silverlight
• puteti incerca tot din Properties de pe proiectul web din tab-ul Silverlight Applications sa stergeti link-ul spre proiectul Silverlight si sa il adaugati din nou( in cazul in care nu aveti proiectul adaugat ca si link, checkboxul de la punctul precedent nu o sa fie vizibil
• verificati ca in browser rulati un url care contine http// si nu file//. Debugul spre linkuri spre local file system este dezactivat
• nu sunteti atasati la procesul care trebuie( aceasta este o problema a Visual Studio care nu se ataseaza la procesul care trebuie). Pentru a va atasa la proces, cand sunteti in debug este nevoie sa selectati Debug->Attach to Process. Acolo trebuie sa selectati procesul care ruleaza aplicatia voastra( iexplorer.exe, firefox.exe etc)

Daca nici o solutie nu a functionat, atunci puteti incerca sa instalati din nou tool-urile pentru Silverlight, in unele cazuri chiar merge.

In cazul in care vreti sa folosti Firefox, este necesar sa faceti urmatori pasi:

• Load FireFox
• Type "about:config" into FF's address bar
• Accept the warning (if applicable)
• Search for the entry "dom.ipc.plugins.enabled"
• Change its value from "true" to "false" (double-click)
• Restart the browser

Enjoy

Read More

Silverlight - Diferente intre MAC OS si Windows OS.

Am fost întrebat zilele astea de doua persoane de limitările pe care le are Silverlight pe MAC OS. O sa încerc sa enumăr cîteva din aceste limitări mai jos.
1. Din cauza ca pe MAC unele tipuri de data nu exista sau sunt reprezentate diferit, este posibil ca metoda ToString() sa returneze valori diferite pe cele doua sisteme. Mai interesant este cand apelam ToString() pentru
Single.PositiveInfinity.ToString()
In cazul MAC-ului o sa obtinem "+oo", iar pe Windows o sa avem "Infinity".
2. Cand lucram cu informatii despre cultura (CultureInfo) rezultatele o sa difere intre cele doua sisteme chiar daca avem aceiasi cultura setata. Totodata TextInfo.ListSeparator pe MAC OS va returna mereu caracterul ',' indiferent de cultura pe care o avem setata.
3. Daca folosim metoda SaveFileDialog, aceasta nu o sa afiseze la user nici o eroare cand userul foloseste caractere invalide, dar in schimb se va arunca exceptia System.ArgumentException pe care noi trebuie sa facem cache.
4. Parsarea de URL-uri difera pe MAC, din aceasta cauza putem sa ne trezim cu '\' in loc de '/'.
5. Evenimentele de click pe butonul stang sau drept al mouse-ului (MouseRightButtonDown, MouseLeftButtonDown, ...) nu sunt suportate in totalitate pe MAC OS, deoarece nu avem 2 butoane pe mouse la toate device-urile. Din aceasta cauza aceste evenimente pot sa fie aruncate fara sa le putem controla de diferite device-uri pe care userul le are instalate.
6. Evenimentele de MouseWheel nu sunt suportate deloc pe MAC OS daca aplicatia nu ruleaza out of the brower. Daca ruleaza in brower e nevoie sa facem handle la ele prin intermediul DOM-ului HTML.
7. In cazul in care folositi evenimente de KeyPress, este bine de stiut ca exista PlatformKeyCode, care difera in functie de platforma.
8. Evenimentele de Drop nu sunt suportate pe MAC OS cand ruleaza in brower-ul Safari (dar exista un workaround pentru aceasta limitare.
9. Daca lucram cu socke-uri, modul in care sunt implementate difera usor, din aceasta cauza este bine sa verificam pe clasele pe care le folosim pentru socket-uri daca exista diferente pe cele doua platforme.
10. Resursele care sunt accesibile prin interop difera, din aceasta cauza trebuie sa verificam ce sistem de operare foloseste utilizatorul si sa apelam resursele corespunzatoare.
11. Implementarea la controler-ului WebBrower difera pentru cele doua sisteme, deoarece modul de randare este diferit.
12. Daca vrem sa facem debug, acesta poate sa fie facut doar prin Remote Debugging.
13. Pe MAC putem sa afisam o aplicatie Silverlight doar ca "windowed", pe cand pe Windows avem atat "windowed" cat si "windowless". Chiar daca avem o alta setare setata, pe MAC o sa fie folosita doar "windowed".
14. Exceptiile contine informatii diferite, iar unele pot sa fie eronate (linia si coloana unde a aparut exceptia).
15. Cand aplicatia ruleaza pe MAC OS in Safari, doua instante de HtmlPage.Window nu sunt egale.
16. MessageBox pe MAC OS o sa aibe mereu o icoana afisata, orice am face.
17. Zonele de access (cross-zone) difera pe MAC OS.

Daca ati mai gasit si alte diferente, va rog sa postati un comentariu.

Read More

(3) How to use Office in Silverlight applications

Lista postări despre Office interop pe Silverlight:

• Part 1
• Part 2
• Part 3

Si iată ca am ajuns la ultimul post din seria de 3 posturi despre Office Interop pe Silverlight.
Am rămas dator cu doua topice:

• cum sa închidem un proces office;
• cum sa scriem unit teste;

Pentru a putea închide procesul pe care îl avem pornit ajunge sa apelam direct metoda Quit(). Atenție, când se apelează aceasta metoda orice modificare deja făcuta nu o sa fie salvata. Pentru a putea face și save trebuie sa apelam și metoda metoda de salvare:

excelApp.Save();
excelApp.Quit();

In cazul în care dorim sa închidem doar un document separat putem sa apelam la metoda Close, care poate sa fie accesibila pentru fiecare document separat.

Testarea automata a unei aplicații care lucrează direct cu interop-ul de Office este destul de dificila. De exemplu cum putem sa testam dacă un document a fost deschis și este vizibil user-ului? Trebuie sa verificam ca avem în Windows o fereastra deschisa (lista de procese pornite în Windows nu este relevanta în acest caz).
Cu cat flow-ul dintre user și interop-ul de Office se bazează direct pe editarea documentelor direct dintr-o fereastra de Office, cu atât testarea este mai dificila. In cazul în care deschidem documentele Office pentru a editate sau vizualiza documente direct din aplicația noastră, atunci testarea este mult mai sigura, și mai ușor de făcut. Iar partea de mock pentru interop o sa fie mult mai ușor de scris.
Cea mai mare problema care poate sa apară este în momentul în care deschidem un document de doua ori, din doua procese separate, iar al doilea proces nu o sa poată sa facă save. In cazul în care pățim acest lucru și nu avem o referința la primul proces nu recomand sa închidem forțat primul proces care face lock pe document, deoarece s-ar putea ca userul sa îl fi deschis manual.

Read More

(2) How to use Office in Silverlight applications

Lista postări despre Office interop pe Silverlight:

• Part 1
• Part 2
• Part 3

In postul precedent am povestim despre problemele pe care le putem avea când încercam sa folosim API de Office pe Silverlight. Astăzi o sa discutam despre modul în care care trebuie configurat proiectul pentru a putea sa folosim API de Office și cum putem sa executam câteva funcții de baza.
Pentru a putea apela API de Office pe Silverlight este nevoie sa setam aplicația sa ruleze Out of the brower (OOB) și sa cu permisiuni elevate. Aceste setări trebuie setate pe proiectul de Silverlight care conține App.xml.
Click dreapta pe proiect în tab-ul Silverlight checkbox-ul "Enable running application out of the brower" sa fie check-uit iar în setările pentru out of the brower aveti grija sa check-uit și "Require Elevated trust when running outside the browser".
Pentru a putea sa accesam API de Office (COM-uri in general) din Silverlight o sa fim nevoiți sa lucram cu obiecte de tip dynamic. Crearea unei instante se face folosind AutomationFactory. Următoarea linie de cod creaza un obiect a aplicației Excel, prin intermediul căruia putem sa manipulam fișiere Excel.

dynamic excelApp = AutomationFactory.CreateObject("Excel.Application");

Pentru a putea sa deschidem un fisier deja existent este nevoie sa accesam lista de Workbooks, iar pe aceasta lista sa facem Open

dynamic workbooks = excelApp.Workbooks;
dynamic excelDoc = workbooks.Open([pathToFile]);

In cazul in care vrem sa deschidem un Excel pentru a afisa documentul pe care facem Open trebuie sa setam propietate Vizible pe excelApp pe true.

dynamic excelApp = AutomationFactory.CreateObject("Excel.Application");
excelApp.Visible = true;
dynamic workbooks = excelApp.Workbooks;
dynamic excelDoc = workbooks.Open([pathToFile]);

Bun, am deschis documentul, acuma il putem manipula in orice fel. La final este necesar sa inchidem documentul. Acest lucru se face in felul urmator:

excelDoc.Close(-1,1,true);

Primul parametru reprezinta un enum prin intermediul caruia se specifica daca se doreste sa se faca save la modificari. Din pacate, nu avem access direct la enumuri, din aceasta cauza trebuie sa folosim valoarea lor ca int.
Comanda SaveAs prin interop de Office arata destul de urat. Din cauza ca și parametrii opționali trebuie specificați aceasta ajunge sa arata în felul următor:

document.SaveAs(
               [pathToSave],
               Type.Missing,
               Type.Missing,
               Type.Missing,
               Type.Missing,
               Type.Missing,
               1,
               Type.Missing,
               Type.Missing,
               Type.Missing,
               Type.Missing,
               Type.Missing);

Valoare 1 reprezinta valoarea enum-ului XlSaveAsAccessMode care poate sa aibe urmatoarele valori:

• xlExclusive - exclusive mode;
• xlNoChange - default (don't change the access mode);
• xlShared - share list;

Fiecare document este însoțit de o colecție de propietati numite custom document properties. Acestea reprezinta o colecție de variabile pe care un utilizator le poate seta. In exemplul de mai jos obținem o referința la aceasta colecție pentru a verifica dacă conține variabila cu numele v1. In cazul în care aceasta valoare este "1", o sa ii setam o noua valoare.

dynamic excelCustomProps = excelDoc.CustomDocumentProperties;
for (int i = 1; i <= Count; i++)
{
   dynamic property = excelCustomProps[i];
   if ((string)property.Name == "v1" &&
       (string)property.Value == "1")
   {
       property.Delete();
       excelCustomProps.Add("v1",4,[valoareNoua],false);
   }
}

Ce trebuie stiut este faptul ca in momentul in care iteram pe aceasta lista index-ul incepe de la 1 nu de la 0. Iar orice modificare pe propietati se face in momentul in care facem save la document. O valoare a unei propietati nu am reusit sa o modific doar daca stergeam propietatea, iar apoi o adaugam iar.
Descrierea API-ului pentur Excel il puteti gasii aici: http://msdn.microsoft.com/de-de/library/ms262200%28v=Office.11%29.aspx.
In următorul post o sa vedem cum putem sa închidem cu tot procesul Excel pe care noi il lansam si cum putem sa facem unit-teste pentru acestea.

Read More

(1) How to use Office in Silverlight applications.

Lista postări despre Office interop pe Silverlight:

• Part 1
• Part 2
• Part 3

Acesta este primul post dintr-o serie de trei sau patru posturi în care o sa discutam despre Silverlight și interop (Office interop).
Dupa cum știm Silverlight suporta integrarea cu Office prin intermediul la interop, dar înainte sa ne aruncam cu capul în fata în API si sa vedem ce putem face o sa prezint ce nu putem face din Silverlight.
Nu avem acces la API-ul de Office in totalitate. Chiar daca in teorie folosim COM-urile de Office nu o sa putem apela orice metoda. De exemplu din cauza modului in care o aplicație Silverlight ruleaza pe o masina, nu o sa putem face pe client new la un nou document.
Dar acest lucru este cauzat direct de Silverlight, care nu ne permite sa generam fisiere pe client (in modul in care Office-ul are nevoie).
O solutie la aceasta problema este crearea fisierului pe server, iar apoi sa il copiem pe client. Putem sa avem templaturi care sa le copiem pe client si prin duplicarea lor sa replicam comanda de new.
Din cauza ca folosim obiecte de tip dynamic, putem foarte usor sa gresim apelul unui metode, iar apoi partea de debug pentru a identifica problema o sa fie criminala. Recomand crearea unui wrapper peste API-ul de Office.
Cand o sa incercam sa apelam o metoda o sa observam ca trebuie sa trasmitem ca si parametru valoarea unui enum de care nici nu am auzit pana atunci. Pentru a putea sa il folosim este nevoie sa apelam la msdn si sa trasmitem valorea efectinva a acestuia ca si un intreg.
O alta problema pe care aduce Silverlight-ul si pe care nu o putem rezolva este imposibilitatea de a transmite parametri prin nume:valoare.
De exemplu API-ul de Office este plin de metode cu parametrii optionali, dar din pacate noi nu o sa putem scrie:

document.Find("text",Page:10,Title:false)

O sa fim nevoiti sa specificam toti parametrii, iar cei pe care nu vrem sa ii folosim o sa trebuiasca sa ii specificam prin Type.Missing. Din aceasta cauza codul poate sa ajunga sa aibe forma urmatoare:

document.Find("text",Type.Missing,Type.Missing,Type.Missing,
Type.Missing, 10,Type.Missing,Type.Missing,Type.Missing,Type.Missing,Type.Missing,false,Type.Missing, Type.Missing)

Maine o sa discutam despre cum trebuie configurata o aplicatie Silverlight pentru a putea folosii API-ul de Office si o parte din API-ul pe care il avem la dispozitie.

Read More

Assembly comun intre mai multe tipuri de proiecte in Visual Studio

Uneori lucram cu proiecte care au assembly-uri atat pe Silverlight cat si solutii clasice .NET. Din pacate un assembly de Silverlight nu se fi adaugat ca si referinta la un proiect normal( sau invers).
O solutie la aceasta problema este sa adaugam fisierele ca si "Add as link" intr-unul din cele doua proiecte. Dar problema apare la compilare, in cazul in care apelam API care nu este suportat de una din platforme si uitam sa compilam fiecare solutie in parte pentru a face aceasta verificare.
Din aceasta cauza ne putem trezii cu neplaceri.
Ar fi frumos sa avem la dispozitie un proiect comun, pe care sa il putem referentia in orice proiect. Aici vine in ajutor Microsoft si ne pune la dispozitie Portable Library Tools.
Din pacate acest lucru trebuia facut in momentul in care au lansat Visual Studio 2010, dar niciodata nu este prea tarziu.
Cu ce ne ajuta acest tool? Avem posibilitatea sa avem un assembly comun intre Silverlight, XNA, Windows Phone, XBox si proiecte .NET clasice. Din pacate nu este perfect, inca se lucreaza la el, dar pana acuma nu am avur probleme cu el.
Dupa instalarea acestuia o sa avem un nou template in lista de proiecte la Visual Studio denumit: Portable Class Library. Acest proiect va putea sa fie adaugat ca referinta in orice alt proiect.

Read More

Cum sa facem handling la evenimente dontr-o pagina HTML afisare printr-un controler Silverlight

Pentru a putea face acest lucru avem nevoie de un mecanism prin care sa trasmitem evenimentul produs. O solutie este javascript.
In Silverlight avem doua controlare care se ocupa cu acest lucru WebBrower si HtmlBrush. Din pacare doar WebBrower stie sa faca handling la evenimente de java script. Prin intermediul acestora codul C# poate sa apele metode javascrip din interiorul paginii pe care o afisam sau sa se inregistreze la anumite evenimente(metode).
Pentru a putea face acest lucru este nevoie sa adaugam in fisierul xaml controlerul care ne permite sa afisam continut HTML:

<WebBrowser  x:Name="browserControl" />

Pasul urmator este sa ne inregistram la notificarea dorita. Aceasta notificare reprezinta un apel a unei metode din javascript.

 browserControl.ScriptNotify += new EventHandler<NotifyEventArgs>(BrowserControl_ScriptNotify);
...
void browserControl_ScriptNotify(object sender, NotifyEventArgs e)
{
     ...
}

In acest moment toate mesajele de notificare o sa fie prinse si procesate de catre metoda BrowserControl_ScriptNotify. In aceasta metoda parametrul e.Value reprezenta numele la notificarea pe care noi am primito.
In codul HTML pe care noi il afisam in controller, trebuie sa apelam metoda window.external.notify("nume_notificare").
Aceasta metoda se poate apela oriunde in codul javascript sau se poate atasa la tag-uri prin evenimentul onclick de exemplu.

Read More