Develop Reference

C# Custom Logger - Best way to capture sending object

I am attempting to build (for learning purposes) my own event logger; I am not interested in hearing about using a non-.net frameworks instead of building my own as I am doing this to better understand .net.
The idea is to have an event system that I can write out to a log file and/or pull from while inside the program. To do this I am creating an LogEvent class that will be stored inside of a Queue<LogEvent>.
I am planning on using the following fields in my LogEvent class:
private EventLogEntryType _eventType //enum: error, info, warning...
private string _eventMessage
private Exception _exception
private DateTime _eventTime
What I am not sure is the best way to capture the object that caused the event to be called. I thought about just doing a private Object _eventObject; but I am thinking that is not thread safe or secure.
Any advice on how to best store the object that called the event would be appreciated. I am also open to any other suggestions you may have.
Thanks, Tony

First off, nothing wrong with writing your own. There are some good frameworks our there, but sometimes you reach the point where some bizarre requirement gets you rolling your own, I've been there anyway...
I don't think you should be using text messages. After doing this type of logging in several projects, I have come the the conclusion that the best approach is to have a set of event types (integer IDs) with some type of extra information field.
You should have an enum of LogEvetTypes that looks something like this:
public enum LogEventTypes
{
//1xxx WS Errors
ThisOrThatWebServiceError = 1001,
//2xxx DB access error
//etc...
}
This, from my experience will make your life much easier when trying to make use of the information you logged. You can also add an ExtraInformation field in order to provide event instance specific information.
As for the object that caused the event, I would just use something like typeof(YourClass).ToString();. If this a custom class you created, you can also implement a ToString override that will name sense in your logging context.
Edit: I am adding several details I wrote about in the comments, since I think they are important. Passing objects, which are not immutable, by ref to service methods is generally not a good idea. You might reassigne the same variable in a loop (for example) and create a bug that is near-impossible to find. Also, I would recommend doing some extra work now to decouple the logging infrastructure from the implementation details of the application, since doing this later will cause a lot of pain. I am saying this from my own very painful experience.

C# Handling Events

When I deal set up events, I usually write as such:
data.event += new data.returndataeventhandler(method);
And have a method as such:
void method(parameter)
{
dosomething();
}
This is when the event returns an object.
I have just been reading through somebody elses code and they have used, what seems to be a much cleaner way, as such:
data.ReturnData += delegate(DataSet returnedDataSet)
{
dataset = returnedDataSet;
};
Is there any downfall to this way?
Thanks.

The one major downfall of using anonymous delegates (or the even-cleaner Lambda as suggested by tster) is that you're not going to be able to unsubscribe it from the event later unless you give it some sort of name.
In most cases, this is "No Big Deal (tm)" because the delegate will go away whenever the event source goes away, but this can be a "Subtle Mistake (tm)" if you're subscribing to static events or events on long-lived objects (e.g., the WPF Dispatcher object).
In your case, this doesn't look like a problem at all, so I'd definitely recommend going with tster's recommendation (assuming you're using an appropriately recent version of .Net):
data.ReturnData += returnedDataSet => dataset = returnedDataSet;
(The compiler can infer the type of returnedDataSet from the EventHandler type of ReturnData.)

The primary downfall of using anonymous delegates is that they are not reusable. Other than that there is typically no difference between defining a delegate and then using it elsewhere in your code versus using an anonymous delegate.

One down fall is that it will not appear in your method drop down list. If you do it inline, it should only be simple, nothing overly complex.

Like said by others, the most obvious is not reusable.
Other points:
readability in particular if you have large method body
because .NET generate a random name for anonymous method (not very meaningful or readable) if you use reflection type technology or profiler, it may complicate traceability.

The only downfall is that if you have more than one event it's easier to point it to a method. If you had to attach events in different blocks to the same handler, you would have to store your delegate somewhere so that both blocks could "see" it.

Even cleaner:
data.ReturnData += returnedDataSet => dataset = returnedDataSet;

Nope its just anonymous method thats all.
You can read more about anonymous methods here.

Aside from the other answers of reusablity/Intellisense, I believe the only downfall is if you need to remove the handler later. With a delegate/lamba you cannot easily remove your handler if it no longer needs to be called.

Best practices for naming user controls?

I've created quite a few user controls to encapsulate GUI functionality used in multiple places in my app. I've noticed I usually have a tendency to describe the function of the control and tack "Control" on the end of the name, but not always. I'd like to standardize the naming and wanted to know if there's a best practice for naming User Controls in .NET?

Actually, Control is a pretty good suffix. Consider making a control for Name/Address, you want something in the name that marks it as GUI instead of Logical.
So I tend to use NameAddressControl.

I also suffix my user controls with "Control"
My typical structure for UI modules would look something like:
DataEntry
-> DataEntryForm
-> DataEntryAddressControl
-> DataEntryNameControl
-> DataEntryAddressItem
-> DataEntryAddressItemCollection
-> DataEntryConfirmationDialog
etc.
works well for our team

