[ASP.NET]Exception met xml/xslt

[Woy]

Ik heb een asp.net application. In een van de pagina's heb ik een XML control staan die ik dynamisch van zijn XmlDocument voorzie. Daarnaast heb ik een xslt file op de server staan die de xml transformeert naar html. Dit werkt op zich allemaal goed op de ontwikkel server en ook op de test server.

Op de live server krijg ik echter de volgende HttpException

Access denied to 'D:\Inetpub\wwwroot\kennistest\resultaat.xslt'. Failed to start monitoring file changes.

Uit de stack trace valt op te maken dat het gebeurt in het caching mechanisme wat blijkbaar een monitor op de file wil plaatsen om te detecteren of de file gewijzigd wordt. We hebben al van alles geprobeerd met de rechten instellingen op deze file. We hebben zelfs de ASPNET user en de IUSER full control gegeven op deze file. De foutmelding wordt echter niet verholpen. De live server draait op bijna dezelfde configuratie als de test machine. We hebben dan ook niet kunnen vinden wat het verschil tussen de instellingen is waardoor het wel op de test server werkt en niet op de live.

in de aspx file staat de xml als volgt gedefineerd

ASP.NET:

<asp:Xml id="Resultaat" runat="server" TransformSource="./resultaat.xslt"></asp:Xml>

Als ik op de live server de aspx zo aanpas dat de TransformSource property niet bestaat krijg ik gewoon netjes zoals je zou verwachten de XML in mijn pagina. Het probleem zit dus echt in de rechten op de xslt file

Is er iemand die dit probleem eerder heeft gehad of een oplossing weet?

[whoami]

Staat die xslt file op een andere server dan de webserver?

Het ASP.NET worker process kan geen files accessen op remote machines. Zelfs al geef je expliciet toegang aan de aspnet account op die remote file, dan nog zal je een access denied error krijgen.

Er zijn verschillende oplossingen voor dit probleem:

Several solutions exist. One is to configure ASP.NET to use a domain account that can be authenticated on the database server. That change is easy enough to accomplish: you simply specify the account's user name and password in the section of each Web server's Machine.config. Many companies, however, have security policies that prevent passwords from being stored in plaintext configuration files. If that's true of your company, but you'd still like to run ASP.NET using a domain account, you can either upgrade to version 1.1 of the .NET Framework (which allows worker process credentials to be encrypted and stored securely in the registry) or download a hotfix for version 1.0 that does the same. You'll find information about the hotfix at http://support.microsoft.com/?kbid=329250

[ Voor 91% gewijzigd door whoami op 18-06-2003 10:58 ]

[Woy]

Nee hij staat in dezelfde directory als de application zelf

ASP.NET:

TransformSource="./resultaat.xslt"

in de error staat ook dat deze ( 'D:\Inetpub\wwwroot\kennistest\resultaat.xslt' ) file geopend wordt en dat is inderdaad de file die ik wil hebben.

de locatie van de de aspx is D:\Inetpub\wwwroot\kennistest\resultaat.aspx dus in dezelfde directory

[ Voor 20% gewijzigd door Woy op 18-06-2003 11:02 ]

[Ramon]

als het dezelfde directory is dan hoeft er toch geen ./ voor?

probeer anders D:\Inetpub\wwwroot\kennistest\resultaat.xslt op te geven?

[ Voor 3% gewijzigd door Ramon op 18-06-2003 11:21 ]

[gorgi_19]

Zie ook: http://support.microsoft.com/default.aspx?kbid=317955

En heb je ook de access gegeven op de folder? Schijnt een bug in versie 1.0 te zijn.

[Woy]

Tampie schreef op 18 June 2003 @ 11:21:
als het dezelfde directory is dan hoeft er toch geen ./ voor?

probeer anders D:\Inetpub\wwwroot\kennistest\resultaat.xslt op te geven?

Nee dat hoeft inderdaad niet. Maar ./ staat ook voor current directory dus dat haalt niet uit. Maar ook met het complete pad opgegeven werkt het niet. Het probleem is ook niet dat hij de file niet kan vinden want dan krijg je een andere foutmelding. In de foutmelding kan je ook zien dat hij de goede file probeert te openen.

[Woy]

gorgi_19 schreef op 18 June 2003 @ 11:26:
Zie ook: http://support.microsoft.com/default.aspx?kbid=317955

En heb je ook de access gegeven op de folder? Schijnt een bug in versie 1.0 te zijn.

Deze lijkt er inderdaad wel op. Ik zal hier zo eens wat mee gaan proberen

[Woy]

Het probleem is ondertussen opgelost. Het lijkt inderdaad dit probleem geweest te zijn. De quick fixes die op de site stonden werkten echter niet ( Mischien niet helemaal goed gedaan ofzo? ). Maar door het 1.1 framework te instaleren werkte alles wel.