I am doing some practice tests for Microsoft's "Programming in C#" exam 70-483 and one of the questions has me in a stump and I don't know enough about tracing to test it properly.
The question is this:
You are developing an application that uses a .config file.
The relevant portion of the .config file is shown as follows:
<system.diagnostics>
<trace autoflush="false" indentsize="0">
<listeners>
<add name="appListener"
type="System.Diagnostics.EventLogTraceListener"
initializeData="TraceListenerLog" />
</listeners>
</trace>
</system.diagnostics>
You need to ensure that diagnostic data for the application writes to the event log by using the configuration specified in the .config file.
What should you include in the application code?
A. EventLog log = new EventLog();
<br/>log.WriteEntry("Trace data...");
B. Debug.WriteLine("Trace data...");
C. Console.SetOut(new StreamWriter("System.Diagnostics.EventLogTraceListener")); <br/>Console.WriteLine("Trace data...");
D. Trace.WriteLine("Trace data...");
I'm thinking "C" because it's the only option that has something to do with the .config file, but it says the correct answer is "D" for some reason. Mind you these questions have been wrong before about completely simple and obvious stuff, so...
Can you please explain which is the correct answer and why?
The solution is to read about tracing instead of trying to just find the correct answer.
C is the absolute worst - not only does it have nothing to do with System.Diagnostics or the EventLog, it will try to create a file named System.Diagnostics.EventLogTraceListener.
The only options that actually use System.Diagnostics are B and D.
The <system.diagnostics><trace> section in app.config configures the System.Diagnostics classes, including sources, listeners, switches that activate or deactive specific sources in the application etc. It's no different really than the configuration files used for any other log library like log4net, Serilog or NLog.
Debug.WriteLine("Trace data..."); will write the output to all the configured trace listeners, only in a debug build.
Trace.WriteLine("Trace data..."); will write to all configured trace listeners both in debug and release builds.
Option A is wrong too. It does involve the event log, but won't work because the Source isn't set. EventLog.WriteEntry doesn't send any diagnostic information either, it just writes an Information message to the Event Log.
The System.Diagnostics listener on the other hand will receive diagnostic events from the myriad of trace sources in .NET, including the application's own, filter it, and write it to its target.
Do you have a problem with networking for example? You can switch the System.Net trace listeners on and collect trace messages from the HTTP level all the way down to sockets, SSL, TCP and even packet operations.
The correct answer is the "D", What that configuration file is doing.. is adding an instance to the trace.Listeners. So whenever you call Trace.WriteLine one of the outputs will be to that listener you set up in the config file.
"C" would work too, but it does say that you need to ensure that you use the config file, and what you are doing in C has nothing to do with the config file.
Related
Is there a mechanism (or config file setting) that will trace read operations against a .NET config file?
Background: I'm working on a SOAP test client application and there's one point where it's complaining about not finding the endpoint element and contract details in the configuration file. There are 9 services, 8 are working fine. The naming of the problem service is complicated with spelling errors (service name, wsdl port name...) I'm starting to suspect that parts of the .NET framework use convention rather than direct configuration to locating parts of the binding configuration. I think I have the name mutated correctly in the various places but when making the connection it still errors.
After all that, what would help is if I could get a trace output as the program (framework) reads through the configuration file. It would be easy at that point to see what specifically is miss-spelled or where it is my mistake.
It's almost impossible to search for this topic, all the hits along the lines of "debugging config file" return links for adding logging to a config file or configuration management of an app build.
I have made a WPF application, and i am using multiple WCF services(deployed on remote server) in it. Currently all client configurations(end points) are given in app.config. If i open App.exe file (File Type: XML Configuration File) in notepad then i can see all configurations (end points) there.
What i want is that i want to hide that configurations so that end user can't see my configuration details (especially Address attribute).
Does Somebody know how to secure/hide my WCF end point? Either i need to use some tool to encrypt app.config file or i need to write client end points in code (if yes then how) ?
Thanks in Advance :)
If you're worried about divulging your endpoint address, you're doing security wrong. It sounds like what you need is--at minimum--to authenticate your WCF service properly.
I recommend starting with the WCF Security documentation.
While trying to figure out how to get log information for an Azure Web/Worker role, lots of posts suggest that I need to set my configuration settings in -two- places.
1 Configure .config file
<system.diagnostics>
<switches>
<add name="logLevel" value="2" />
</switches>
<trace>
<listeners>
<add type="Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics, Version=1.8.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" name="AzureDiagnostics">
<filter type="" />
</add>
</listeners>
</trace>
</system.diagnostics>
2. Programatically (ie. OnStart method)
DiagnosticMonitorConfiguration config = DiagnosticMonitor.GetDefaultInitialConfiguration();
config.Logs.ScheduledTransferPeriod = TimeSpan.FromMinutes(1);
config.Logs.ScheduledTransferLogLevelFilter = LogLevel.Warning;
DiagnosticMonitor.Start("Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString", config);
I don't understand why everyone are suggesting that we have to define the logging filter level twice?
Shouldn't the configuration file be sufficient?
In the 1st one, you're telling your application (website etc.) what kind of trace listener you would like to use. Or in other words, when you write something like Trace.WriteLine("Something"), who should listen to that message.
While in the 2nd place, you're telling the diagnostics monitor engine running in your VM what to do with the tracing data sent to it.
For example, in your code (OnStart method) you have configured:
config.Logs.ScheduledTransferLogLevelFilter = LogLevel.Warning;
What that means is that diagnostics monitor engine will only accept trace messages with log level Warning or above i.e. only those messages will be considered for transferring into storage. So even if you're writing Trace.Information("Something") in your code, that will be ignored by the diagnostics monitor.
Another thing you do in your code is telling the diagnostics engine what to do with the diagnostics data it has collected. Some of the other things you configure there are:
Buffer Quota - How much data should be held in the buffer before it gets rolled over.
Transfer to Storage - How frequently you would like to transfer the data to Windows Azure Storage.
#Gaurav Mantri 's answer probably touches exactly what you needed.
However,
Shouldn't the configuration file be sufficient?
I am not sure what you mean by "sufficient".
Azure Cloud services are already predefined with default values for the DiagnosticsMontiro, and therefor you don't HAVE to add those code lines.
Actually, since almost everything in Azure configurations can be controlled from outside the application, it is also preferred not to change configurations in code.
The following is taken from MSDN:
The Windows Azure SDK gives you the ability to configure Diagnostics using an XML configuration file (diagnostics.wadcfg) instead of programmatically configuring diagnostics in the OnStart method of your role. This approach has several advantages over writing code:
Diagnostics starts before the OnStart method is called, so errors in start-up tasks can be caught and logged.
Any changes made to the configuration at run time will remain after a restart.
Diagnostics configuration changes do not require the code to be rebuilt.
You can automatically start the diagnostics monitor in a specific configuration without needing additional code (which might cause an exception that would prevent your role from starting).
I am developing c# application, which is running as a windows service.
What ever transactions we are doing in the application i am writing it into log file.
A log directory is added in app.config file as below.
<add key ="LogDir" value="log" />
<add key ="LogLevel" value="2" />
And in the c# code the above one is accessing as below.
int logLevel = Convert.ToInt32(ConfigurationManager.AppSettings["logLevel"]);
if (logLevel > 0)
{
logger = new Logger();
logger.TraceLevel = logLevel - 1;
logger.logDir = ConfigurationManager.AppSettings["logDir"];
logger.logFileBaseName = "touchserver";
}
And then when any process is happening i am writing the data to the log as below.
TouchServer.Log(Logger.MessageType.Trace, 1, "Item successfully deleted");
And when i run my application in debug mode (i mean as console application) the log file will be created in the application's debug folder and the data will write into the log file.
But my problem is that when i install my application as service the log file is not getting created in the debug folder, and i am unable to see the actions performed , in case if anything went wrong.
Please help me to find a solution in this.
And i am installing service using Installutil command.
Thanks in advance
sangita
While you could get into why this is not working and fix the solution, overall there is no need to implement a logging component.
There are excellent free libraries available that do this very well. log4net is very popular. It is easy to use, feature rich and efficient. Take a look at it.
But my problem is that when i install my application as service the log file is not getting created in the debug folder, and i am unable to see the actions performed , in case if anything went wrong.
Check out what are the result of the IO operations by using Process Monitor. I suspect you'll find the identity being used to run the service process does not have write permissions where it is trying to write the log file.
But the better option is to use an existing logging library as Hemal suggests.
I am using a third party tool which internally adds trace messages using the following code:
System.Diagnostics.Trace.WriteLineIf(
new System.Diagnostics.TraceSwitch("Switch", "").TraceInfo, message);
In this scenario, it appears that I must add the switch to my app.config file to get the trace messages to appear:
<system.diagnostics>
<switches>
<add name="Switch" value="3" />
</switches>
</system.diagnostics>
Since not all of my users are granted administrator rights to make changes in the Program Files directory this becomes an issue.
Is it possible to set the TraceSwitch programmatically and allow the third party tool to write the trace messages?
Yes to first part of question. Probably no to second part, since the third-party is creating a new TraceSwtich on each call to WriteLineIf. In my opinion, it seems the third-party control has a failed implementation because 1) it should allow you to change the "switch" programmatically through a property, method, or function, and 2) it is reading the config file on every trace statement.