[IIS 6.0, ASP.NET, WIN2003] app werkt niet met externe dll

[jobo]

Hallo,

Ik heb een applicatie ontwikkeld in Microsoft Visual Studio 2003. Hierbij maak ik gebruik van een API om verbinding te maken met een global360 server (Imaging en Workflow applicatie). Deze applicatie is ontwikkeld op een Windows XP machine waarop ook IIS draait. Daar werkt de applicatie naar behoren. Nu zit ik bij de klant om de applicatie live te brengen op een windows 2003 server met IIS 6.0.

Ik heb een nieuwe website aangemaakt in IIS en de pagina verschijnt netjes zoals deze behoort te doen. De eerste pagina is een login scherm waarmee een connectie gemaakt wordt met global360. echter op het moment dat de verbinding tot stand gebracht moet worden met global360 verschijnt het login scherm opnieuw. het lijkt erop dat de geinstalleerde api niet gevonden kan worden. alle instellingen zijn exact hetzelfde als op de windows xp machine, alleen de ontwikkel omgeving is niet beschikbaar. Binnen de applicatie zijn alle benodigde dll's beschikbaar en ook alle paden naar naar mogelijke gebruikte dll's kloppen met de exacte locatie op het windows 2003 systeem.

Ik weet echt niet meer wat ik nog kan proberen om dit probleem te verhelpen. Ben nu al twee dagen bezig om de applicatie aan het werk te krijgen. Heeft iemand van jullie misschien een zelfde soort situatie gehad? hoe hebben jullie dit opgelost? heeft iemand nog suggesties voor een mogelijke oplossing? schiet maar raak!

Ik hoor het wel

Groeten Joel

[_js_]

Kijk in de eventlog wat voor fouten gegenereerd worden.
Kijk in de iis logs of daar iets interessants staat.
Controleer of de rechten op je bestanden goed zijn.
Controleer of web service extensions in iis goed staat ingesteld.
Controleer eventueel met een programma als filemon welk bestand benaderd wordt.

[TeeDee]

Ik 'vergeet' ook altijd de rechten correct te zetten. Ook na een update.

Verder ga ik gewoon mee met de tips/hints van _js_.

RiCkY82 schreef op dinsdag 20 juni 2006 @ 15:22:
Ik meen mij ook iets te herinneren dat je de .dll moet registeren vanuit de .NET dir

In de GAC zetten bedoel je?

[ Voor 49% gewijzigd door TeeDee op 20-06-2006 15:26 ]

[RiCkY82]

Ik meen mij ook iets te herinneren dat je de .dll moet registeren vanuit de .NET dir

[jobo]

De rechten heb ik gecontrolleerd. Ik heb zelf everyone read/write gegeven. dan zou iedereen er toch altijd meer moeten kunnen werken. De applicatie werkt ook wel, maar de desbetreffende dll kan op de een of andere manier niet gebruit worden.

Ook het registreren van de dll met gacutil /i heb ik gedaan. (dit stond ook zo beschreven in de installatie documentatie van de API)

Ik ga nu thuis op mijn eigen windows 2003 server IIS installeren. Daarna de API en de webapplicatie daarin installeren en dan eens kijken wat er gaat gebeuren.

Heeft er iemand nog ideeën? ondertussen voer ik de installatie uit...

[ Voor 22% gewijzigd door jobo op 20-06-2006 17:41 ]

[TheVMaster]

ehh...heb je de Network Service wel rechten gegeven op de dll? (volgens mij is dat ook noodzakelijk met een .net app).

[jobo]

Dit zegt me even niets. Is dat een soort van gebruiker die ik kan toevoegen?

[Not Pingu]

Het ASP.NET worker process draait onder Win2003 onder een andere user dan onder WinXP.

Onder XP draait ie als user ASPNET, onder Win2003 als de network service. Die gebruiker moet je dus toevoegen en rechten geven.

[jobo]

Not Pingu schreef op dinsdag 20 juni 2006 @ 17:46:
Het ASP.NET worker process draait onder Win2003 onder een andere user dan onder WinXP.

