Har ett jättekonstigt problem som jag inte har en aning om vad jag skall göra åt.

Jag har skapat en .net assembly som samtidigt fungerar som COM-server. Ett vanligt VS installationsprojekt installerar assemblyn i GAC. Assemblyn är strong-name.

Det har fungerat bra ganska länge på många olika datorer med XP, Vista, Office XP/2003/2007.

Nu har några nya kunder fått problem med att assemblyn inte fungerar i Excel (VBA). Det konstigaste är att när de försöker använda den så stängs datorn av! Eftersom Excel har en dialogruta uppe som sägera att den inte kan hitta assemblyn så går det att avbryta avstängningen men alla andra program avslutas.

Eftersom alla andra program stängs av är det lite svårt att felsöka. Jag har dock lyckats hitta följande:
1. Assemblyn laddas inte, dvs ingen del av min kod körs överhuvudtaget.
2. På samma dator fungerar det fint att använda assemblyn via VBScript och Visual Studio.
3. Avinstallera och installera igen gör ingen skillnad.
4. Det händer på flera (ev alla) datorer hos samma kund.

Någon som har en idé om var jag skall leta efter problemet? Är det Excel, installationsprojektet, fusion loader, anti-virus eller något annat?

Och du hittar inga fel i någon loggfil? Avinstallerar du denna så fungerar allting bra eller? Skriv i eventloggen från din service om det inte finns nån felhantering där - så kanske du kan börja hitta vad det är som felar.

Och du hittar inga fel i någon loggfil?
>Nix har kollat system/application/Security etc

>Avinstallerar du denna så fungerar allting bra eller?

Allt fungerar bra när den är installerad också. Det är bara när man försöker använda assemblyn från excel som datorn stängs av.

>Skriv i eventloggen från din service
Det är ingen service, utan en COM server. COM server innebär bara att den kan anropas från COM klienter (dvs exporterar ett interface). Det finns ingen server process eller något sådant.

I Excel skriver jag
Dim obj As New MinAssembly
och i VBScript
Set obj = CreateObject("MinAssembly")

Som jag skrev så körs ingen kod i min assembly eftersom den inte hittas när Excel skall öppna den på dessa datorer.

Och det har fungerat förut samt existerande datorer och det smäller bara på nya datorer?

Vad är det du gör med objektet och vad används det till? Det kanske går att skriva om det lite fiffigare så det fungerar bättre? Kan det vara svenska / eng office? Servicepacks eller inte?

>Och det har fungerat förut samt existerande datorer och det smäller bara på nya datorer?

Det är inte nya datorer, bara några nya kunders datorer.

>Vad är det du gör med objektet och vad används det till? Det kanske går att skriva om det lite fiffigare
>så det fungerar bättre?

Min kod exekveras inte överhuvudtaget så det spelar ingen roll vad den gör.

>Kan det vara svenska / eng office? Servicepacks eller inte?

Det är inget sånt som skiljer dessa datorer från sådana där det fungerar.

Har precis hittat en sak som är gemensam för dessa datorer. .Net 2.0 var inte installerat före installationen och därför laddades ner av installationsprogrammet. Det verkar vara någon standardpryl i VS installationsprojekt för jag har inte lagt till det. Vet dock fortfarande inte om det har med saken att göra eller vad jag skall göra åt det.

Ditt program, kör den net framework 1.1 eller 2.0?

Något med brandväggar/virusskydd?

>Ditt program, kör den net framework 1.1 eller 2.0?

2.0

>Något med brandväggar/virusskydd?

Själva nedladdningen och installationen går bra. Assemblyn fungerar ju också fint från både VBScript och Visual Studio. Tänkte också att det kanske har något med virusskydd att göra men förstår inte varför det skulle ställa till det enbart för Excel. Dessutom borde ju inte anti-virusprogrammet stänga va datorn.

Om du instansierar COM-objektet från något annat än just Excel/VBA, då?

>Om du instansierar COM-objektet från något annat än just Excel/VBA, då?

Från VBScript fungerar det utan problem.

Enda skillnaden jag vet är att VBScript använder IDispatch medan VBA använder com interfacet. Det fungerar ju som sagt på många andra datorer så jag tror inte problemet ligger där. För säkerhets skull skall jag kolla vad som händer om jag använder IDispath (dvs CreateObject) från VBA.

Kan det ha med kodbaserad säkerhet att göra, om du har skrivit en .NET Assembly som anropas av Excel så har jag för mig att den assemblyn måste ges "FullTrust" Permission Set genom att skapa en speciell kodgrupp. Titta på din utvecklingsdator i ".NET 2.0 Framework Configuration" och se om du kan hitta den kodgruppen.

Om det skulle kunna vara detta så ska jag försöka vara lite tydligare i nästa svar, sitter lite dumt till när jag skriver detta...

>Kan det ha med kodbaserad säkerhet att göra, om du har skrivit en .NET Assembly som anropas av
>Excel så har jag för mig att den assemblyn måste ges "FullTrust" Permission

Jag funderade också på det men grävde inte så djupt i det av flera anledningar:
1. Kodbaserad säkerhet gäller enbart i .Net. Excel/VBA ansluter till ett COM objekt som i sin tur öppnar en .Net assembly. Det är ju samma COM hostingprocess som används oavsett om man ansluter från Exel/VBA eller VBScript.
2. Om det är ett säkerhetsproblem skulle det ju generera ett security exception och inte stänga av datorn.

Men hur gick det med CreateObject?

Har du VB6?
Vad händer om du i så fall testar med early binding i ett VB6-program, borde ju bli identiskt resultat?

Har du assemblerat din DLL till en TLB-fil ?
Den ska ligga i win32 och i Excell's exe-map om jag inte minns fel.

/Martin

Efter hur mycket jobb som helst så har jag hittat felet.

Det som ledde mig på spåret var att jag hade en dialogruta i installationsprogrammet som visades ibland. En kund rapporterade att denna dialogruta visades precis innan datorn stängdes av.

Det var alltså windows installer som stängde av datorn! (brydde mig inte om att ta reda på varför)

Jag provade då att installera min assembly manuellt med regasm. Resultatet blev precis detsamma (dvs fungerar från VS och vbscript men ej från Excel) men datorn stängdes inte av.

Googlade på regasm, excel mm och hittade såsmåningom några som hade liknande problem.

Lösningen var att installera en obskyr officepatch med namnet KB908002 <url>http://support.microsoft.com/kb/908002/</url>.

Problemet finns i alla officeversioner till och med 2003.