[C#.NET] Wie/wat startte het process?

Pagina: 1
Acties:

Acties:
  • 0 Henk 'm!

  • Crazybyte
  • Registratie: Juli 2002
  • Laatst online: 15-09 10:07
Situatie:
Het ERP pakket dat hier gebruikt wordt heeft de mogelijk om via COM benaderd te worden. Deze COM heeft o.a. een functie Login() en Logout(). Bij de door mij te maken applicatie moet ingelogd worden, het idee daarbij is dat men inlogt met de credentials die men gebruikt in het ERP pakket. In de te maken applicatie controleer ik dan met behulp van een aanroep naar Login() of die gegevens kloppen. Deze geeft namelijk 'true' terug wanneer er ingelogd is. Wanneer ik 'true' terug krijgen, kloppen de gegevens en krijgt de persoon toegang tot mijn applicatie.

Probleem:
Aanname: Er is ingelogd met juiste credentials en Login() heeft een 'true' teruggegeven.
De gebruiker wil nu uitloggen en onder een andere naam of gewoon opnieuw inloggen. We roepen Logout() aan en vervolgens loggen we in met de (nieuwe) credentials, er volgt dus weer een aanroep naar Login(), maar deze returned nu 'false' ondanks dat de credentials wel degelijk correct zijn.
Een test (in VB) door de leverancier liet zien dat als je het object verwijderd en weer opnieuw aanmaakt, dat Login() wel weer 'true' geeft bij juiste credentials.

Dat ben ik dus gaan uitproberen, zet die variabele op null (na een Logout()) en creëer hem opnieuw bij een nieuwe inlog, dat werkt, geen enkel probleem, toch? Wel dus, want de aangeroepen COM blijft als process draaien en er wordt gewoon een nieuw process gestart. Bij het uiteindelijk afsluiten van de te maken applicatie, sluit hij het laatst gestarte process af en de rest blijft actief.

Oplossing:
Nou had ik bedacht dat ik misschien zelf kan bijhouden dat het process gestart is en deze gewoon geforceerd via Process.Kill() kan afsluiten na een aanroep naar Logout(). Een klein probleempje hierbij is dat het process, aangezien het om de exe van het ERP pakket gaat, waarschijnlijk al minimaal één keer actief is bij de gebruiker. Ik wil er dus achter komen wie het process gestart heeft, was dat de gebruiker die het ERP pakket gestart heeft of was dat mijn applicatie? Hij moet natuurlijk alleen dat process afsluiten dat door mijn applicatie is gestart.

Vraag:
Kan ik zien wie het process gestart heeft of is dat niet te achterhalen? Dan kan ik namelijk gewoon dat process afsluiten. Of moet ik gaan bijhouden welke gestart is en hoe weet ik dan alsnog dat mijn programma dat was en niet de gebruiker die daarna nog een keer het ERP heeft gestart?

Overige:
Ergens lijkt het er overigens op dat Logout() niet goed is geïmplementeerd in de COM, helaas kan ik daar niets aan wijzigen. Het probleem is doorgegeven bij de leverancier van de software en deze gaat hier naar kijken, maar ik heb geen idee hoe lang dit gaat duren en of het juist opgelost gaat worden.

Acties:
  • 0 Henk 'm!

  • R4gnax
  • Registratie: Maart 2009
  • Laatst online: 06-09 17:51
COM interop componenten in .NET hebben een speciale manier om afgesloten en gedeactiveerd te worden.
Gewoon een reference op null zetten wil zeggen dat je moet wachten op de garbage collector om Dispose aan te roepen. Roep zelf Dispose eens aan vóór je de reference weg gooit. Als de fabrikant een degelijke .NET wrapper meegeleverd heeft, zou de Dispose aanroep onder de kap alles voor je moeten regelen.

Heb je geen, of geen degelijke .NET wrapper om je COM object heen, dan zul je een met de hand gecreeërd COM object moeten gebruiken en dat wanneer je er mee klaar bent, weer vrij moeten geven met System.Runtime.InteropServices.Marshal.ReleaseComObject.

Acties:
  • 0 Henk 'm!

  • Crazybyte
  • Registratie: Juli 2002
  • Laatst online: 15-09 10:07
R4gnax schreef op vrijdag 11 september 2009 @ 12:06:
Heb je geen, of geen degelijke .NET wrapper om je COM object heen, dan zul je een met de hand gecreeërd COM object moeten gebruiken en dat wanneer je er mee klaar bent, weer vrij moeten geven met System.Runtime.InteropServices.Marshal.ReleaseComObject.
Het COM object heeft inderdaad geen Dispose of iets wat daar op lijkt. Het zelf vrijgeven met de genoemde functie werkt wel, al leek dat in het begin niet zo te zijn.

Ik had namelijk een kleine test gemaakt met een DataGridView en een "Load" en "Kill" button. Als ik die start is er één proces actief, dat klopt want ik ben al ingelogd in het ERP. Dan klik ik op de Load-button, hij maakt dan het object aan en refreshed de DataGridView en komt er één proces bij, maar als ik op de Kill-button klik (ReleaseComObject, gevolgd door variabele = null, en dan een refresh) verdwijnt dat proces niet, athans zo lijkt, want in Windows Taakbeheer is te zien dat het proces sluit. Echter een System.Threading.Thread.Sleep van 200 tussen het nullen van de variabele en het opnieuw opvragen van de processen deed het hem, heb hem overigens voor de zekerheid op 500 gezet.

Overigens heb ik nog even wat verder geprobeerd en de variabele op null zetten werkt ook wel, alleen hij is dan ergens op aan 't wachten. Zolang de GUI niet geupdate is, blijft het proces actief. Als hij de GUI vernieuwd heeft zie je het proces ineens verdwijnen in het Windows Taakbeheer, maar dan laat de DataGridView wel nog 2 processen zijn, want die was al klaar natuurlijk. Een langere Sleep had hier geen effect op.

Dat vind ik dan nog wel een beetje vreemd, maar ik kan hier verder eigenlijk prima mee vooruit.

Ik ga wel eens nog wat meer informatie zoeken over COM interop componenten in .NET, want ik verwacht eerlijk gezegd nog wel meer aparte dingen tegen te gaan komen, helaas.

Acties:
  • 0 Henk 'm!

  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
Ik ruik Accountview :X
offtopic:
Als dat zo is kan ik je maar 1 tip geven: maken dat je weg komt. Die "COM interop" is meer een "COM internot" en bevat zoveel nukken en haken en ogen dat het één dieptrieste ellende is om fatsoenlijk mee te kunnen werken. Nu is het nog maar het login gebeuren maar reken er maar op dat je voor ieder akkefietje en knullig ietsje weer 4 dagen kunt gaan puzzelen waarom dat nou weer niet werkt :X Vervolgens bouw je workaround op workaround op workaround en eindig je met een stinkende brei en puinhoop aan code om die gammele zooi draaiend te houden/krijgen. Melden van problemen geeft steevast een "we kijken er naar" en "oh, dat hebben we nou nog noooooooit gehoord meneer" en vervolgens hoor je er nooit meer iets van. Hopen op een fix is ijdele hoop.

* RobIII heeft heel wat afgerant op dat k*tproduct ;)

[ Voor 61% gewijzigd door RobIII op 12-09-2009 13:15 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


Acties:
  • 0 Henk 'm!

  • Crazybyte
  • Registratie: Juli 2002
  • Laatst online: 15-09 10:07
Dan laat je neus je in de steek ;)

Er wordt hier gebruik gemaakt van Ridder R8 en ik heb best wel goede ervaringen met hun support. Wat niet wil zeggen dat het pakket helemaal top is, maar volgens mij heeft elk ERP wel zo z'n nukken.