Console.WriteLine อยู่ที่ไหนใน ASP.NET?

313

ในแอ็พพลิเคชัน J2EE (เช่นเดียวกับที่รันใน WebSphere) เมื่อฉันใช้System.out.println()ข้อความของฉันจะไปที่ standard out ซึ่งถูกแม็พกับไฟล์โดยคอนโซลผู้ดูแลระบบ WebSphere

ในแอปพลิเคชัน ASP.NET (เช่นเดียวกับที่ทำงานใน IIS) ผลลัพธ์ของการConsole.WriteLine()ไปที่ไหน กระบวนการ IIS ต้องมี stdin, stdout และ stderr แต่ stdout ถูกแมปกับรุ่น Windows ของ / dev / null หรือฉันขาดแนวคิดหลักที่นี่?

ฉันไม่ได้ถามว่าฉันควรเข้าสู่ระบบที่นั่น (ฉันใช้ log4net) แต่ผลลัพธ์จะไปไหน? ข้อมูลที่ดีที่สุดของฉันมาจากการสนทนาที่พวกเขาบอกว่าConsole.SetOut()สามารถเปลี่ยนแปลงได้TextWriterแต่ก็ยังไม่ได้ตอบคำถามเกี่ยวกับค่าเริ่มต้นของคอนโซลหรือวิธีการตั้งค่าใน / นอกรหัสรันไทม์

asp.net iis console.writeline

— Kevin Hakanson
แหล่งที่มา

จริงๆแล้วมันจะไปที่ STDOUT ของกระบวนการ ASP.NET Worker ในกรณีที่ชี้ไปที่ฉันไม่แน่ใจ

— FlySwat

2

นั่นคือคำถาม - STDOUT ไปไหน

— Kevin Hakanson

35

เห็นได้ชัดว่าไม่มีใครรู้ แต่ทุกคนใช้มันในตัวอย่างของพวกเขา wtf

— Jason

หากคุณกำลังมองหาวัตถุประสงค์ในการแก้ไขข้อบกพร่องฉันจะดู @Greg Bernhardt ตอบด้านล่าง

— Ram

1

@KevinHakanson FWIW ทุกปีต่อมา stdout สำหรับกระบวนการใด ๆ ที่ถูกเลือกโดยผู้ปกครองกระบวนการที่เริ่มต้นขึ้น ในกรณีนี้ผู้ปกครองจะเป็น IIS นี้อาจชี้ให้คุณในทิศทางที่เหมาะสม

— jpaugh

197

หากคุณดูที่Consoleคลาสใน. NET Reflectorคุณจะพบว่าหากกระบวนการไม่มีคอนโซลที่เชื่อมโยงConsole.OutและConsole.Errorได้รับการสนับสนุนโดยStream.Null(ถูกรวมอยู่ภายในTextWriter) ซึ่งเป็นการดำเนินการแบบหลอกๆของStreamสิ่งนั้นโดยทั่วไปจะละเว้นอินพุตทั้งหมดและ ไม่ให้ผลลัพธ์

ดังนั้นมันจึงเทียบเท่ากับแนวคิด/dev/nullแต่การใช้งานมีความคล่องตัวมากขึ้น: ไม่มี I / O จริงเกิดขึ้นกับอุปกรณ์ null

นอกจากการโทรSetOutแล้วจะไม่มีวิธีกำหนดค่าเริ่มต้น

— รูเบน
แหล่งที่มา

18

ใช้ System.Diagnostics.Debug.WriteLine () ถ้าคุณต้องการให้บางสิ่งบางอย่างถูกเขียนไปยังหน้าต่างผลลัพธ์ซึ่งคุณสามารถดูได้เมื่อทำการดีบัก

— ΕГИІИО

743

ถ้าคุณใช้System.Diagnostics.Debug.WriteLine(...)แทนคุณConsole.WriteLine()จะเห็นผลลัพธ์ในหน้าต่างผลลัพธ์ของ Visual Studio

— Greg Bernhardt
แหล่งที่มา

45

ฉันจะถามคำถามเดียวกันกับเควิน แต่นี่คือคำตอบที่ฉันจะตามหา

— Zasz

11

คำใบ้อีกเล็กน้อย; หากคุณกำลังพิมพ์สตริงที่จัดรูปแบบให้ใช้ Debug.Print แทน Debug.WriteLine เพื่อหลีกเลี่ยงข้อขัดแย้งที่ขัดแย้งกัน (ดูsocial.msdn.microsoft.com/Forums/ar/Vsexpressvcs/thread/… )

— นิโคลัส Riley

12

โปรดทราบว่าจะต้องแนบโปรแกรมดีบั๊กเพื่อให้ข้อความแสดงในหน้าต่างเอาต์พุต

— Cosmin

4