Try to stay with something familiar to the user unless you are coding directly for other coders. It is a proven reliability issue not to introduce nomenclature that end-user is not familiar with.

Like some of the others, we also use the Control suffix for our user controls. (ie ResPayerControl)

UI elements are the only thing that I still do Hungarian notation for. uctDoesSomething works for me.
This is mostly a preference thing but I find that when I'm selecting a control my thoughts go in the order of "what type of control would it be" and then "what does it do". In that case it makes sense to type out "uct" and let intellisense provide me the alternatives.

There are two methods I've seen used:
LoginDateCalendarCtl
UCLoginDateCalendar

firstNameLA.Text="Name:";
firstNameTI.Text="<Enter your name in this TextInput Control>";
1) lowcaseCamel because controls are default private
2) use suffix instead of prefix for intellisense, etc to pick up by name not type
3) include the type and not simply 'Control', to remind your mind of the real, weireded-out names of all those darn fancy-schmantzy ui comps you gots

Where do I put my C# delegate declaration, in a file of its own?

Out of habit I tend to put classes/structs/enumerations in separate files when not nested.
For delegates, it seems like overkill to create a seperate file for a one liner:
public delegate string MyDelegateThatIsNotNestedInAnyClass ( string par );
I usually add it to the bottom of the most closely related class file. I was just wondering what other people do?

I tend to put each type in a separate code file. Doing so will help you navigate in Solution Explorer, though ReSharper rocks with "Go To File"
(source: jetbrains.com)
and "Go To Type":
(source: jetbrains.com)

I usually add it to the .cs file of the class which implements the delegate function (at the namespace level). If there are several of these, I put it in a separate file.
If I know for sure that only one class will implement the delegate function, I nest it in the implementing class.

I personally add it before a closely related class definition. I make good use of namespaces, though, so I don't pollute!

If it's closely related enough to belong in the same file as the class, then you can probably justify nesting it in the class. Then you'll have no trouble remembering which class file it's in.
If there's no single class that's an obvious choice to nest in, creating the one-line file is probably worthwhile since you'll never waste time trying to remember which class file you decided to put it in.

I allways declare my own events, even if I don´t need them in the sence that a generic event would suffice. The reason for that is that the class name of the event gives the code so much more readability and also not seldom the declared event will be needed further down the road for some reason.
Since I have an event class, I allways put the delegate above the class declaration of the event. They are closely coupled and if you need to listen to the event then you´ll need both the event and the delegate. I don´t know if this violates some design rules of any kind, but this has worked nicely for me.

Usually, I just use:
Func<string, string>
these days

(Conventions) C# Class names

I'm not too quite sure about what i should do about a grouped set of classes.
My situation: I have 11 classes that relate only to the class Character.cs, but all of those classes (including Character.cs and CharacterManager.cs) are within the namespace Models.Characters.
Which is the more "proper" or preferred way of naming the classes:
(examples):
CharacterDetails.cs
CharacterSprites
CharacterAppearance
CharacterClientRights
CharacterServerRights
or:
Details.cs
Sprites
Appearance
ClientRights
ServerRights
(They're all noticed in Models.Characters (so eg. Models.Characters.CharacterDetails, Models.Characters.Appearance)
Thanks in advance.

Personally for me it"depends". Usually I would prefix everything with the word Character to keep things consistant, however if you have everything already under the Character namespace the Character prefix could seem redundant.
I could easily see going with the shorter convention of Models.Character.[X] if there never will be another class called Details, if there for instance could be UserDetails then Details and UserDetails could be confusing when looking back at the code weeks or months from now and I would personally prefer then the CharacterDetails option.
In the end it is your personal preference, what more accurately describes your domain, Details or CharacterDetails?

Personally I'd stick with the second method as that is what namespaces are for: grouping related sets of classes. The first method is just making the class names longer with negligible benefits.

Your namespace already is grouping its classes under the Characters umbrella, so I would not name your classes with the Character moniker.

There is probably no right or wrong answer here. I find myself prefering your first style, but I have used the second style as well. I think in this specific situation if I were a caller of your API I would find it easier to read code that used the first style.

It is really a personal preference.
I would favor
CharacterDetails
CharacterSprites
CharacterAppearance
CharacterClientRights
CharacterServerRights
Because it is more readable.
You are typically going to have a using statement of
Models.Characters.Appearance
Unless you are going to do the full notation.
I would favor anything that would increase readability. It might matter on the project and the team you are working with. If it is just you than do what you like best and would help you maintain the code in the future.

As long as you pick one and consistantly use that throughtout your code, then whichever one you choose is the right one.
My personal choice is your second option. If your namespace is character, I see no reason to use the prefix character in the class name.

Think about ambiguity that may be created by naming class. For example if I have a class called "Thread" denoting "CharacterThread" (hypothetical) and if some other class uses two namespaces
Models.Characters
System.Diagnostics
I will have to fully qualify the Thread name everytime I use it ... which can be a pain sometimes