Onder XP draait ie als user ASPNET, onder Win2003 als de network service. Die gebruiker moet je dus toevoegen en rechten geven.

Wat ik nu heel vreemd vind, is dat ik onder windows 2003 de gebruiker ASPNET heb toe kunnen voegen aan de applicatiedirectory. dat zou betekenen dat je verhaal niet helemaal klopt. Ik weet niet precies hoe het in elkaar zit, maar vreemd vind ik het wel.

Ik zal in ieder geval even kijken of ik de user Network Service kan toevoegen. Inmiddels de IIS server geinstalleerd.

Ik houd jullie op de hoogte.

Nog meer ideeën???

[Vedett.]

Die API van de Global360 server, is dat ook een .Net dll?
[quote]
Ik meen mij ook iets te herinneren dat je de .dll moet registeren vanuit de .NET dir
[/qoute]
Je moet een .Net dll NIET registeren zolang je hem binnen een .Net toepassing gebruikt.
Wanneer je een VB6 toepassing schrijft en je wilt een .Net dll gebruiken moet je die wel registeren. Dit is zowat de enige reden.

De GAC is nog iets anders. Als je een dll in de GAC zet kunnen meerdere .Net programma's tegelijk gebruik maken van deze dll.

De dll is toch ook geen vb6 COM+ component, of een server activated .Net COM+ component? Anders moet je die uiteraard ook nog als COM+ component installeren op de server.

[Not Pingu]

jobo schreef op dinsdag 20 juni 2006 @ 17:52:
[...]


Wat ik nu heel vreemd vind, is dat ik onder windows 2003 de gebruiker ASPNET heb toe kunnen voegen aan de applicatiedirectory. dat zou betekenen dat je verhaal niet helemaal klopt. Ik weet niet precies hoe het in elkaar zit, maar vreemd vind ik het wel.

Dat die gebruikersaccount er is, kan alleen maar een voorzorg zijn. ASP.NET draait onder win2k3 mee in W3wp.exe (proces van IIS6) en dat draait geauthenticeerd als Network service.

[jobo]

Het is een speciaal voor .Net geschreven library met commando's aan de Global360 server. In de installatie handleiding stond hoe ik het desbetreffende dll bestand (CAL.dll) moest registreren met GACUtil /i en dat heb ik dus ook netjes gedaan.

Ik ga proberen de user Network Service toe te voegen. ben nu even bezig met de Vmware image van de global360 server te kopieren naar mijn eigen server.

[jobo]

Ik heb de oplossing gevonden!!!!

Het blijkt inderdaad aan de rechten op het FileSystem te liggen. Door de gebruiker Network Service toe te voegen bleek het probleem niet opgelost. Ik ben daarna wat verder gaan proberen. Gewoon om te testen, ben ik een Application Pool gaan maken. Daarin kon ik instellen wat voor een soort identity er gebruikt moet worden door de applicatie. Daar stelde ik network service in, maar dat gaf hetzelfde resultaat. daarna heb ik deze verandert in Local System. Er verschijnt vervolgens een melding dat hierdoor de applicatie full control rechten heeft op de server. Ik probeer mijn applicatie uit en tot mijn grote verbazing werkt het nu wel!!!. Ik bekijk enkele andere application pools (bijvoorbeeld die van Exchange) en daar staat dit ook op Local System. Het zal dus wel normaal zijn dat een applicatie full control rechten heeft op de server.

Ik ben nu in ieder geval weer uit de brand geholpen en ga het nu implementeren bij de klant!

bedankt voor jullie reacties!!

mvg Joël

[bigbeng]

Het is praktischer en veiliger om rechten op filesysteem niveau zo minimaal mogelijk te houden. Door een tool als Filemon (freeware) te gebruiken op de server kun je analyseren welke fileaccess er wordt gedaan door welke applicatie. Ook access denieds (veelal de reden waarom zaken niet goed gaan) kun je met deze tool zien. Op deze manier kun je dus veel praktischer rechten uitdelen, ipv je IIS of ASP.NET de volledige rechten te geven.

Filemon download je hier.