Check alle échte Black Friday-deals Ook zo moe van nepaanbiedingen? Wij laten alleen échte deals zien

[VS2010] debuggen van een website via ftp

Pagina: 1
Acties:

  • Stefke
  • Registratie: December 2000
  • Laatst online: 10:31
Ik heb, als beginnend C#.net-er, een simpele website op mijn ASP-host gezet. Deze website functioneert, daar geen problemen.

http://www.dblogic.nl/test2/

Ik bewerk het project rechtstreeks via FTP

C#:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
Web.config
<configuration>
    <system.web>
        <compilation debug="true" targetFramework="4.0" urlLinePragmas="true"/>
    </system.web>
</configuration>


default.aspx
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title></title>
</head>
<body>
    <form id="form1" runat="server">
    <div>
        <asp:Label ID="Label1" runat="server" Text="Label"></asp:Label>
    </div>
    </form>
</body>
</html>


default.aspx.cs
    protected void Page_Load(object sender, EventArgs e)
    {
        Label1.Text = "Hallo Wereld! :) ";
    }


Nu wil ik graag de boel debuggen terwijl ik over FTP het project bewerk (ik heb een ander projectje waar ik mee bezig ben dat ik niet kan debuggen), dus vandaar deze "testsetup".

De eerste keer dat ik mijn "projectje" ging debuggen kreeg ik de melding: debuggen moet aan staan in de webconfig. Ik heb dit bevestigd, met als resultaat bovenstaande web.config.
De volgende melding die je krijgt is de vraag of je een URL op wil geven. Nu weet ik niet precies meer wat de vraag is (ik krijg hem één keer, daarna niet meer), maar ik zit al een paar uur allerlei zaken na te zoeken op o.a. MSDN (bijv. MSDN: Testing Web Pages in Visual Studio)
For FTP-deployed websites, Visual Studio runs the page by using the start URL that you provide as part of the FTP website properties. If you have not provided one, Visual Studio prompts you for the start URL when it is required. For more information, see FTP-Deployed Web Site Projects.
.
MSDN: FTP-Deployed Web Site Projects

Wat ik begrepen heb is dat je aan de debugger vertelt waar hij de website kan vinden, aangezien deze niet via FTP kan werken.
Dus heb ik deze link opgegeven: http://www.dblogic.nl/test2/

Deze zie ik vervolgens terug onder Website > Start Options > Use Custom Server - Base URL: ....

Desondanks werkt het niet en krijg ik een melding:
Unable to start debugging on the web server. The debugger cannot connect to the remote computer. This may be ...blabla firewall
De helpdesk van mijn ASP-hosting zegt dat het in de web.config moet zitten maar ze kunnen/willen niet aangeven wat er nog meer in de web.config moet staan.
Van alle pagina's die ik heb gelezen was er geen enkele waar precies stond waar ik wat moet invullen: elke keer waren het net andere menu's die ik niet kon vinden, opties die ik niet had etc.

Iemand die me opweg kan helpen?

[ Voor 12% gewijzigd door Stefke op 16-11-2012 15:20 ]


  • Haan
  • Registratie: Februari 2004
  • Laatst online: 10:27

Haan

dotnetter

Maar je kan dus niet gewoon lokaal debuggen, of hoe moet ik het precies zien? Voor remote debugging heb je normaal gesproken een remote debugging service nodig die op de remote server moet draaien.
Ik weet alleen niet of dat in jouw geval via FTP ook zo is, geen ervaring mee.

Kater? Eerst water, de rest komt later


  • Stefke
  • Registratie: December 2000
  • Laatst online: 10:31
Lokaal debuggen werkt wel. Ik werkte eerst ook lokaal, maar toen kreeg ik allerlei problemen bij het publishen van mijn projectje. De ASP-host gaf toen de tip om via ftp te werken en daar de site op te bouwen, want dan werk je in de "productie"-omgeving.
Allemaal goed en wel, want mijn eigenlijke website werkt ook nu (online), alleen kan ik tijdens het programmeren niet debuggen. En dat is gezien mijn skills :| wel nodig ...

(Natuurlijk kan ik weer lokaal gaan werken, maar vermoedelijk krijg ik dan straks weer opnieuw problemen met publishen. Dit leek me wel een prettige methode, werken via FTP)

[ Voor 91% gewijzigd door Stefke op 16-11-2012 15:26 ]


  • CodeCaster
  • Registratie: Juni 2003
  • Niet online

CodeCaster

Can I get uhm...

