Debugging Windows Service without deploying it

Have you ever tried to build a Windows Service? Did you get it right the first time? Chances are that you had to modify it a couple of time before getting it the way you want it. Each time you had to build the installation package, uninstall the old version and reinstall the new one. Hopfully you can get the installation package to remove old version before installing new one. How did you debug it? Your only option was to start the service and attache a debugger to it. Although this is a good way to do it and you must go to that process before going into production with your service, this is way too much time consuming for the deveopment process. I invite you to take look at a simple class I built to enable any Windows services to be debug from Visual Studio using F5. Here are the step you have to follow:

1. Build or open your own Windows Service project
2. Change it's build setting to be a console application
3. Add ServiceDebuggerHelper project to your solution (can be download from CodeProject)
4. Add a reference to ServiceDebuggerHelper project in you project
5. Modify your Program class to start your service with ServiceRunner if it is started with /debug command line argument
6. Modify your service to be debuggable in one of two way:
   1. Implement IDebuggableService interface
   2. Inherit from DebuggableService base class
7. Start it in debug mode

See Debugging Windows Service made easy on CodeProject for details.

Passing anonymous to and from method's call

As posted by Alex James on Meta-Me blog.

T CastByExample(object o, T example)

So earlier today I was lamenting that an anonymous type can't be
shared between functions with Wes Dyer, when he said "Well actually they can..."

Cue me learning something cool.

The first step is to create a seemingly innocent method:

    public static T CastByExample<T>(this object o, T example)
    {
        return (T) o;
    }

Seems innocent enough right? Well it is until you start using it with anonymous types. Imagine you had this function, that returns an anonymous type as object, because that is your only choice:

static object GetAnonymousType()
{
    return new { FullName = "Cosmo Kramer" };
}

Normally if you called this function anywhere you wouldn't be able to get at the anonymous type without using reflection... This is where CastByExample<T> comes to the rescue. If you know the shape of the anonymous type, you use that to do a CastByExample...

        object o = GetAnonymousType();

        //get the original anonymous type back again
        var v = o.CastByExample(new { FullName = "" });

        //Use the properties of the anonymous type initialized in another
        //function directly !!
        Console.WriteLine(v.FullName);

This works because when an anonymous type is used the compiler first checks that one with the same signature (i.e. all fields are the same name and type) hasn't already been used. If one has the same CLR type is used.

Hence if you pass in an example that is the same shape as the original anonymous type to the CastByExample(..) method will get you back to the original anonymous type... and var magic does the rest.

Nifty huh?

Visual Studio 2008 Training Kit - Ready for the next step?

You can download your Visual Studio 2008 training kit now!

http://www.microsoft.com/downloads/details.aspx?FamilyID=8bdaa836-0bba-4393-94db-6c3c4a0c98a1&displaylang=en

Quick Tip: Knowing if you are running from visual studio or not

I was trying to know if my program is running from visual studio or not. The reason for that is I want to add a pause in my console application only if it runs from visual studio. Otherwise I want it to run normally.

Here is a quick tip I found. I’m not sure if there is another way to do this but this works fine.

if (AppDomain.CurrentDomain.FriendlyName.Contains(".vshost.")) Console.ReadLine();

If you add this line in a console app, it will wait for a enter only if you un it from visual studio.

Interresting theory

Theosophy Oriented Programming

http://www.codeproject.com/useritems/TOP.asp

Tired of stepping through properties while you debug?

If you are tired of stepping through every properties in your code while you are debugging it here are some cool things you can do



Add a DebuggerHidden attribute.



This attribute applies to Properties, Methods and Constructors. So you can do this:






Add a DebuggerStepThrough attribute.

This attribute applies to Methods, Constructors, Structs and Classes. You can use it on a single property but if you have a simple DO (Data Object) you can mark it so the debugger will step through it.


Of course you can also use the entire assembly in release mode.

Source Download: http://www.docdotnet.com/portal/LinkClick.aspx?link=TestSkipDebug.zip&tabid=129&mid=459

Have fun.

Getting access to Settings in another project

One of the new cool features of Visual Studio 2005 is the new property editor. With this property editor you can easily add setting to your application. But ther is a problem the way its impelemented. Let me explain you why.

Usually the settings are specific to a project. When you add a setting in a project a special custom tool associate with the setting file generates a new class which you can use to access it. What is good about this class is it's strong typed. But behind the scene it's just getting a key from an xml file. This generated class is set as "internal sealed". This prevent from beeing accessed from any other assembly. What if you want to centralize where you edit these settings.

After many attempt to expose it I found a quick an easy way to do it. Let's say we have 2 project in our solution: an Engine and a WinApp. Each have settings but we want them to be editable from WinApp. Here is what it look like.




If you want to get access to Engine settings here th trick: Add a link file.

The link file will be compiled as part as you WinApp project. The setting class will still be internal and sealed but to WinApp project instead of Engine.

Here is the final result:


Notice that I addes a foler with the same name as my Engine project. This will be helpfull if you want to add settings from many projects.

With this in place you can access you engine setting the way from you engine class as from your WinApp class. You may omit the “Engine” part from your engine class because you should be in the same namespace. Here is what it should look like:

namespace WinApp
{
    public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();
        }

        public void AccessConfig()
        {
            Engine.Properties.Settings.Default.EngineSetting = "test";
        }
    }
}

Editing a password in a PropertyGrid control

Sometimes, when something is too simple, you can spend hours to find out the solution. That happened to me yesterday as I was looking for a way to edit a password in a PropertyGrid control. As you should know, the PropertyGrid control can be customized by adding attributes on object's property you want to edit. One of this attribute is "Editor". With this attribute you can define a designer class that inherits from UITypeEditor to implement your own way to edit the value of a field in the property grid. I made some research on internet to find if somebody had build a special editor for password. No luck. Every time I was looking for page with "UITypeEditor and Password" I found many pages talking about UITypeEditor only. These pages were found because they all contain a "Forgot your password" link in it. Then I tied to search on Code Search. Here I found some interesting code that lead me to Enterprise Library, but it turns out to be a dead-end. Finally I used Reflector to search for "Password". This is where I found that simple attribute called "PasswordPropertyTextAttribute". So the solution was only to add this attribute to my password property and that's it!