Aiemmin, kun sivustoa debuggattiin, oli tapana klikata oikealla suoraan ratkaisussa – aloittaa uusi instanssi, mutta myöhemmin havaittiin, että tällaisia haittoja olivat:
1. Lähtö on suhteellisen hidas;
2. Joidenkin selainten pyyntöparametria ei voi tuoda;
3. Jos et määritä käynnistys-URL:ää, VS lataa sivun localhostiin, kuten http://localhost/test.aspx;
Tässä tapauksessa verkkotunnusten kautta jaettuja evästeitä ei voi jakaa.
Vaikeana puolena päätin debugata IIS-sivuja liittämällä prosessin VS:ään.
Vaiheet ovat seuraavat:
1. Luo sivusto IIS:ssä ja osoita suoraan kansioon, jossa ohjelma sijaitsee (tai polku osoittaa kansioon, jossa ohjelma on julkaistu);
2. Aseta taukopiste testattavalle sivulle, valitse sitten "Debug" > "Liitä prosessiin" ja valitse w3wp.exe prosessi prosessissa (sinun täytyy avata CRM tai testattava sivu ensin); Jos et löydä w3wp.exe prosessia, prosessilistan alareunassa on esitys prosesseista kaikissa istunnoissa, ja sen näkee
3. Mutta huomasin, etten voinut syöttää katkopistettä, viitaten kaikkien ohjeisiin, olipa generointimenetelmä debug ja niin edelleen, se ei ratkaissut ongelmaani.
Lopulta huomasin, että kyseessä oli web-projektin ominaisuussivun virheenkorjaaja – natiivikoodia ei tarkistettu, ja sivu voidaan debuggata onnistuneesti, joten olen iloinen!
4. Lisäksi on parasta tarkistaa yllä olevan kuvan muokkaus ja jatkaa sen rastittamista, muuten se voidaan raportoida virheeksi eikä siihen pääse käsiksi.
|
Julkaistu 18.8.2016 14.50.23
|
|
|
|
Vuokraisäntä