Haan schreef op vrijdag 16 november 2012 @ 15:20:
Maar je kan dus niet gewoon lokaal debuggen, of hoe moet ik het precies zien? Voor remote debugging heb je normaal gesproken een remote debugging service nodig die op de remote server moet draaien.
Ik weet alleen niet of dat in jouw geval via FTP ook zo is, geen ervaring mee.
Precies:
For more information, see the "Remote Computer Configuration" section in Debugging Web Pages Overview.
Het enige verschil met FTP debugging is dat Visual Studio de codebestanden van de FTP-server kan halen als je lokaal niet over de code beschikt. Je kunt dus niet automagisch remote debuggen over FTP, omdat het FTP-protocol geen symbols en andere debug-informatie heen en weer kan sturen.

Je moet op de webserver dus de Remote Debugging Monitor draaien om op afstand te kunnen debuggen.

Remote debugging is iets voor uitzonderlijke gevallen; zorg dus gewoon dat je code lokaal én op de server werkt. Als je dan een bug vindt in de liveomgeving, is deze waarschijnlijk afhankelijk van data; als je dan je database lokaal haalt kun je lokaal debuggen. Wel zo makkelijk en een stuk sneller en flexibeler.

[ Voor 12% gewijzigd door CodeCaster op 16-11-2012 15:28 ]

https://oneerlijkewoz.nl
Op papier is hij aan het tekenen, maar in de praktijk...


  • Alex)
  • Registratie: Juni 2003
  • Laatst online: 18-11 20:57
stefijn schreef op vrijdag 16 november 2012 @ 15:21:
Lokaal debuggen werkt wel. Ik werkte eerst ook lokaal, maar toen kreeg ik allerlei problemen bij het publishen van mijn projectje. De ASP-host gaf toen de tip om via ftp te werken en daar de site op te bouwen, want dan werk je in de "productie"-omgeving.
Dat is een slecht advies :X

Wat aan te bevelen is, is om lokaal te ontwikkelen en te zorgen dat je daarbij zoveel mogelijk overeenkomsten hebt met de productie-omgeving. Denk hierbij bijvoorbeeld aan dezelfde .NET Framework-versie gebruiken, dezelfde database-engine, enzovoorts. Wanneer je klaar bent publish je je project naar productie.

Als dit niet lukt (kan gebeuren) is het zaak om te achterhalen waarom het niet lukt. Ontbreken er dependencies (zoals een library die jij lokaal hebt geïnstalleerd in de GAC), heb je ergens een hardcoded pad staan, enzovoorts.

We are shaping the future


  • xzaz
  • Registratie: Augustus 2005
  • Laatst online: 10:50
Is het systeem lokaal (dev) -> dev.mijndomein.nl (acceptatie) -> mijndomein.nl (productie) geen idee? Dan moet je acceptatie een 1 op 1 zijn van je productie waarbij je dev snel kan overzetten naar acceptatie. Een soort halve OTAP dus. Heb je dit gelijk netjes staan.

Schiet tussen de palen en je scoort!


  • Stefke
  • Registratie: December 2000
  • Laatst online: 10:31
Nou, ik ben maar aan t amateuren hoor (voorlopig iig ;) ), een bouw en live omgeving vind ik voorlopig voldoende :) bedankt voor het advies

Oke, duidelijk. Ik heb nog even nagevraagd bij de webhost of ze kunnen aangeven of het bij hun "aan" staat. Maar wellicht toch maar offline werken en zorgen dat het online ook werkt...

Een van de problemen was bijv. dat als ik met VS een standaard website maak (met Masterpage etc) dat in de pagina's gelinked wordt naar "~/Masterpage.aspx", en dat werkt lokaal wel, maar online niet. Dat is natuurlijk maar iets kleins, maar als ik meer van dat soort zaken ga tegenkomen wordt het een lastig verhaal.
Ik heb .NET 4.0, de website ook.

Het verwonderde me nogal dat een default "template" van VS gebruik maakt van ~/ verwijzingen terwijl dit vervolgens op de ASP-webhost niet werkt..

[ Voor 28% gewijzigd door Stefke op 16-11-2012 15:50 ]


  • Cloud
  • Registratie: November 2001
  • Laatst online: 03-11 10:25

Cloud

FP ProMod

Ex-moderatie mobster

Die ~/ zou in principe ook gewoon remote moeten werken, maar dat hangt vooral af van hoe jouw hoster IIS geconfigureerd heeft. ~/ resolved altijd naar de root van de gehele applicatie. Je applicatie zal in zijn eigen application moeten zitten om dat te laten werken, waarbij jouw .aspx pagina's dus in de root terechtkomen.

Maar als je hoster een enkele application aangemaakt heeft en jij zit in een subdirectory te werken daarvan (bijv. /test/), dan gaat ~/Masterpage.aspx falen inderdaad. Je moet dan eigenlijk ~/test/Masterpage.aspx hebben.

Je kunt twee dingen doen denk ik:
  1. Hoster IIS aan laten passen en van jouw directory een losse application maken. Maar dat kan soms niet mogelijk zijn of soms wil een hoster dat gewoon niet doen.
  2. Dezelfde mappenstructuur lokaal nabouwen
