I have a simple asp.net application. I want to write in the output console of visual studio in debug mode. I've been using this code for a long time System.Diagnostics.Debug.WriteLine("Hello");.
When I run my web application with IIS Express, it works perfectly well.
When I run it with IIS, nothing appears.
How can I write in the output console with IIS ?
Edit : trying to use Trace which is better, here is the code i put in the Application_Start method of my Global.asax, but still not working :
System.Diagnostics.Trace.Listeners.Add(new ConsoleTraceListener());
System.Diagnostics.Trace.WriteLine("Hello");
You can use the Trace class. It provides a versatile interface to log the execution of your application.
You have to register a listener when your app starts (this can be in various places, depending on your application):
using System.Diagnostics;
...
Trace.Listeners.Add(new ConsoleTraceListener());
Then you can use Trace.WriteLine("Logging to output window"); to log.
Related
How is (cross-platform) logging achieved with Uno? (to console, mainly)
I'm using Visual Studio, starting the UWP Head, and when i try to write something to the log, I'm expecting it to appear in Visual Studio Output windows / Uno Platform output, but nothing shows up there.
I'm using the following code (that i found in various repositories, as a supposed 'standard' way to log), in a UWP page 'code behind' code:
this.Log().LogInformation("My log");
but, as I said, nothing appears in the output windows.
The documentation says that to enable console logging you should use the following code:
Uno.Logging.LogManager.LoggerSelector = Uno.Logging.ConsoleLogger.Instance.GetLog;
Uno.Logging.ConsoleLogger.Instance.LogLevel = Uno.Logging.LogLevel.Warn;
Uno.Logging.ConsoleLogger.Instance.Filter = (level, name, message, exception) =>
{
// Provides a list of loggers that should be displayed to the console
var passList = new[] {
"Windows.UI.Xaml.VisualStateManager",
"Windows.UI.Xaml.VisualStateGroup",
"Windows.UI.Xaml.Controls.RadioButton",
};
return passList.Any(n => name.StartsWith(n))
? Uno.Logging.ConsoleLogger.FilterResult.Pass : Uno.Logging.ConsoleLogger.FilterResult.Ignore;
};
but the types Uno.Logging.LogManager and Uno.Logging.ConsoleLogger are not existent. Are they defined in additional libraries/nuGet packages? And where does this code should be placed?
EDIT:
This happens only with the UWP head. With the Wasm head, the log messages show correctly in browser's console, and with Android head (running in an emulator) they show up in Visual Studio's Output/Debug window. Can't try the iOS head, sorry.
Environment:
Visual Studio 2019 16.7.3
Uno.Core 2.0.0
Uno.UI 3.0.17
Uno.UI.RemoteControl 3.0.17
Uno.UI.WebAssembly 3.0.17
Uno.UniversalImageLoader 1.9.32
Uno.Wasm.Bootstrap 1.3.4
Uno.Wasm.Bootstrap.DevServer 1.3.4
When you are calling this.Log(), it will capture the fully qualified named of the this's type.
If you add the namespace of this type to the passList, it should work.
When you create a project using the template, you'll see a ConfigureFilters method in the App.xaml.cs file. Add you namespace there in the .WithFilter() call.
Example of such call here.
I want to know how to be able to read a text file from both :
when running as a standalone
and
when running from a host ASP.NET app.
I am aware of the Server.MapPath command but it only works on the ASP.NET app and I want the file loading to be done from the console application.
Let's begin with an empty project and create two projects :
First, a Console application :
Then, a ASP.NET MVC application :
Once we have our two projects, let's create a text file :
And put something in there :
Make sure it is included in the bin folder :
Now, we can finally read the file content like this :
Using the following code :
We get the desired output.
Now, as stated in the beginning of this post, I want to be able to access the file from the same project, but called from the ASP.NET app.
Let's add the console app as a project dependency of TestWebApp :
And call it's method like so :
Now I get this error :
I want to know how I would go on and be able to load the file both when running the app by itself (console app) or when running from a host web service (asp.net web server).
Use AppContext.BaseDirectory. This is the directory for which the runtime checks to resolve assemblies. In your context, this is the closest to the output directory.
Now there is a difference between what it returns for the Console App vs Web App. The below common code would address both.
var appContextBase = AppContext.BaseDirectory;
var filePath = appContextBase.IndexOf("bin", StringComparison.OrdinalIgnoreCase) == -1 ? "bin/Files/File.txt" : "Files/File.txt";
var fileContent = File.ReadAllText(appContextBase + filePath);
Console.WriteLine(fileContent);
For Console App, AppContext.BaseDirectory returns something like this - "C:\\Users\\user123\\Documents\\Visual Studio 2017\\Projects\\MySamples\\MySamples\\bin\\Debug\\"
For Web App, it returns something like this - "C:\\Users\\user123\\Documents\\Visual Studio 2017\\Projects\\MySamples\\MyWebApp\\"
That is the reason I have added the ternary operator check on the filePath.
I'm developing a console application that is supposed to run under WinCE 6.0 and WinCE 7.0. I'm using C#, Compact Framework 2.0 for different compatibility reasons.
My application is started by an external runtime called TwinCAT (from Beckhoff). Within this application, my teammate used a function block called nt_startProcess (documentation here) that is in charge of starting my application on demand.
My problem - Two different behaviors depending on the OS :
When started manually (without TwinCAT) from a cmd line :
My application behaves properly on both systems. It means that, the applications starts, displays "Hello World" and then returns to the cmd line.
When started from TwinCAT :
a) On WinCE 6.0, I can see a cmd line opening, displaying "Hello World" and shutting itself right after. Perfect behavior to me.
b) On WinCE 7.0, I can see a cmd line opening, displaying "Hello World" but it remains open forever. This is my problem!
Code snippet :
using System;
using System.Collections.Generic;
using System.Text;
namespace MyBasicExample
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Hello World");
}
}
}
Compilation information
In Visual Studio 2008, within the Project compilation's properties :
Plateform target : Any CPU
Additionnal note :
Please note that the computer who is running WinCE 6.0 is using a i486 processor while the one running WinCE 7.0 is using a Freescale ArmCortex process.
WinCE 6.0 :
WinCE 7.0 :
What I tried :
1) Using return 0; at the end of application.
Doesn't change anything on WinCE 7.0.
2) Using Environment.Exit(0);
Is not available in Compact Framework 2.0.
3) Using the property : IsBackground
Snippet :
// ... Same snippet as above except for the next line...
Thread.CurrentThread.IsBackground = true;
Console.WriteLine("Hello World");
// ...
4) From TwinCAT, calling a batch file (which calls my exe) instead of my exe.
Doesn't work with TwinCAT. I get an error of type "General Sub-Windows error".
5) Tested with the Compact Framework 3.5.
Same behavior.
6) Tested with another CX computer (model 2020) using Windows CE 7.0 and another processor architecture (Intel Pentium III Xeon Model A).
Same behavior.
try this code:
Environment.Exit(0);
Try this:
Tools > Options > Debugging > Automatically Close the Console When Debugging Stops
Are you putting you .exe file in Arguments property of ProcessStartInfo ?
If you must do that, I believe that you're using CMD in FileName property, so you must use /K before your .exe name.
Or just put in FileName the .exe path.
You can clarify a lot if you put the code that calls your application.
Try calling Application.Exit
This works in windowed applications, and may force the console window to close.
I had exactly the same problem. Running console app on Beckhoff PLC which never closed.
Instead of creating Console app I created Windows App.
My code stayed the same as for console app. I just commented out:
// Application.Run(new Form1());
Seems now codes run without opening a form.
I created a Windows service in C# (4.0) and am trying to install it using installutil tool in command line. However I get an exception. I managed to find out what part of my code is causing the exception - using some crappy logging but whatever - but now I want to understand why. So what I want to do is debugging the installation of my Windows Service.
I know how to debug the service itself, but here, I want to debug the content of my Installer.Install(IDictionary stateSaver) method in the service.
I tried to attach the debugger to the cmd.exe process but it obviously doesn't work. I was thinking also to attach the debugger to the installutil process but I have no clue how to do this.
I had a look to this post: How do you debug a windows service that is being installed? and several others but in this case, for some reason, this guy seem to have his service already in the services.msc which is not my case.
How can I achieve this?
You can put a Debugger.Break(); statement in the installer code, and it should launch the debugger for you.
If the above does not work, I have found this process works too. Basically, you compile in debug mode and install the service (I used installutil.exe through the command line). In code you pop-up a message box with the process ID. Startup a second instance of studio, attach it to that process and debug. The message box pauses it to allow setup. The process ID isn't important, its named InstallUtil.exe. I usually put a Debug.Break() in after the message box to guarantee it enters the code.
using System.Windows.Forms;
using System.Diagnostics;
...
#if DEBUG
int processId = Process.GetCurrentProcess().Id;
string message = string.Format("Please attach the debugger (elevated on Vista or Win 7) to process [{0}].", processId);
MessageBox.Show(message, "Debug");
#endif
....
How to debug the installation of a custom windows service
[Visual Studio 2008]
I created a new project for console application and modified it to look like this:
class Program
{
static void Main (string[] args) {
Thread.Sleep (2000);
}
}
Then I created another project for Windows Form application and modified it:
static class Program
{
//[STAThread] commented this line
static void Main (string[] args) { //Added args
//Commented following lines
//Application.EnableVisualStyles ();
//Application.SetCompatibleTextRenderingDefault (false);
//Application.Run (new Form1 ()); commented this line
Thread.Sleep (2000);
}
}
Now I have neither written Console functions (Console.Write etc.) in first application nor I have written forms related operations in second one. Looks identical to me.
Still first application shows BLACK window and second one doesn't show anything. What makes it work like this?
If you inspect the exe files usine ILDASM you can see that there is a difference in the Manifest (look for "subsystem").
In a Winforms application:
.subsystem 0x0002 // WINDOWS_GUI
In a console application:
.subsystem 0x0003 // WINDOWS_CUI
There may be more differencies in the IL code.
When it comes to what makes the compiler emit this differently in the two cases, this is controlled by the project file's OutputType value:
In a Winforms application:
<OutputType>WinExe</OutputType>
In a console application:
<OutputType>Exe</OutputType>
Out of curiosity I also checked that value for a Class Library project:
<OutputType>Library</OutputType>
In project properties, Application Tab, Output Type you can set to 'Windows Application' or 'Console Application'.
I believe that behind the scenes VS does exactly what Fredrik presented in his post.
Also, setting it to Console Application will show you the black console application for the windows Forms project.
Under the bonnet, there is no difference in a winform vs console exe except for a flag in the PE-header that says "I need a console". The PE header is not controlled from your C# (since it is a compile thing, not a runtime thing), so this is defined in the project file instead (<OutputType>...</OutputType>).
Or at the command-line (csc /target:exe vs csc /target:winexe).
Arguably, they could have used an assembly-level attribute that the compiler intercepted - but would that really have helped? Probably not.
If you look in the project file (csproj) you'll see that the target is defined there as either a console or windows app.