|
Simon_Whale wrote: my question is that currently I log at exception levels, but I feel that this level of logging is not enough.
Can you objectively point out where you lack logging and which part needs additional tracing?
You could trace every sql-statement on the database-server, log a lot of actions and events, and even log the information on the network. You could "always" run the app in debug-mode, using a custom debugger to log everything.
If you're hunting exceptions in the wild, you might want to make minidumps[^]. That's not logging, but might still be what you're after.
Bastard Programmer from Hell 
if you can't read my code, try converting it here[^]
|
|
|
|
|
Thanks Eddy
The application is a complete back office for an insurance underwriters which I work for, at present I felt with just capturing the exception and the data that caused the issue it gave me a wild goose chase to find the area that caused the problem, as not all the time does the user give you a full picture of what they were doing.
but with information from yourself and Richard I now have a lot of things that I can do to make logging a good debugging tool.
Thanks
Simon
Lobster Thermidor aux crevettes with a Mornay sauce, served in a Provençale manner with shallots and aubergines, garnished with truffle pate, brandy and a fried egg on top and Spam - Monty Python Spam Sketch
|
|
|
|
|
Simon_Whale wrote: what I am asking is advice / help or even pointers to a good logging strategy.
There are several definitions for logging. I have taken to using the following definitions.
1. Audit logging. This involves tracking what 'users' are doing on the system. For example if a user deletes a record then a 'audit log' is created. This can be driven 'users' that are not actually people such as a 3rd party application.
2. Operations logging. This is information collected specifically to assist operations staff in diagnosing expected error conditions. For example if a third party web service goes down then operations needs to know about it.
3. Trace logging. This is logging that assist a developer in determining why a system failed due to unexpected problems. It will often require familiarity with the code base to understand everything.
Audit logging is defined by business requirements.
Operations logging is defined mostly by operations but can be guessed at by development.
Trace logging is solely dependent on development making educated guesses about failure points.
Specifically for trace logging...
Trace logging does NOT work if it does not exist in the production system. Thus trace logging is NOT a tool that is used during development. That doesn't mean you can't add logging to figure out some obscure problem while you are writing code but it does mean that the logging statements that are left in must be manageable in production.
It also means that logging must exist in the production system. It is not turned off nor turned down.
Trace logging can be used by operations but operations does not dictate, control nor otherwise own it. Operations can make suggestions for improvements but consideration should be given that operations has their own log and thus most times what they want should be in there and not in the trace log.
In general logging (trace logging) cannot use a off box repository (database,etc) because both of those can fail. And with such failures there must be some way to log that.
Trace logging must not stop the real application from running. Compare this to audit logging which one might code such that the application stops working if it can no longer do audit logging.
With smaller systems it often seems possible and desirable to do things like log the entry and exit from every major method. However that is impossible in systems will larger volumes. Both because the log files can become large very quickly (think 10 of gigs daily or larger) and because finding anything when there is a lot of data becomes a problem.
So addressing large system only one can come up with the following
- Log exceptions but insure that they only log once. In practice this means that if you catch an exception and log it you do NOT re-throw it.
- Log entry and exit (including success/failure) from major functional areas.
- Provide a trace id for every message in the application and even better in the system. When logging relevant to message processing then always log with that id.
- Log off box request/response attempts. This includes success and failure. Especially when going to a 3rd party.
- Avoiding logging in looping structures. This is to reduce noise. Logging at the beginning and the end is sufficient.
- Avoid duplicate logging. If you load configuration information don't log it every time you access the configuration information, but only the first time.
- Log messages must contain relevant information. Thus don't log "x=3" but instead "result of order query=3"
- Log messages are not a dumping ground for development. Developers must keep in mind that the log file is not an infinite resource and also keep in mind that although they will need to use it to debut problems that unnecessary log lines can multiply hundreds of thousands of times in production and thus make it that much harder to determine problems. The log file provides assistance but not solutions to unknown problems.
Another trick that I have found valuable works in some scenarios with exception handling.
- This is often a boundary layer system.
- I catch an exception, log it along with an id (GUID).
- I throw another exception with a message that is appropriate for the boundary layer and I include the id as part of the message.
The advantage of the above is that upstream, perhaps a user or a third party system gets an error message that means something to them. And questions about that can be address in the context of finding the exception cause in the log file with the id if that becomes necessary.
|
|
|
|
|
Thanks jschell
that has given me great things to read and use 
Lobster Thermidor aux crevettes with a Mornay sauce, served in a Provençale manner with shallots and aubergines, garnished with truffle pate, brandy and a fried egg on top and Spam - Monty Python Spam Sketch
|
|
|
|
|
There are several questions that need to answering:
1. What
Despite the actual text you might want to log off course, the datetimestamp (go millisecond or smaller!), but also who was the user at the time, what machine, which application, module, class, method and finally you'll need a log type (error, warning, information,...) and severity.
2. When
Concerning the actual log message I usually log every exception and the SQL statements. Then mostly I add logging at key points eg when receiving information from a webservice call or when we send an email succesfully, ...
3. Where
Mostly one logs to a txt file or something like that. I find that horrible personally. If you have one application, no problem, but if you have a system, log to the database. It will be easier to trace the sequence instead of going through five log files at the same time comparing datetime stamps. It is always possible to catch a db down and write to txt file as backup.
4. How
Prevent in using a method inside each class, create an assembly that can be used by all applications. Built in a debug level setting that will prevent logging too verbose when not required.
Hope this helps.
|
|
|
|
|
sample application developing in c#
|
|
|
|
|
You can find samples in various books, and even on Microsofts' website. There's samples on this website too.
Start here[^].
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
|
|
This isn't even a question. You want a sample application (bad enough - why should we do your work for you) but don't describe what it is that you want (which could range from a "hello world" application to modelling the universe).
|
|
|
|
|
If you are still a sophomore, you can be pardoned and I would suggest a read of Some guidelines for posting questions in the forums[^]
But if you are working in some organization, I would seriously need to know the management of the organization and shoot down the CEO mercilessly because you are just one sample of the whole bunch of rotten apples waiting to spoil the face of entire developer fraternity.
Vasudevan Deepak Kumar
Personal Homepage
Tech Gossips
The woods are lovely, dark and deep,
But I have promises to keep,
And miles to go before I sleep,
And miles to go before I sleep!
|
|
|
|
|
countered downvote 
|
|
|
|
|
|
|
Hi,
I have to create a single setup package which on detection of User's machine decides which msi to consider(compiled for x86 bit machine or x64 bit machine).
My Project using:
1. Visual Studio 2010
2. Coded in C#
3. Built on framework 4.0
4. Using Windows Installer 4.0
5. Prerequisits included (Framework 4.0 (integrated x86 & x64) and SQL Express2008 (integrated x86 & x64))
Problem is currently i have to build 2 setups for different target palteforms (x86 & x64) which bundeling same prerequist files.
If a single setup can be done which decides which sub-msi to use will save more that 100 mb of files to be included in the package.
Thus i want to create one setup.exe, one set of prerequisites and two msis' in separate folders (e.g. x86 & x64) which contains their respective msi file.
So that executing setup.exe will search for firstly prerequisites & then on the basis of system will run the appropriate msi to install.
Regards,
honeyashu
modified 25-Oct-12 5:26am.
|
|
|
|
|
I don't think that is possible, every app I have downloaded that has a different requirement for 86/64 has supplied separate MSIs.
I would be mightily annoyed if I had to download x86 files when installing on a 64 machine!
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Thanks for your reply, but what i want is i want to create one setup.exe, one set of prerequisites and two msis' in separate folders (e.g. x86 & x64) which contains their respective msi file.
Thus running on setup.exe will search for firstly prerequisites & then on the basis of system will run the appropriate msi to install.
Regards,
Ashish
|
|
|
|
|
OK, so what's the problem then??
Other than, yes it's possible. Setup.exe wrapped installers like this are made all the time.
BTW: Your pre-req's, depending on what they are and how your application uses them, would possibly ALSO have to be seperated into x86 and x64 versions. You cannot mix 32 and 64-bit code in the same process, so if your app is running 64-bit, it cannot use a 32-bit library.
|
|
|
|
|
Problem is i am unable to find a way to create such type of setup.exe
which should call appropriate msi to run on correct system.
|
|
|
|
|
You can create the Setup.exe in any language you want. C and C++ won't require you to install a prereq just to run the Setup.exe. You could use C# or VB.NET, but the user would have to install the .NET Framework on the machine first (if needed) before the user launches your Setup.exe.
In any case, all your Setup.exe is doing is determining which bitness of Windows it's running on then starting a new Process with the appropriate command line to launch your installer, such as "msiexec /i myinstall.msi" and waiting for it to end.
|
|
|
|
|
I don't think it can be done with an MSI installer. You need to have two projects which build two versions of the .msi and which you both provide for download to the user.
You could write a tiny application that checks the platform, downloads the appropriate MSI and uses Process.Start to run it. Most applications don't bother with this, they expect users to know which platform they're on.
|
|
|
|
|
Hello Community,
I am fairly new to OOP so forgive me in my faltering.
I'm putting together a rather small application, in WPF .NET4CP. This application will fetch information from a SQL server and should display the results.
In this example the SQL DB's table will contain lets say 5 columns (first name, last name, description, job, access). These are all varchar.
When the query is run from a button onclick, each resulting row's field will need to be mapped to a control (like a label or something simple). Here's what I do not understand - how does one dynamically create instances of controls AND handle where they will be shown/placed/located in the application (these controls may not all be grouped together in the same place - a tabular listing of results wouldn't do me much good).
I seriously wouldn't want to define an int for say a Y axis value, and for each result, create a new instance of a control, set Y axis to int and then increment int +=10; and go to next result right?
I'm missing fundamentals here and I'm frustrated that I'm not sure what the proper terminology is or how to search for answers.
modified 25-Oct-12 12:03pm.
|
|
|
|
|
The most common design for this type of data is to use a grid to list the records and a panel/dialog/form to display the detail.
There is nothing dynamic about the UI, especially with WPF/Silverlight, you should know what the columns are and can therefore name the grid columns and the form controls.
As you have all the information you then design the view placing the controls where you want them.
The grid should be bound to a collection and there should be a selecteditem bound to the grid and the form controls.
I suggest you get a book on WPF and work through some examples you do not have a grasp of the fundamentals yet.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
In addition to Mycroft's comments I would mention that there is also a Silverlight WPF forum[^], which may be a better place for future questions.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
This sounds like it can be done with a ListBox or something similar, data bound to the result of the query. The rows of a list box can be complex controls (or groups of controls), by changing the ItemTemplate.
|
|
|
|
|
Thank you all for your assistance
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