Hoe dan ook gaat remote debugging een lastige taak worden, je moet gewoon lokaal werken en zorgen dat je eventuele verschillen bij lokaal -> productie zo glad als mogelijk strijkt :)

Never attribute to malice that which can be adequately explained by stupidity. - Robert J. Hanlon
60% of the time, it works all the time. - Brian Fantana


  • Stefke
  • Registratie: December 2000
  • Laatst online: 10:31
Ga ik even uitzoeken, volgens mij kan ik zelf iets instellen m.b.t. tot dat met die directories.


edit: @cloud, achteraf inderdaad logisch :F Gewoon een gebrek aan ervaring

[ Voor 29% gewijzigd door Stefke op 16-11-2012 16:09 ]


  • edeboeck
  • Registratie: Maart 2005
  • Laatst online: 20-11 12:23

edeboeck

mie noow noooothing ...

stefijn schreef op vrijdag 16 november 2012 @ 15:51:
Ga ik even uitzoeken, volgens mij kan ik zelf iets instellen m.b.t. tot dat met die directories.
Als ik me niet vergis, kan je dan instellen dat die test-directory een Virtual Directory is.

  • Stefke
  • Registratie: December 2000
  • Laatst online: 10:31
Bedankt, ik ga er even naar kijken

O ja... een andere voor mij niet onbelanrijke reden waarom ik dat online werken wel prettig vond lijken is omdat ik "lokaal" een andere connectiestring (IP-adres + poort) moet gebruiken naar de MySQL-server van mijn host dan online (een normaal adres "mysql4.webhost.nl")
Dan moet ik dus telkens in de webconfig veranderen van connectiestring.

Of ik upload alleen de gewijzigde files en niet de web.config, alleen...met publishen gaat toch de hele website mee? Of kun je beter handmatig via FTP uploaden dan. Lijkt me toch dat VS hier wel iets voor bedacht heeft?

[ Voor 8% gewijzigd door Stefke op 16-11-2012 16:04 ]


  • Haan
  • Registratie: Februari 2004
  • Laatst online: 10:27

Haan

dotnetter

stefijn schreef op vrijdag 16 november 2012 @ 16:03:
Bedankt, ik ga er even naar kijken

O ja... een andere voor mij niet onbelanrijke reden waarom ik dat online werken wel prettig vond lijken is omdat ik "lokaal" een andere connectiestring (IP-adres + poort) moet gebruiken naar de MySQL-server van mijn host dan online (een normaal adres "mysql4.webhost.nl")
Dan moet ik dus telkens in de webconfig veranderen van connectiestring.

Of ik upload alleen de gewijzigde files en niet de web.config, alleen...met publishen gaat toch de hele website mee? Of kun je beter handmatig via FTP uploaden dan. Lijkt me toch dat VS hier wel iets voor bedacht heeft?
Als het goed is, heeft je project een web.config, en een web.config.debug en een web.config.release. Daarmee los je precies dat probleem op ;) In een release build komt dan netjes de juiste configuratie te staan voor de productieomgeving, mits je dat uiteraard eerst goed hebt ingesteld, maar dat is niet zo heel lastig op te zoeken.

Kater? Eerst water, de rest komt later


  • Stefke
  • Registratie: December 2000
  • Laatst online: 10:31
Nou, dat heeft ie dus niet... Heb veel geld uitgegeven aan een cursus C# (met ASP) maar dat soort praktijkdingen kwam daar helaas niet aan bod. Weer wat geleerd (d.w.z. even noteren en later uitzoeken)


edit: ~/ punt opgelost met het aanmaken van een virt-dir "test". Daarvoor moest ik ook de mySQL-connector.dll verplaatsen (stond in de wwwroot, maar moet nu ook in test staan). :) :) Nu kan ik inderdaad wel ~/ gebruiken (en daarvoor moest het inderdaad ~/test/Sitemaster zijn! )

edit2: het gaat nu allemaal een stuk beter. Zonder problemen een nieuwe webapplication (template) compleet geupload en werkend! Bedankt voor de tips :)

[ Voor 54% gewijzigd door Stefke op 16-11-2012 16:37 ]


  • Stefke
  • Registratie: December 2000
  • Laatst online: 10:31
Pff...wat een gedoe zeg dat VS :)

Ben weer "opnieuw" begonnen met een Webapplication (ik had eerst een "website") omdat ik zag dat daar in automatisch al een debug en release.configs opgenomen zijn (met het juiste mechanisme). Heb de pagina's van mijn projectje (niet de bovenstaande test dus) overgenomen, van alles bijgewerkt, maar uiteindelijk heb ik het werkend gekregen :) en kan ik dus nu lokaal ontwikkelen en debuggen met de "externe" connectiestring en publishen met de "interne" :) tnx mannen :D
D.w.z. debuggen gebruikt de normale web.config (debug.config wijzigt niets) en de release.config wijzigt de connectiestring.

