[C#] AccountView COM koppeling

[Teknix1982]

Op dit moment moet ik voor een klant van ons een koppelingsapplicatie schrijven die relatie en factuurgegevens uit AutoTask leest (Middels een goed gedocumenteerde webservice) en deze gegevens doorsturen naar AccountView. Ik had zelf nog geen ervaring met AccountView koppelingen maar na wat speurwerk ben ik ver gekomen. In overleg met de klant is gekozen voor een COM koppeling met XML berichten. Dit is overlegd met AccountView en dit is mogelijk. Tijdens de ontwikkeling hebben we eerst de XML berichten gemaakt. Deze hebben we getest met de import module van AccountView en deze werken.

Nu heb je binnen de AccountView COM classes de functie doxml(string xml). Deze wil ik gebruiken om de XML berichten in AccountView te verwerken. En hier gaat het fout. Mijn code ziet er als volgt uit:

C#:

        private string SendToAccountView(string xml)
        {
            try
            {
                Type avType = Type.GetTypeFromProgID("avwin.application");
                if (avType != null)
        {
                    object avObj = System.Activator.CreateInstance(avType);
                    string response = (string)avType.InvokeMember("doxml", BindingFlags.InvokeMethod, null, avObj, new Object[] { xml });
                    XmlDocument doc = new XmlDocument();
                    doc.LoadXml(response);

                    return doc.ToString();
        }
            }
            catch (Exception e)
            {
                return e.Message.ToString();
            }
        }

Ik heb de AccountView COM server geregistreerd en het vinden van het type avwin.application gaat ook goed. Echter bij het aanmaken van een instantie gaat het fout. De volgende foutmelding krijg ik:

Het ophalen van de COM-classfactory voor het onderdeel met CLSID {AF3FF4B3-E0EF-4187-B7A2-8F54CB092000} is mislukt vanwege de volgende fout: 80040154 Klasse is niet geregistreerd (Uitzondering van HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).

Wanneer ik op deze foutcode zoek worden er op internet een aantal mogelijkheden aangeboden als oplossing:
1. De DLL is niet goed geregistreerd. AccountView levert alleen een type library mee en deze hebben we omgezet naar een DLL met tlbimp.exe. Is dit voldoende?

2. De koppelingsapplicatie is 64 bits terwijl de COM objecten 32 bits zijn. Dit is niet het geval, de applicatie die ik geschreven heb is 32 bits.

AccountView wil geen support leveren omdat er eerst een 3 daagse cursus gevolgd moet worden. Ik heb al heel wat koppelingen geschreven in mijn leven alleen nog nooit met AccountView. Ik heb zelden zo'n slechte ondersteuning gekregen. Die cursus ga ik niet volgen en ik ben er van overtuigd dat er hier vast mensen zitten die al is met dit probleem te maken gehad hebben. Ik hoop dat jullie mij verder kunnen helpen.

[Sircuri]

1e vraag: waarom een COM oplossing? Als iets ellende is dan is het wel COM.

Verder zie ik niet in je bericht of je die com klasse ook hebt geregistreerd op je computer. Type.GetTypeFromProgID kijkt in je registry en gaat op zoek naar die klasse. Daarnaast is beveiliging ook altijd een hot issue bij com applicaties.

[Teknix1982]

Deze licentie was reeds aanwezig bij de klant en was een eis van de klant. Ik heb hem daarop gewezen en ook de mogelijkheid aangedragen van de AccountView BackOffice server maar dat was geen optie.

De Type.GetTypeFromProgID vind de avwin.application wel in het register op de server. Moet ik echter de DLL file expliciet nog registreren op de server? Dit heb ik inmiddels geprobeerd door hem in c:\windows\System32\ te plaatsen en dan regsvr32 aan te roepen en krijg de volgende melding:

Module 'c:\windows\system32\avwin.dll' is geladen, maar het toegangspunt DllRegisterServer is niet gevonden.

Zorg ervoor dat 'c:\windows\system32\avwin.dll' een geldig DLL- of OCX-bestand is en probeer het vervolgens opnieuw.

[Woy]

Ik wil je allereerst vast condoleren met het gebruik van de AV COM koppeling, wat een drama's heb ik daar mee gehad zeg

Bij ons was het in ieder geval zo dat er in de AV directory een bat bestand aanwezig was die het COM component registreert. Kopieren naar System32 zou niet nodig hoeven zijn, want de DLL wordt gewoon binnen de AV dir geregistreerd.

Er is overigens ook gewoon info te vinden op de site van de leverancier: http://software.nl.visma.com/av52651.htm

[ Voor 14% gewijzigd door Woy op 11-07-2013 10:03 ]

[Teknix1982]

Woy schreef op donderdag 11 juli 2013 @ 10:02:
Ik wil je allereerst vast condoleren met het gebruik van de AV COM koppeling, wat een drama's heb ik daar mee gehad zeg

Dank je, ik vind het ook een drama pakket en wat een slechte support!

Bij ons was het in ieder geval zo dat er in de AV directory een bat bestand aanwezig was die het COM component registreert. Kopieren naar System32 zou niet nodig hoeven zijn, want de DLL wordt gewoon binnen de AV dir geregistreerd.

Er is overigens ook gewoon info te vinden op de site van de leverancier: http://software.nl.visma.com/av52651.htm

Uiteraard heb ik deze pagina ook gevonden en oplossing 1 is uitgevoerd. Alleen test de COM koppeling gaat verkeerd. Zie bovenstaande melding.

Oplossing 2 is niet van toepassing.

Oplossing 3, ik gebruik een account waarmee ik de handeling wel handmatig in AccountView mag doen.

Oplossing 4, wij hebben COM server, nu heb ik net even navraag gedaan intern en kreeg door dat het bedrijf niet COM CAL heeft aangeschaft. Die is dus ook nog nodig. Het vreemde is wel dat de klant verteld dat er altijd een koppeling lag tussen hun vorige pakket en AccountView en dat deze geen COM CAL licentie had en dat de server genoeg was.

AANVULLING:
Ik heb over oplossing 4 toch nog is nagedacht maar dat lijkt me niet de oplossing voor mijn foutmelding:

Het ophalen van de COM-classfactory voor het onderdeel met CLSID {AF3FF4B3-E0EF-4187-B7A2-8F54CB092000} is mislukt vanwege de volgende fout: 80040154 Klasse is niet geregistreerd (Uitzondering van HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).

Graag nog input van jullie?

[ Voor 20% gewijzigd door Teknix1982 op 11-07-2013 10:43 ]

[Coca-Cola]

Ik weet verder niets van accountview of hun com integratie, maar heb jij nou wel of geen com dll van AV? Je schrijft dat je zelf een dll hebt gegenereerd? Dat je de dll niet kan registreren kan betekenen dat het helemaal geen com dll is (of in een onwaarschijnlijk geval dat je regsvr32 niet als admin runt), maar in ieder geval lijkt me dat daar je probleem zit.

[Teknix1982]

Wat AccountView aanlevert is een avwin.tlb die in de accountview directory staat. Daarnaast geeft AccountView aan dat het registreren van de COM server gedaan moet worden met register.bat als administrator uit te voeren. Als ik die open staat het volgende er: AVWIN.exe /regserver (dit is gebeurt) Sindsdien vind hij de class type ook, alleen blijkbaar moet de COM dll nog geregistreerd worden op de server. Maar die DLL heb ik niet, ik heb alleen een tlb. Daar kan ik wel een dll van maken maar die kan ik niet registreren.

[Coca-Cola]

Hmm, is het geen .net assembly? Je zou regasm of regtlib kunnen gebruiken om ofwel je tlb als com dll te registeren ofwel je tlb te registeren. Ik heb er maar beperkte ervaring mee overigens, maar ik vermoed nog steeds dat hier ergens je probleem zit...

[RobIII]

Ik kan je adviseren (been there, done that, gecondoleerd overigens want AV zuigt hard...) een dagje op "cursus" te gaan bij AV. Kost je (lees: de opdrachtgever) een paar honderd euro maar dat scheelt je een bak frustratie tot-en-met. Het is voor mij inmiddels weer een jaar of 7...9... zoiets geleden en weet niet wat de huidige stand van zaken is maar de documentatie (voor zover je die zo mocht noemen) bevatte weinig tot geen nuttige informatie (gewoon een dump van de (toenmalige equivalent van) "XMLDoc"/"PHPDoc") en de paar online documenten wisten ook amper iets zinnigs te vertellen. Op die "cursus" waar ik indertijd, an-sich, weinig tot niets "in de les" opstak anders dan een "aha momentje" of 2 kreeg je in ieder geval nog een CD'tje mee met wat PDFjes en andere zaken waar meer zinnigs in stond. Documentatie was, om een voorbeeld te geven, in de trant van:

function AddOrder(int customerid, int productid, int someotherid, string dingy)
AddOrder: Adds an order Duh...customerid: Customer ID ECHT... productid: Product ID No shit sherlock... someotherid: Some Other Id ... en waar haal ik die vandaan? Waar dien't die voor? Is 't optioneel? thingy: Thingy (see thingy) ... waarbij de link dan naar een compleet nieuwe pagina linkte waarop je las: Thingy: used in AddOrder. Punt.

De cursus ging in ieder geval even vlug over het "opzetten van de ontwikkelomgeving" (zoals geklooi met DLL's, TLB's etc.), wat ongedocumenteerde zaken werden aangestipt als "handig om te weten mocht je ooit vastlopen op iets" (lees: dit ga je voor fuckin' iedere scheet nodig hebben) en de persoon "voor de klas" kon in de koffiepauze en naderhand even flink uitgehoord worden over allerlei zaken die helemaal niet aan bod kwamen in de "les".

Either way: AV is (iig: was indertijd) een bitch om mee te werken, laat staan tegenaan te programmeren. Het is zoals ik al zei lang geleden, maar de frustraties zitten nog diep Heb er diverse flinke rants op GoT over gehouden (voornamelijk in crewfora volgens mij). Na lang geklooi met allerlei zooi heb ik de FoxPro (indertijd nog) driver genomen en gewoon (zolang 't READ-ONLY acties waren!!!) rechtstreeks de DB gequeried; zaken die een WRITE vereisten gingen wel door de COM componenten heen om zo te zorgen dat alle Business Logic van AV in ieder geval toegepast werd. Nogmaals: ik leef met je mee.

* RobIII krijgt flashbacks... Iets met "Database repareren" en "Database optimaliseren" en dat soort geintjes, die je uiteindelijk ooit 15 keer per dag(!) moest uitvoeren omdat AV niet vooruit te fikken was en altijd in een inconsistente staat verkeerde... AV bleek dan (nogmaals: indertijd, geen idee hoe 't nu is) niet opgewassen tegen 't aantal klanten/orders/etc. dat we deden.

Edit: heb ooit iets vergelijkbaars gepost hier.

[ Voor 9% gewijzigd door RobIII op 11-07-2013 12:37 ]

[Teknix1982]

Dank jullie allen voor de medeleving. Het is een veel gehoord iets als je over AccountView en koppelen begint.

Ik heb met mijn opdrachtgever overlegd en een cursus doen is geen optie. Ik ga die ook niet zelf financieren. Het enige wat ik nog moet weten is of ik die handmatig AvWin.tlb moet registreren op de server en hoe ik dat moet doen. Is er niemand meer die dat nog weet? De berichten voor debiteuren muteren en facturen inboeken heb ik al en werken al. ik moet alleen nog kunnen inloggen en de functie doxml() kunnen aanspreken na het inloggen.

[ Voor 18% gewijzigd door Teknix1982 op 11-07-2013 13:37 ]

[Sircuri]

Even een stapje terug. Waar ontwikkel je? Ik neem op je lokale desktop? Op je desktop heb je die COM objecten niet staan denk ik.
Daarnaast heb je die type library inderdaad nodig om een interface te genereren voor in je applicatie.
Vertel even de setup die je nu gebruikt.

[Teknix1982]

Ik ontwikkel op mijn desktop inderdaad. Dit is een windows 8 omgeving met visual studio 2012. Daar heb ik de COM objecten inderdaad niet staan. Maar ik test de applicatie ook nadat ik deze gepubliceerd heb op de IIS server (Windows 2008 server R2) en werk op dit moment even met trail en error ( hoe irritant ook). Ik kan de dll die ik uit de tlb bestand genereer wel toevoegen als referentie en dan herkent hij de methodes wel maar het werkt dan niet op de live server. Daarnaast hebben de methodes dan geen parameters terwijl ik zeker weet dat login en doxml sowieso parameters verwacht.

Het totale systeem is een web based applicatie in C# met ASP.NET MVC 3. Wij ontwikkelen altijd services voor een applicatie in een apart project (DLL). Deze services worden als referentie toegevoegd aan de web applicatie en de services implementaties worden geinjecteerd in de web applicatie met Ninject. Een service voor deze applicatie is de AccountViewExportService. Deze voert het stukje code uit dat in de openingspost staat. De applicatie draait op de server waar ook AccountView staat. De stappen die ik doorlopen heb.

1. ik heb de XML berichten gemaakt en getest met de klant via de import functie die in AccountView zit.
2. ik heb de user interface gemaakt zodat er per factuur op een knop geklikt kan worden die een XML bericht maakt en deze naar AccountView gaat versturen. Dit gaat zo omdat de klant controle wil hebben welke facturen en debiteuren naar AccountView gaan.
3. Ik heb daarna de webapplicatie op de server geinstalleerd.
4. Ik heb register.bat aangeroepen die de AccountView COM Server registreert
5. Ik heb de koppeling getest en hij vindt de type wel in het register maar geeft de melding dat de class niet geregistreerd is nadat ik een instantie van het object wil aanmaken met System.Activator.
6. Ik heb een DLL gegenereerd met tlbimp.exe van avwin.tlb en in de accountview directory geplaatst
7. Ik heb de DLL geprobeerd te registreren met regsvr32 en RegAsm.exe /codebase. Dit laatste lukt niet.

Regsvr32 gaf de volgende melding:

Module 'c:\windows\system32\avwin.dll' is geladen, maar het toegangspunt DllRegisterServer is niet gevonden.

Zorg ervoor dat 'c:\windows\system32\avwin.dll' een geldig DLL- of OCX-bestand is en probeer het vervolgens opnieuw.

RegAsm gaf de volgende melding:

Could not load file or assembly avwin.dll or one of it's dependencies

Operation is not supported

Echter stappen 6 en 7 heb ik zelf bedacht om te gaan doen en weet niet of dit überhaupt moet. Ik heb lang geleden ooit wel is wat met COM gedaan in microsoft outlook maar wij ontwikkelen tegenwoordig meer met .NET en Webservices en niet zozeer met COM en ATL. Daarnaast wilde AccountView geen support meer geven na stap 4, hoe ik de COM server moet registreren. Maar dit wist ik al wel.

[ Voor 20% gewijzigd door Teknix1982 op 11-07-2013 22:08 ]

[Teknix1982]

Nog iemand een idee? Ik kan de hulp nog wel goed gebruiken.

[Woy]

Als je snel wat wil testen kan je ook gewoon even met een VBScript filetje op de server testen. Dan hoef je niet telkens wat te compilen en te kopieren. Maar kun je gewoon met een text-editor wat uitproberen.

Toen ik met AV werkte was het in ieder geval voldoende om de Register.bat aan te roepen, maar verder is het gelukkig al te lang geleden om me er veel van te herrineren

[Teknix1982]

Het probleem is verholpen, de COM server was weldegelijk actief echter de beheerder van de server had de rechten van de IIS gebruiker die de applicatie runt niet goed staan. Toen deze goed stond was dit opgelost. De COM koppeling werkt naar behoren, gelukkig doe ik niet meer dan een paar XML berichten versturen. AccountView en COM is niet bepaald ideaal werken.