Windows 2008 Server + Office 2007 = InteropServices.COMException (0x800A03EC): Microsoft Office Excel cannot access the file

Mi-am prins astazi urechile cu urmatoarea eroare:

InteropServices.COMException (0x800A03EC): Microsoft Office Excel cannot access the file

Aceasta eroare era ascunsa in spatele unei erori de tip NullReferenceException. Eroare aparea pe linia de cod car facea open la un excel.

myBooks.Open(fileName, 0, true, missing, missing, missing, true, missing, missing, missing, missing, missing, missing, missing. missing);

Ce era cel mai curios ca acest lucru se intampla doar in productie, pe un Windows Server 2008 pe 64b (x64). Aceasta problema nu aparea pe nici o masina de dezvoltare cu Windows 7, nici pe build machine sau pe masina de testare.
Am incercat sa i-au pe rand diferite cauze la aceasta problema. Am verificat daca nu cumva excel-ul este deja deschis de un alt proces. Fisierul nostru nu era deschis de nici un alt proces. Path-ul spre fisier era corect, nu era nici o problema de drepturi de acces pe fisierul dat.
Cautand o posibila cauza am gasit o cauza destul de ciudata, care in cazul meu se pare ca a rezolvat si problema. Pe sistemele WIndows 2008 Server, nu se ai creaza automat un folder de care are nevoie COM-ul de Office pentru a deschide un fisier.
Pentru Windows 2008 Server x86 este nevoie sa creati urmatorul folder:

C:\Windows\System32\config\systemprofile\Desktop

, iar pentru Windows 2008 Server x64:

C:\Windows\SysWOW64\config\systemprofile\Desktop

Nu intrebati de ce am avut nevoie de a procesa pe server fisiere Excel, stiu ca nu este recomandat, dar aceasta era o cerinta care ne-a venit.
Din cate am investigat pana acuma aceasta problema apare doar pe Windows 2008 in combinatie cu Office 2007. Pentru noi aceasta solutie ne-a rezolvat problema :-)

Read More

Interop - release COM objects( Excel.EXE hanging)

Pentru mine "interopul" a fost mereu o provocare. Nu neaparat modul prin care se pot face apelurile ci modul in care se face dispose la acestea si eliberarea resurselor.
O sa ma duc pe un exemplu concret - interopul cu Excel. Cand lucram cu acesta viata noastra poate sa devina un iad daca nu eliberam resursele corespunzator. Daca avem un serviciu windows care proceseaza fisiere Excel, foarte usor ne putem trezii ca avem 100 de procese EXCEL.EXE ramase agatate in sistem cu care nu stim ce sa facem. Dar asta nu e tot, fisierele raman agate pe disk pana cand cineva omoara procesul.
Sa incepem cu inceputul. Pentru a putea accesa un fisier Excel folosind Microsoft Office, avem un cod asemanator cu acesta:

Application application = new Application()
     {
        Visible = false,
        UserControl = true,
    };
Workbook workbook = Application.Workbooks.Open(fileName, 0, false, 5, "", "", true, XlPlatform.xlWindows, "\t",true,false, 0, true, 1, 0);
Worksheet worksheet = (Worksheet)Workbook.Worksheets.Item[1];
Range range = Worksheet.UsedRange;
.....
string value = (range.Cells[rowNumber, columnNumber] as Range).Text;

Pentru fiecare obiect din Office trebuie sa facem explicit dispose folosind
"System.Runtime.InteropServices.Marshal.ReleaseComObject(obj)".
Trebuie avuta mare grija, deoarece in exemplul dat mai sus ultima linie de cod contine un obiect la care o sa pierdem referinta si la care nu o sa mai putem face dispose:

range.Cells[rowNumber, columnNumber] as Range

Un apel corect, care o sa ne permita sa facem si dispose ar fi:

Range cell = range.Cells[rowNumber, columnNumber] as Range;
string value = cell.Text;

In acest fel o sa putem face release si la obiectul care are o referinta la celula pe care o procesam.
Inainte sa facem release la Workbook si Application este nevoie sa le inchidem si sa facem quit pe ele:

workbook.Close(false, Type.Missing, Type.Missing);
Application.Application.Quit();
Application.Quit();
O implementare a metodei care face release pentru exemplul nostru ar putea sa fie urmatoarea:
System.Runtime.InteropServices.Marshal.ReleaseComObject(cell);
workbook.Close(false, Type.Missing, Type.Missing);
Application.Application.Quit();
Application.Quit();
System.Runtime.InteropServices.Marshal.ReleaseComObject(range);
System.Runtime.InteropServices.Marshal.ReleaseComObject(worksheet);
System.Runtime.InteropServices.Marshal.ReleaseComObject(workbook);
System.Runtime.InteropServices.Marshal.ReleaseComObject(application);
GC.Collect();
GC.WaitForPendingFinalizers();

Dupa cum se poate observa toate actiunile care se fac sunt destul de complexe si trebuie avut grija ca sa se face release la fie obiect in parte. Daca nu eliberam aceste resurse o sa ne trezim cu procese de tip EXCEL.exe ramane in memorie la care trebuie sa facem manual dispose( kill). Ca sa ne usuram putin viata putem sa ne definim o clasa generica care sa faca release automat la obictele din COM.

