Toon posts:

[ASP.NET] Lastig 'scenario' voor Remote Debugging

Pagina: 1
Acties:

Verwijderd

Topicstarter
Ik heb de volgende situatie:

Win XP SP2 met VS.Net 2003 (werkstation)
Win Server 2003 IIS 6 (webserver)
Win Server 2003 (fileserver)

Op de webserver staat een website, als ik de document root hiervan op de webserver heb staan, dan werkt remote debugging vanaf mijn werkstation. Als ik de documentroot laat verwijzen naar de fileserver (met een UNC pad) dan krijg ik de foutmelding Access Denied.

Heeft iemand ervaring met dit scenario? Is het mogelijk om dan te debuggen?

Ik heb iig de volgende zaken al geregeld:

Op de webserver heeft managed code die geindentificeerd wordt door een url \\fileserver\websites\* Full Trust.
Mijn Windows XP firewall is met een tooltje van Microsoft geconfigureerd voor VS Remote debugging.
De applicatie werkt als je start zonder debug (Het is alleen één pagina met een button en een label).

  • giMoz
  • Registratie: Augustus 2002
  • Laatst online: 02-04 08:55

giMoz

iets met meester...

Je wil idd een lastig scenario..

voor elk probleem zijn er altijd 2 oplossingen:
Zorgen dat het werk, of zorgen dat je het niet nodig hebt.

De laatste lijkt me in dit geval stukken makkelijker.
wat voor functie heeft die webserver eigenlijk als je daar je files niet op host en je werkt er niet op??

Voor later werkend krijgen kan je altijd nog je bestanden verplaatsen. Maar voor nu ontwikkelen en debuggen kan het toch wel op de webserver (of nog makkelijker op je local machine)

Of niet natuurlijk...


Verwijderd

Topicstarter
Je slaat de spijker op z'n kop. De achterliggende gedachte is, dat websites ondergebracht kunnen worden op de fileserver. Daar worden namelijk ook alle bestanden van andere projecten opgeslagen, ik werk bij een reclamebureau, wij maken ook drukwerk en audio/video, sommige projecten omvatten zowel drukwerk als een website bijvoorbeeld. Dan is het handig om alles bij elkaar te hebben.

Dat is de reden dat ik toch zoek naar een oplossing. Als het niet lukt dan ga ik uiteraard met de huidige oplossing (bestanden op de webserver). Lokaal (op werkstation) is in ieder geval geen oplossing, omdat we regelmatig zullen werken met 2 tot 3 man aan een website.

  • TeeDee
  • Registratie: Februari 2001
  • Laatst online: 17-04 11:22

TeeDee

CQB 241

Verwijderd schreef op donderdag 22 december 2005 @ 09:39:
Lokaal (op werkstation) is in ieder geval geen oplossing, omdat we regelmatig zullen werken met 2 tot 3 man aan een website.
Microsoft Visual Sourcesafe, Visual Studio TeamSystem (alleen van VS.NET 2005) etc. etc. Er zijn legio tools die hierin voorzien.

Heart..pumps blood.Has nothing to do with emotion! Bored


  • Annie
  • Registratie: Juni 1999
  • Laatst online: 25-11-2021

Annie

amateur megalomaan

Even ingaand op je melding: is dit niet een delegation probleem (double hop)? Of hoor ik nu een klok luiden en heb ik weer eens de klepel volledig gemist? Misschien dat je eens een Windows administrator naar het (rechten)probleem kan laten kijken.

Los daarvan. Begrijp ik je nu goed als ik zeg dat de bestanden voor de site (incl bijv code-behind) op een fileserver staan en dat daar de ontwikkeling op wordt uitgevoerd? En dat bovendien de documentroot op die dir staat?

Als dat zo is: bad developer, bá-á-ád developer! ;)

Ontwikkel gewoon lokaal en gebruik een versiebeheersysteem (er zijn ook gratis alternatieven, je hoeft je niet direct krom te betalen aan VSS). En migreer releasebuilds (excl de cs files) naar de webserver (evt met een test/acceptatieserver als tussenstation).

Today's subliminal thought is:


Verwijderd

Topicstarter
Annie schreef op donderdag 22 december 2005 @ 10:48:Als dat zo is: bad developer, bá-á-ád developer! ;)

Ontwikkel gewoon lokaal en gebruik een versiebeheersysteem (er zijn ook gratis alternatieven, je hoeft je niet direct krom te betalen aan VSS). En migreer releasebuilds (excl de cs files) naar de webserver (evt met een test/acceptatieserver als tussenstation).
Zo erg? Hmm, we zijn maar met 3 man, en we beginnen nog maar net met .NET :?, dus VSS of TeamSystem zit er voorlopig nog niet in. Maar zou je het nog wat nader toe kunnen lichten waarom mijn idee zo slecht was? Ik d8 juist dat het wel makkelijk zou zijn, kunnen we alles op één plek houden.

Ik zal kijken of we SVN of iets dergelijks kunnen gaan gebruiken. Dat lokaal ontwikkelen, ja dat weet ik nog niet. Dan hoor ik heel graag de voors (en tegens).
Pagina: 1