สิ่งนี้ใช้ไม่ได้กับ IIS ในเครื่องหรือบางอย่าง ฉันดูเหมือนจะไม่สามารถที่จะเขียนไปยังผลลัพธ์สำหรับชีวิตของฉันแม้ว่าความจริงที่ว่าฉันเริ่มต้นด้วย F5 (ดังนั้น debugger ที่แนบมา) ฉันรู้ว่ารหัสของฉันถูกเรียกใช้เพราะฉันสามารถเขียนไฟล์ได้ดี

— Kat

@Cosmin อะไรที่แน่นอน. exe ที่ฉันควรแนบใน VS?

— เกรซ

26

ฉันพบคำถามนี้โดยพยายามที่จะเปลี่ยน Log output ของ DataContext เป็นหน้าต่าง Output ดังนั้นสำหรับคนอื่นที่พยายามทำสิ่งเดียวกันสิ่งที่ฉันทำคือสร้างสิ่งนี้:

class DebugTextWriter : System.IO.TextWriter {
   public override void Write(char[] buffer, int index, int count) {
       System.Diagnostics.Debug.Write(new String(buffer, index, count));
   }

   public override void Write(string value) {
       System.Diagnostics.Debug.Write(value);
   }

   public override Encoding Encoding {
       get { return System.Text.Encoding.Default; }
   }
}

Annd หลังจากนั้น: dc.Log = new DebugTextWriter () และฉันสามารถดูข้อความค้นหาทั้งหมดในหน้าต่างผลลัพธ์ (dc คือ DataContext)

ดูที่นี้สำหรับข้อมูลเพิ่มเติม: http://damieng.com/blog/2008/07/30/linq-to-sql-log-to-debug-window-file-memory-or-multiple-writers

— Artur Carvalho
แหล่งที่มา

ทำไมไม่เพียงแค่ใช้เครื่องห่อแบบคงที่เพราะคุณกำลังห่อวิธีการคงที่ทั้งหมด? ทำไมต้องยืดออกTextWriter?

— Kat

1

dc.Log = s => Debug.WriteLine(s);นอกจากนี้คุณยังสามารถใช้

— Rudey

1

Application_Start: System.Console.SetOut (ใหม่ DebugTextWriter ());

— Stefan Steiger

ดียิ่งขึ้น Console.SetOut (ใหม่ DebugTextWriter ());

— Alde

18

หากคุณใช้ IIS Express และเปิดใช้งานผ่านทางพรอมต์คำสั่งมันจะเปิดหน้าต่างDOSและคุณจะเห็นConsole.Writeข้อความสั่งที่นั่น

ตัวอย่างเช่นรับหน้าต่างคำสั่งเปิดและพิมพ์:

"C:\Program Files (x86)\IIS Express\iisexpress" /path:C:\Projects\Website1 /port:1655

สิ่งนี้ถือว่าคุณมีไดเรกทอรีเว็บไซต์ที่ C: \ Projects \ Website1 มันจะเริ่มต้น IIS Express และให้บริการหน้าต่างๆในไดเรกทอรีเว็บไซต์ของคุณ มันจะเปิดหน้าต่างคำสั่งค้างไว้และคุณจะเห็นข้อมูลเอาท์พุทที่นั่น สมมติว่าคุณมีไฟล์อยู่ที่นั่น default.aspx ด้วยรหัสนี้:

<%@ Page Language="C#" %>
<html>
<body>
    <form id="form1" runat="server">
    Hello!

    <% for(int i = 0; i < 6; i++) %>
       <% { Console.WriteLine(i.ToString()); }%>

    </form>
</body>
</html>

จัดเรียงเบราว์เซอร์และหน้าต่างคำสั่งของคุณเพื่อให้คุณเห็นได้ทั้งบนหน้าจอ ตอนนี้พิมพ์ลงในเบราว์เซอร์ของคุณ: http://localhost:1655/. คุณจะเห็นสวัสดี! บนหน้าเว็บ แต่ในหน้าต่างคำสั่งคุณจะเห็นสิ่งที่ต้องการ

Request started: "GET" http://localhost:1655/
0
1
2
3
4
5
Request ended: http://localhost:1655/default.aspx with HTTP status 200.0

ฉันทำให้มันง่ายโดยมีรหัสในบล็อกรหัสในมาร์กอัป แต่คำสั่งคอนโซลใด ๆ ในโค้ดของคุณหรือที่อื่นใดในรหัสของคุณจะแสดงที่นี่เช่นกัน

— คริส
แหล่งที่มา

