Korábban, amikor egy weboldalt hibáztattak, szokás volt közvetlenül a megoldásban jobb kattintással indítani – új példányt indítani, de később kiderült, hogy ezek a hátrányok a következők voltak:
1. A kezdés viszonylag lassú;
2. Egyes böngészők kérésparamétere nem importálható;
3. Ha nem megadod az indító URL-t, a VS betölti az oldalt a localhostba, például http://localhost/test.aspx;
Ebben az esetben a domainneveken keresztül megosztott sütik nem oszthatók meg.
A nehéz oldalon úgy döntöttem, hogy IIS oldalakat hibáztatok egy folyamattal a VS-ben.
A lépések a következők:
1. Létrehozz egy oldalt az IIS-ben, és közvetlenül a program mappára mutat (vagy az út arra a mappára mutat, ahol a program megjelent);
2. Állíts be egy megszakítási pontot a tesztelt oldalon, majd válaszd a "Debug" > "Csatolj a folyamathoz" opciót, majd w3wp.exe folyamatot válaszd ki a folyamatban (először meg kell nyitnod a CRM-et vagy a tesztelt oldalt); Ha nem találod w3wp.exe folyamatot, akkor minden alkalomban a folyamatlista alján van egy folyamatok megjelenítése, és láthatod
3. De azt tapasztaltam, hogy nem tudtam beírni a töréspontot, mindenki utasítására hivatkozva, hogy a generáló módszer hibakeresés volt-e és hasonló, nem oldotta meg a problémámat.
Végül rájöttem, hogy a webprojekt property page hibakeresője volt – a natív kód nem volt ellenőrizve, és az oldal sikeresen hibáztatható, nagyon örülök!
4. Emellett a legjobb ellenőrizni a fenti kép engedélyezési szerkesztését, és tovább pipálni azt, különben hibáként jelenthetik és nem lehet hozzáférni
|
Közzétéve 2016. 08. 18. 14:50:23
|
|
|
|
Háziúr|
Közzétéve 2021. 03. 02. 9:59:42
|
