Vroeger was het gebruikelijk om bij het debuggen van een website direct met de rechtermuisknop in de oplossing te klikken - een nieuwe instantie te starten, maar later ontdekte men dat zulke nadelen waren:
1. De start is relatief traag;
2. De verzoekparameter van sommige browsers kan niet worden geïmporteerd;
3. Als je de opstart-URL niet specificeert, laadt VS de pagina naar localhost, zoals http://localhost/test.aspx;
In dit geval kunnen cookies die via domeinnamen worden gedeeld niet worden gedeeld.
Aan de harde kant besloot ik IIS-pagina's te debuggen door een proces aan VS toe te voegen.
De stappen zijn als volgt:
1. Maak een site aan in IIS en wijs direct naar de map waar het programma zich bevindt (of het pad verwijst naar de map waar het programma is gepubliceerd);
2. Stel een breakpoint in op de te testen pagina, kies dan "Debug" > "Hecht aan proces" en selecteer w3wp.exe proces in het proces (je moet eerst het CRM of de te testen pagina openen); Als je w3wp.exe proces niet kunt vinden, staat er onderaan de proceslijst een 'procesprocessen weergeven' in alle sessies, en je kunt het zien
3. Maar ik merkte dat ik het breakpoint niet kon invoeren, en het raadplegen van ieders instructies, of de generatiemethode debug was, enzovoort, loste mijn probleem niet op.
Uiteindelijk ontdekte ik dat het de property page debugger van het webproject was - de native code was niet gecontroleerd, en de pagina kan succesvol worden gedebugged, dus ik ben blij!
4. Daarnaast is het het beste om de bewerking van bovenstaande afbeelding te activeren en deze te blijven aanvinken, anders kan het als foutmelding worden gerapporteerd en kan deze niet worden geopend
|
Geplaatst op 18-08-2016 14:50:23
|
|
|
|
Huisbaas|
Geplaatst op 02-03-2021 09:59:42
|