public class AutoReleaseComObject<TComObject> : IDisposable
        where TComObject : class
    {
        private TComObject _comObject;
        private bool _disposed = false;

        public AutoReleaseComObject(TComObject comObject)
        {
            _comObject = comObject;
        }

        public TComObject ComObject
        {
            get { return _comObject; }
        }

        public void Dispose()
        {
            Dispose(true);
            GC.SuppressFinalize(this);
        }

        protected virtual void Dispose(bool disposing)
        {
            if (_disposed)
            {
                return;
            }
            lock (this)
            {
                if (_disposed)
                {
                    return;
                }

                int refcnt = 0;
                do
                {
                    refcnt = System.Runtime.InteropServices.Marshal.ReleaseComObject(_comObject);
                } while (refcnt > 0);

                _comObject = default(TComObject);
                _disposed = true;
            }
        }
    }

Cam asa ar arata implementarea pentru un obiect COM. Daca aveam nevoie sa facem si alte actiuni, asa cum facem pentru Application, putem sa face ovverite la metoda Dispose si sa facem intr-un alt mod eliberarea de resurse.
Totul o sa fie bine pana cand un alt dezvoltator o sa vina si o sa ne modifice codul cand fara sa isi dea seama nu o sa faca release la resurse. De exemplu in urmatoarea line de cod:

((Range)range.get_Value(rangeValueDataType)).QueryTable.Creator

se pierde referinta la doua obiecte la care nu o sa se mai poata face dispose. Prima greseala este obiectul returnat de 'get_Value', la care trebuie sa se faca dispose. Al doilea obiect este QueryTable unde apare aceiasi problema. Corect ar trebui sa avem:

Range itemRange = (Range)Range.get_Value(rangeValueDataType);
QueryTable queryTable = itemRange.QueryTable;
XlCreator creator = queryTable.Creator;

Daca folosim solutie prezentata putin mai sus am obtine urmatorul cod:

using (AutoReleaseComObject<Range> range=GetRange())
            {
                using (AutoReleaseComObject<Range> itemRange = range.ComObject.get_Value(rangeValueDataType))
                {
                    using (AutoReleaseComObject<QueryTable> queryTable = itemRange.ComObject.QueryTable)
                    {
                        XlCreator creator = queryTable.Creator;
                    }
                }
            }

Si totusi sunt diferite cazuri cand un obiect COM ne scapa si ne trezim cu un proces agatat. Exista si diferite probleme cu inteoropul de Office din cauza carora nu se poate face release la date corespunzator si ne trezim ca nu putem sa scapam de proces.
O solutie destul de hard-core, care trebuie folosita cu mare grija este sa omoram direct procesul. In exemplul de mai jos o sa obtin Hwnd( adrsa din memorie) din procesul EXCEL.exe pe baza caruia putem obtine id-ul procesului EXCEL.EXE pe care dorim sa il omoram.

[DllImport("user32.dll")]
private static extern uint GetWindowThreadProcessId(IntPtr hWnd, out uint lpdwProcessId);
...
int currentHWn =application.Hwnd
uint processID;
GetWindowThreadProcessId((IntPtr)hWnd, out processID);
if (processID != 0)
{
    Process.GetProcessById((int)processID).Kill();
}

O alternativa la interop pentru Office este Open XML: http://msdn.microsoft.com/en-us/library/bb448854%28office.14%29.aspx
Succes!

Read More

Office document and custom properties in .NET 3.5

In documentele Office( Excel, Word, ..) putem sa stocam meta-propietati. Aceste meta-propietati sunt denumite custom properties. O parte din ele sunt definite de catre fiecare utilizator in parte, iar altele exista by default.
Informatii precum "Last Saved Time" sau "Last Author" sunt setate automat de catre Office in momentul in care lucram cu un document. In cazul in care dorim sa accesam aceste informatii din .NET 4.0 este destul de simplu, dynamic types isi face perfect treaba aici.
Partea interesanta este cand este nevoie sa accesam aceste date din .NET 3.5 de exemplu, unde dynamic types exista, dar nu ne permite sa il folosim asa cum am dorii.
Pentru a putea sa accesam custom properties dintr-un document Office, in .NET 3.5 trebuie sa ne reintoarcem putin in timp. Orice incercare de a accesa aceste propietati direct, o sa termine cu o eroare de COM la runtime.

((DocumentProperties)docWorkbook.BuiltinDocumentProperties)["Last Author"]
((DocumentProperties)docWorkbook.BuiltinDocumentProperties).Items[0]

Ca sa putem accesa aceste valori este nevoie sa apelam la Reflection. Orice call pe care il facem pe obiectul de tip DocumentProperties trebuie sa se faca prin reflection. Din cauza ca este un lazy binding, orice conversie a propietatii BuiltinDocumentProperties spre DocumentProperties o sa se termine cu o exceptie.
Mai jos gasiti un sample de cod care permite accesul la meta-propietatiile unui document Office.

private string GetDocumentProperty(Application doc, string propertyName)
      {
          object documentProperties = doc.Workbook.BuiltinDocumentProperties;

          Type propertiesType = documentProperties.GetType();
          object properties = propertiesType.InvokeMember("Item",
                               BindingFlags.Default |
                               BindingFlags.GetProperty,
                               null, documentProperties,
                               new object[] { propertyName });

          Type propertyType = properties.GetType();
          return propertyType.InvokeMember("Value",
                                     BindingFlags.Default |
                                     BindingFlags.GetProperty,
                                     null, properties,
                                     new object[] { }).ToString();
      }

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