edit: o sorry, had moeten editten 8)7

[ Voor 14% gewijzigd door Stefke op 16-11-2012 18:06 ]


  • CodeCaster
  • Registratie: Juni 2003
  • Niet online

CodeCaster

Can I get uhm...

stefijn schreef op vrijdag 16 november 2012 @ 16:11:
Heb veel geld uitgegeven aan een cursus C# (met ASP) maar dat soort praktijkdingen kwam daar helaas niet aan bod.
Het is natuurlijk ook lastig om álle aspecten van applicatie-ontwerp tot en met deployment te bespreken, maar toch mooi dat het nu is gelukt. :)

https://oneerlijkewoz.nl
Op papier is hij aan het tekenen, maar in de praktijk...


  • Stefke
  • Registratie: December 2000
  • Laatst online: 10:31
Nee, dat is logisch, alleen merk je dan wel dat je eigenlijk nog niks kunt

Wel even een vraagje: stel de website werkt niet meer. Ik kan nu dus niet remote debuggen, maar het probleem kan best wel komen door de webspace en niet voorkomen als ik de boel lokaal test. Heb nu bijv. even getest door de mysql.dll die ik in de bin heb gezet te verwijderen, nu krijg ik een fout. De fout is echter niet zichtbaar omdat de release.config de <customErrors mode="Off"/> verwijderd.

Hoe gaat dat in de (simpele) praktijk. Vervang je dan de webconfig even door één met <customErrors mode="Off"/>?

Natuurlijk, uiteindelijk zal er wel een mooie afhandeling voor zijn, maar zover ben ik nog niet.

[ Voor 80% gewijzigd door Stefke op 16-11-2012 18:50 ]


  • Alex)
  • Registratie: Juni 2003
  • Laatst online: 18-11 20:57
Foutmeldingen moet je niet tonen, maar wel loggen. Hiervoor zijn tools en libraries beschikbaar zoals ELMAH.

We are shaping the future


  • CodeCaster
  • Registratie: Juni 2003
  • Niet online

CodeCaster

Can I get uhm...

Wat Alex) zegt. Ook log4net kun je gebruiken, maar dan zul je zelf vanuit je applicatie moeten loggen. Dat gaat niet als de hele applicatie niet werkt, zoals in het geval van een missende DLL.

Vooral wanneer fouten niet bij jou, maar bijvoorbeeld wel bij andere bezoekers optreden is logging onmisbaar.

https://oneerlijkewoz.nl
Op papier is hij aan het tekenen, maar in de praktijk...


  • Alex)
  • Registratie: Juni 2003
  • Laatst online: 18-11 20:57
Wat handig kan zijn is om packages te installeren via NuGet, dan wordt installatie (van bijvoorbeeld ELMAH) meteen geregeld. Ook bijwerken is makkelijk :)

We are shaping the future


  • Cloud
  • Registratie: November 2001
  • Laatst online: 03-11 10:25

Cloud

FP ProMod

Ex-moderatie mobster

ELMAH is echt een aanrader overigens :) Helaas pas recent aan toegekomen om te gaan gebruiken in onze productieapplicaties, maar werkt ideaal. Zeker als je het over een medium-trust omgeving hebt als een webhoster (dus zonder volledige RDP toegang).

Never attribute to malice that which can be adequately explained by stupidity. - Robert J. Hanlon
60% of the time, it works all the time. - Brian Fantana


  • Tarilo
  • Registratie: December 2007
  • Laatst online: 12:03
Als een laatste tip zou ik je ook aanraden je SQL server lokaal na te bootsen. Het is namelijk niet echt aan te raden om met test code in een productie-database te werken. Je zou zomaar eens data kunnen weggooien terwijl dat niet de bedoeling was.

Misschien is het nu niet direct noodzakelijk, maar het is toch fijn om dat deel ook alvast goed geregeld te hebben.

  • Stefke
  • Registratie: December 2000
  • Laatst online: 10:31
Dat had ik al geregeld (ik heb een eigen mySQL-server draaien op mijn NAS), en met de debug.config en release.config schakelt ie al automatisch tussen mijn eigen server en die van de webhost! :D Het is zoveel tegelijk, om alleen maar een simpele website online te krijgen. Maar deze tip was ik voor :) desodanks bedankt!
Zie hier het resultaat van weer een paar dagen zwoegen (let niet op de teksten, dat is allemaal "under construction") www.dblogic.nl/test
(de .NET-versie van mijn nog erg kale html/css-site op dblogic.nl). De projecten komen uit de database

:) moet uiteindelijk een soort van CMS worden met allerlei mogelijkheden, gewoon als oefenproject

[ Voor 14% gewijzigd door Stefke op 17-11-2012 00:09 ]

Pagina: 1