+1 ฉันใช้ IIS Express เสมอในขณะที่พัฒนาด้วยเหตุผลนี้ เอาต์พุตคอนโซลนั้นมีค่ามากใช้ที่ส่วนท้ายเช่นคอนโซลจาวาสคริปต์ที่ส่วนหน้า ประหยัดเวลาในการดีบั๊กเมื่อเทียบกับการใช้บันทึกไฟล์เซิร์ฟเวอร์ คุณไม่จำเป็นต้องแทนที่การจัดการข้อยกเว้น "เป็นมิตร" - รักษาหน้าเบราว์เซอร์ "อุ๊ปส์" ที่ดีและเพียงแค่ส่งข้อยกเว้นไปยังคอนโซลและมองเห็นได้ง่าย

— ingredients_15939

9

System.Diagnostics.Debug.WriteLine(...);รับลงในหน้าต่างทันทีใน Visual Studio 2008

ไปที่เมนูDebug -> Windows -> ทันที :

ป้อนคำอธิบายภาพที่นี่

— Nik
แหล่งที่มา

ใน Visual Studio 2012 ของฉันฉันทำตามสิ่งที่คุณพูด แต่สตริงนั้นปรากฏอยู่OutputนอกเหนือจากคำImmediate Windowขอบคุณ!

— WTFZane

6

ไม่มีการฟังคอนโซลโดยปริยาย การรันในโหมดดีบักจะมีคอนโซลติดอยู่ แต่ในสภาพแวดล้อมการใช้งานจริงคุณสงสัยว่าข้อความจะไม่สามารถไปได้ทุกที่เพราะไม่มีอะไรฟัง

— Craig Tyler
แหล่งที่มา

5

ถ้าคุณไม่อยู่ในแอปพลิเคชันคอนโซลที่เข้มงวดฉันจะไม่ใช้มันเพราะคุณมองไม่เห็นจริงๆ ฉันจะใช้ Trace.WriteLine () สำหรับข้อมูลการดีบักประเภทที่สามารถเปิดและปิดในการผลิต

— ชาร์ลส์เกรแฮม
แหล่งที่มา

ใช่นี่เป็นจุดเริ่มต้นที่ดี: msdn.microsoft.com/en-us/library/x5952w0c.aspx

— Zhaph - Ben Duguid

3

TraceContextวัตถุใน ASP.NET เขียนไปDefaultTraceListenerซึ่งผลการกระบวนการโฮสต์ออกมาตรฐาน แทนที่จะใช้Console.Write()ถ้าคุณใช้Trace.Writeเอาต์พุตจะไปที่เอาต์พุตมาตรฐานของกระบวนการ

คุณสามารถใช้System.Diagnostics.Processวัตถุเพื่อรับกระบวนการ ASP.NET สำหรับไซต์ของคุณและตรวจสอบเอาต์พุตมาตรฐานโดยใช้OutputDataRecievedเหตุการณ์

— Brian Griffin
แหล่งที่มา

1

หากคุณบังเอิญใช้ NLog ในโครงการ ASP.net ของคุณคุณสามารถเพิ่มเป้าหมาย Debugger ได้ :

<targets>
    <target name="debugger" xsi:type="Debugger"
            layout="${date:format=HH\:mm\:ss}|${pad:padding=5:inner=${level:uppercase=true}}|${message} "/>

และเขียนบันทึกไปยังเป้าหมายนี้สำหรับระดับที่คุณต้องการ:

<rules>
    <logger name="*" minlevel="Trace" writeTo="debugger" />

ตอนนี้คุณมีคอนโซลเอาต์พุตเหมือน Jetty ในหน้าต่าง "เอาท์พุท" ของ VS และตรวจสอบให้แน่ใจว่าคุณกำลังทำงานในโหมดดีบั๊ก (F5)

— มิกกี้
แหล่งที่มา

0

นี่คือความสับสนสำหรับทุกคนเมื่อมันมาถึง IISExpress ไม่มีอะไรให้อ่านข้อความคอนโซล ตัวอย่างเช่นในแอป ASPCORE MVC จะกำหนดค่าโดยใช้ appsettings.json ซึ่งไม่ได้ทำอะไรเลยหากคุณใช้ IISExpress

สำหรับตอนนี้คุณสามารถเพิ่ม loggerFactory.AddDebug (LogLevel.Debug); ในส่วนกำหนดค่าของคุณและอย่างน้อยมันจะแสดงบันทึกของคุณในหน้าต่างผลลัพธ์การดีบัก

ข่าวดี CORE 2.0 จะมีการเปลี่ยนแปลงทั้งหมด: https://github.com/aspnet/Announcements/issues/255

— คริสไป
แหล่งที่มา

0

Mac ในโหมด Debug จะมีแท็บสำหรับเอาท์พุท

— Thushara Buddhika
แหล่งที่มา

-3

ในแอปพลิเคชัน ASP.NET ฉันคิดว่ามันจะไปที่หน้าต่าง Output หรือ Console ซึ่งสามารถมองเห็นได้ในระหว่างการดีบัก

— Leon Tayson
แหล่งที่มา