“Platform mismatch. You cannot run PostSharp on a 64-bit application from a 32-bit operating system.”

It was obvious that PostSharp was trying to run it’s post processor in x86 mode because my OS is 64-bit and the project is targeting x64 only. The question was “how do I tell PostSharp to work in x64 mode?”. The answer to resolving this issue is pretty easy because the developers at SharpCrafters have come through once again with great tooling for their product. You simply need to go into the project properties and click on the PostSharp tab, then set the “Processor Architecture” to x64. After that, you’re good to go.

What else can you do in here? Well you can also enable/disable PostSharp, enable/disable support for obfuscation and pass in additional properties to PostSharp just to name a few.

If you don’t have the latest version of PostSharp, grab it from PostSharp 2.1 and if you’re new to AOP or PostSharp, have a look at PostSharp Principals to quickly get to speed with PostSharp.

I saw a post stating that DataTable.Select() is actually a write operation so it isn’t thread safe and requires a lock. I don’t see anything on MSDN about this. So I got to thinking and that’s when I opened up dotPeek. What did I find?

DataTable.NewRow() is not thread safe! The point of this method is to create a new row with the same schema as the table. According to MSDN you have to then add that row to the table’s DataRowCollection, it is not automatically added to the row collection when calling NewRow(). This, for the most part, is a read operation which would be thread safe. BUT, at one point in the internals, a call to NewRow(int) is made which creates the new record object, then sets that record to a class scoped field before passing it along to a DataRowBuilder. This is where it is no longer thread safe.

I was seeing so many problems because I was using NewRow() in a parallel loop and data was being corrupted at the end. This was why. To combat this, I generated a cache of new rows before the parallel loop, in a ConcurrentBag<DataRow> and then use a TryTake() inside of the loop. No more problems.

My project breaks up operations that need to be performed on a DataTable into groups that can be executed concurrently. In total that are about 15 groups each with 2-5 concurrent processes. Each process works with certain columns on a DataRow but still, the DataTable can’t handle more than one change request at a time or it just has a stroke. It’s very annoying. I could easily combat this by using POCOs instead of DataTables but it isn’t an option. So how do I do it? Using what I call the Change Request pattern.

The concept is simple, there are operations reading and making changes to each row in the DataTable. Usually data correction, number crunching, etc. Instead of writing the new value back to the DataColumn, it queues up the change in a thread safe collection using a POCO to describe what has to change. When the operations in the group have finished, the changes are processed one-by-one in a thread safe manner.

private void DoWork(DataTable table)
{
    var chgcrd = new ChangeCoordinator(table);
   
    Task t1 = Task.Factory.StartNew(new Action(() => { UpdateColumn1(table, chgcrd); }));
    Task t2 = Task.Factory.StartNew(new Action(() => { UpdateColumn2(table, chgcrd); }));

    Task.WaitAll(t1, t2);

    chgcrd.ProcessChanges();
}

private void UpdateColumn2(DataTable table, ChangeCoordinator changes)
{
    Parallel.For(0, table.Rows.Count, new Action<int>((i) =>
    {
        int oldValue = table.Rows[i].Field<int>("column2");
        int newValue = oldValue * 5;
        long rowId = table.Rows[i].Field<long>("id");

        changes.ScheduleChange(new ChangeRequest(rowId, "column2", newValue));
    }));
}

private void UpdateColumn1(DataTable table, ChangeCoordinator changes)
{
    Parallel.For(0, table.Rows.Count, new Action<int>((i) =>
    {
        int oldValue = table.Rows[i].Field<int>("column1");
        int newValue = oldValue * 2;
        long rowId = table.Rows[i].Field<long>("id");

        changes.ScheduleChange(new ChangeRequest(rowId, "column1", newValue));                
    }));
}

public class ChangeRequest
{
    public long ID { get; set; }
    public string Column { get; set; }
    public object Value { get; set; }

    public ChangeRequest(long id, string column, object value)
    {
        this.ID = id;
        this.Column = column;
        this.Value = value;
    }
}

public class ChangeCoordinator
{  
    public ChangeCoordinator(DataTable table) 
    {
        _table = table;
    }

    private ConcurrentBag<ChangeRequest> _changes = new ConcurrentBag<ChangeRequest>();
    private DataTable _table;

    public void ScheduleChange(ChangeRequest request)
    {
        _changes.Add(request);
    }

    public void ProcessChanges()
    {
        ChangeRequest cr;
            
        while(_changes.TryTake(out cr)) 
        {
            var row = _table.Rows.Find(cr.ID);
            if (row == null) { continue; }

            row[cr.Column] = cr.Value;
        }

        _table.AcceptChanges();            
    }
}

The code is a dumbed down version of what I’ve implemented, just to show the basic concept. The applications are numerous but I chose to use the DataTable example because it’s a thorn in my side at the moment.

Because I’m working with many disparate DataTables and the join predicates are complex it just isn’t feasible (performance wise) to use DataRelation. To get a working prototype I decided to just use nested loops to find matching DataRows but I’ve found that nested loops when using the TPL results in poor performance and is generally a bad idea when working with large item sets anyway.

Normally I would build a HashTable and create a key from each row based on the columns in the predicate, then use that to match rows with a single loop. However, when using parallel loops, one has to take care to avoid concurrency/multi-threading issues that arise with non thread safe collections. Dictionary<K,V> is normally satisfactory when using them, but they are not thread safe. ConcurrentDictionary<K,V> would seem like an obvious candidate to replace the normal dictionary, but it buckles under the pressure. Memory consumption goes through the roof even for simple, small data processing and performance takes a serious hit.

Another issue with my row key by column approach is that the code has to be written each time and normally I use string concatenation for the keys. Instead, I wanted a nice way to build an index that I can easily query, but I also wanted a generic solution so any key could be used.

I went with the following method

public static Dictionary<TKey, List<DataRow>> BuildIndex<TKey>(this DataTable source, Func<DataRow, TKey> processRow)
{
    ConcurrentBag<Index<TKey, DataRow>> indexBag = new ConcurrentBag<Index<TKey, DataRow>>();

    Parallel.For(0, source.Rows.Count, new Action<int>((i) =>
        {
            indexBag.Add(new Index<TKey, DataRow>()
            {
                Key = processRow(source.Rows[i]),
                Row = source.Rows[i]
            });

        }));

    var result = (from i in indexBag
                    group i by i.Key into g
                    select g
                        ).ToDictionary(c => c.Key, d => d.Select(e=>e.Row).ToList() );

    return result;
}

private class Index<TKey, URow>
{
    public TKey Key { get; set; }
    public URow Row { get; set; }
}

This method  takes in a generic type TKey to define the index key and then requires a predicate to build the key from each row. The performance of this is excellent. The generic Index model is simply a nice way to organize the keys as things are being built. I chose to return a dictionary because I’m satisfied with the performance and functionality and since it’s only being used for reading and not writing, we don’t need a thread safe collection. I could have easily went with a IEnumerable<Index<TKey,URow>> but why bother?

Since this ends up as an extension method, using it is pretty simple.

private void Loop(DataTable table1, DataTable table2)
{
    //Build index for table2
    var idx = table2.BuildIndex<Tuple<int, long, int>>((dr) =>
    {
        return new Tuple<int, long, int>(
            dr.Field<int>("userid"),
            dr.Field<long>("orderid"),
            dr.Field<int>("domainid"));
    });

    //Loop over table1
    Parallel.For(0, table1.Rows.Count, new Action<int>((i) =>
    {
        var rowKey = new Tuple<int, long, int>(
            table1.Rows[i].Field<int>("userid"),
            table1.Rows[i].Field<long>("orderid"),
            table1.Rows[i].Field<int>("domainid"));

        if (idx.ContainsKey(rowKey))
        {
            //Exists
        }
        else
        {
            //Doesn't exist
        }
    }));
}

private void Join(DataTable table1, DataTable table2)
{
    //Build index for table1
    var idx1 = table1.BuildIndex<Tuple<int, long, int>>((dr) =>
    {
        return new Tuple<int, long, int>(
            dr.Field<int>("userid"),
            dr.Field<long>("orderid"),
            dr.Field<int>("domainid"));
    });

    //Build index for table2
    var idx2 = table2.BuildIndex<Tuple<int, long, int>>((dr) =>
    {
        return new Tuple<int, long, int>(
            dr.Field<int>("userid"),
            dr.Field<long>("orderid"),
            dr.Field<int>("domainid"));
    });

    //Do a join
    var joined = from i in idx1
                    join j in idx2 on i.Key equals j.Key
                    select new { Key = i.Key, t1Rows = i.Value, t2Rows = j.Value };

}

Tuples are great to use as keys because they’re immutable and have a smaller footprint than strings (generally speaking).

Conclusion: If I could use POCOs instead of DataTables I certainly would but for now I do what I can. I find the indexing method I’ve come up with a great way to work around performance and threading issues (even when only reading) of DataTables.

I’m interested in hearing your thoughts.

T4 Templates on PluralSight.com

This course introduces T4, Microsoft’s code generation tool that comes with Visual Studio. The Text Template Transformation Toolkit dynamically produces text of any type and is used for code and document generation.

Discover how to reduce development time, bugs and maintenance by building reusable templates. This course covers T4 template building blocks, extending templates with custom functionality and debugging the template execution process.

MVC and Entity Framework, among others, can be customized and extended through T4 templates. It also covers, how to customize MVC controllers using the default templates and the MVCScaffolding package, and customizing entities by adding validation attributes.

Dustin tops it all off with real world uses of T4 including generating, and automatically synchronizing, code based on external resources, and combining T4 with other technologies to produce powerful templates.

The Evil API

I was working with an API recently that had me using ILSpy to figure anything out. At some point I needed to make use of some code while inheriting a class and overriding a virtual method. So I copied out some code from ILSpy into Visual Studio when I realized that an important method call was broken because that method was internal only. DOH! Due to reasons I won’t explain, I didn’t actually modify the assembly, I just went another way, but if I could have I would have just exposed the method.

Here is our own little evil API

namespace Example.API
{
    public class Calculator
    {
        public int ProcessValue(int x)
        {
            return SuperSpecialCalculation(x, x);
        }

        internal int SuperSpecialCalculation(int x, int y)
        {
            return x + y;
        }

    }
}

Two methods, a public and an internal. We need access to the internal!

The Apsect and Provider

I’m sure there are better ways, but I decided to just introduce a public method using the same signature as the internal method and it will just act as a wrapper. So we need an aspect that imports the expected internal method (target) and introduces our wrapper method. Then we need a provider to tell PostSharp where to apply our aspect. For more information on aspect providers, see PostSharp Principals day 12 & day 13. For more information on introduction, see PostSharp Principals day 13 & day 14.

namespace InternalToPublic
{
    //Aspect Provider
    public class AspectProvider : IAspectProvider
    {
        public IEnumerable<AspectInstance> ProvideAspects(object targetElement)
        {
            List<AspectInstance> targets = new List<AspectInstance>();

            var targetType = ((Assembly)targetElement).GetTypes().FirstOrDefault(c => c.Name.Equals("Calculator"));

            if (targetType == null) { return targets; }

            targets.Add(new AspectInstance(targetType, new ExposeSuperSpecialCalculation()));

            return targets;
        }

    }

    //Aspect
    [Serializable]
    public class ExposeSuperSpecialCalculation : InstanceLevelAspect
    {
        [ImportMember("SuperSpecialCalculation", IsRequired = true, Order = ImportMemberOrder.BeforeIntroductions)]
        public Func<int, int, int> InternalMethod;

        [IntroduceMember]
        public int SuperSpecialCalculationPublic(int x, int y)
        {
            return InternalMethod(x, y);
        }
    }
}

Modify!

Just as in the previous post, we run a batch file to do the modifications to the assembly.

@"C:\Program Files (x86)\PostSharp 2.1\Release\postsharp.4.0-x86-cil.exe" "Example.API.dll" /p:AspectProviders=InternalToPublic.AspectProvider,InternalToPublic /p:Output=output\Example.API.dll
@copy /y InternalToPublic.dll .\Output
@copy /y PostSharp.dll .\Output
@pause

Test

Now we just need to make sure it’s all working. Create a new project and reference the modified Example.API.dll, InternalToPublic.dll and PostSharp.dll.

namespace Example.TestApp
{
    class Program
    {
        static void Main(string[] args)
        {
            Example.API.Calculator c = new API.Calculator();
            Console.WriteLine(c.ProcessValue(10));
            Console.WriteLine(c.SuperSpecialCalculationPublic(10, 20));
            Console.ReadKey();
        }
    }
}

The output is as expected

20
30

Example

If you compile this code and step through it, the args parameter will be null.

[LogAspect]
class Program
{
    static void Main(string[] args)
    {
        throw new Exception("test exception");
    }
}

[Serializable]
public class LogAspect : OnExceptionAspect
{
    public override void OnException(MethodExecutionArgs args)
    {
        Console.Write("There was an error");
    }
}

So what’s going on? Well if you use ILSpy and look at the compiled result, you’ll see that PostSharp uses optimizations that include ignoring unused properties.

See how the OnException method has been decorated with multiple MethodExecutionAdviceOptimizations flags? The entire list for this aspect is:

MethodExecutionAdviceOptimization(
MethodExecutionAdviceOptimizations.IgnoreGetMethod 
| MethodExecutionAdviceOptimizations.IgnoreSetFlowBehavior
| MethodExecutionAdviceOptimizations.IgnoreGetArguments
| MethodExecutionAdviceOptimizations.IgnoreSetArguments
| MethodExecutionAdviceOptimizations.IgnoreGetInstance 
| MethodExecutionAdviceOptimizations.IgnoreSetInstance
| MethodExecutionAdviceOptimizations.IgnoreGetException 
| MethodExecutionAdviceOptimizations.IgnoreGetReturnValue
| MethodExecutionAdviceOptimizations.IgnoreSetReturnValue 
| MethodExecutionAdviceOptimizations.IgnoreGetMethodExecutionTag
| MethodExecutionAdviceOptimizations.IgnoreSetMethodExecutionTag 
| MethodExecutionAdviceOptimizations.IgnoreEventArgs
)

Notice the IgnoreGetException flag? That’s why it’s null when stepping through the aspect. Change the aspect to

[LogAspect]
class Program
{
    static void Main(string[] args)
    {
        throw new Exception("test exception");
    }
}

[Serializable]
public class LogAspect : OnExceptionAspect
{
    public override void OnException(MethodExecutionArgs args)
    {
        Exception e = args.Exception; //Now we're using Exception so it won't be null
        Console.Write("There was an error");
    }
}

and rebuild. When you step through this time, args is not null and neither is args.Exception.

Looking at ILSpy again, you no longer see the IgnoreGetException flag.

MethodExecutionAdviceOptimization(
MethodExecutionAdviceOptimizations.IgnoreGetMethod
| MethodExecutionAdviceOptimizations.IgnoreSetFlowBehavior
| MethodExecutionAdviceOptimizations.IgnoreGetArguments
| MethodExecutionAdviceOptimizations.IgnoreSetArguments
| MethodExecutionAdviceOptimizations.IgnoreGetInstance
| MethodExecutionAdviceOptimizations.IgnoreSetInstance
| MethodExecutionAdviceOptimizations.IgnoreGetReturnValue
| MethodExecutionAdviceOptimizations.IgnoreSetReturnValue
| MethodExecutionAdviceOptimizations.IgnoreGetMethodExecutionTag
| MethodExecutionAdviceOptimizations.IgnoreSetMethodExecutionTag
)

Answer

So why are the arguments null? Because you’re not using them.

There is undocumented functionality in PostSharp 2.1 (2.1.2.3 or higher) that allows us to apply aspects to assemblies that we don’t have the source code for. I’m going to show you how this works, but first I have state that this functionality is undocumented because it isn’t officially supported by PostSharp. Proceed at your own risk.

Setup

If you do not have PostSharp 2.1.2.3 (at this point it’s CTP 3) then get it and install it. We will create two projects, a console project that we’ll be using as our dummy and a class library that is going to hold our aspect provider. I highly recommend that you read through the PostSharp Principals series if you are not familiar with PostSharp or aspect providers.

We will also have a folder called ‘Lab’ which we’ll store all our needed files in. Create the Lab folder and then create a subfolder under Lab called Output.

Note: I’m targeting .NET 4.0.

Code

The proceeding code is going to be our dummy executable that we will apply aspects to. Go ahead and start a new console project in Visual Studio called DummyApp. No need to reference PostSharp or any other assemblies. Replace the code in Program.cs with the following:

namespace DummyApp
{
    class Program
    {
        static void Main(string[] args)
        {
            ExampleClass ec = new ExampleClass();

            ec.Method1();
            ec.Method2();

            Console.ReadKey();
        }
    }

    public class ExampleClass
    {
        public void Method1()
        {
            Console.WriteLine("Method1()");
        }

        public void Method2()
        {
            Console.WriteLine("Method2()");
        }
    }
}

Build the project and copy DummyApp.exe to the Lab folder.

Now for the aspect provider. Create a new class library project and call it MyProviders. Add a reference to PostSharp. Add a new class file and name it TraceAspect.cs. Add the following code:

[Serializable]
public class SomeTracingAspect : IOnMethodBoundaryAspect
{
    public void OnEntry(MethodExecutionArgs args)
    {
        Console.WriteLine("Entering method: {0}.{1}", args.Method.DeclaringType.Name, args.Method.Name);
    }

    public void OnException(MethodExecutionArgs args)
    {
    }

    public void OnExit(MethodExecutionArgs args)
    {
        Console.WriteLine("Exiting method: {0}.{1}", args.Method.DeclaringType.Name, args.Method.Name);
    }

    public void OnSuccess(MethodExecutionArgs args)
    {
    }

    public void RuntimeInitialize(MethodBase method)
    {
    }

}

Our aspect is nothing special, just an aspect that implements IOnMethodBoundary and we are just adding code to the OnEntry and OnExit advices.

Add another class file and name it TraceAspectProvider.cs then add the following code:

public class TraceAspectProvider : IAspectProvider
{
    readonly SomeTracingAspect aspectToApply = new SomeTracingAspect();

    public IEnumerable ProvideAspects(object targetElement)
    {
        Assembly assembly = (Assembly)targetElement;

        List instances = new List();
        foreach (Type type in assembly.GetTypes())
        {
            ProcessType(type, instances);
        }

        return instances;
    }

    private void ProcessType(Type type, List instances)
    {
        foreach (MethodInfo targetMethod in type.GetMethods(BindingFlags.Instance | BindingFlags.Public | BindingFlags.DeclaredOnly))
        {
            instances.Add(new AspectInstance(targetMethod, aspectToApply));
        }

        foreach (Type nestedType in type.GetNestedTypes())
        {
            ProcessType(nestedType, instances);
        }
    }
}
 

This is how we tell PostSharp what targets to work with and what aspects to apply to those targets. We implement the IAspectProvider interface and satisfy its required ProvideAspects method. PostSharp invokes the ProvideAspects method passing in a System.Reflection.Assembly instance for the target assembly we’re trying to modify. Using reflection, we’ll get all of the types in the target assembly and process each one by calling our ProcessType method.

In the ProcessType method, we again use reflection to discover all of the methods in the given type that are public and not static. For each applicable method we create a new AspectInstance and add it to the instances list that we’ll be giving back to PostSharp for processing. Then we do some recursion to process any nested types.

When we create a new AspectInstance, we’re passing in to the first parameter the System.Reflection.MethodInfo instance we received from GetMethods(). This parameter can take System.Type, most of the System.Reflection types such as FieldInfo, EventInfo etc and also PostSharp.Reflection.LocationInfo. If we were attempting to apply a LocationInterception aspect, we would pass in a System.Reflection.PropertyInfo type for our intended target.

The second parameter requires an instance of IAspect that will be applied to the target. This is where we supply our desired aspect. We’ve declared and instantiated a class member of type SomeTracingAspect for this purpose so we supply this instance to satisfy the parameter.

Build the project and copy the MyProviders.dll and PostSharp.dll to the Lab folder.

Modify!

Now we’re all ready to go. The last step is to actually perform the transformations. To do this we just need to run the PostSharp command line interface with some specific options. I recommend creating a batch file to do this because it could be a lot of typing.

@"C:\Program Files (x86)\PostSharp 2.1\Release\postsharp.4.0-x64-cil.exe" "DummyApp.exe" /p:AspectProviders=MyProviders.TraceAspectProvider,MyProviders /p:Output=output\DummyApp.exe /attach
@copy /y MyProviders.dll .\Output
@copy /y PostSharp.dll .\Output
@pause

Your PostSharp path may vary. You will also need to choose the correct version of PostSharp CIL executable to run. If you’re working with assemblies targeting .NET 3.5 then use the 2.0 version. If you’re working with assemblies targeting .NET 4.0 then use the 4.0 version and of course, choose the appropriate architecture type (x86, x64). For example:

• postsharp.2.0-x86-cil.exe
• postsharp.2.0-x64-cil.exe
• postsharp.4.0-x86-cil.exe
• postsharp.4.0-x64-cil.exe

The first argument we pass in is the path to the target, DummyApp.exe. The target doesn’t have to be an executable, it can be a library (DLL).

Next we tell PostSharp which aspect provider to use. We do this using the /P argument which allows us to set PostSharp properties (Usage: /P:name=value). Of course we want to use the aspect provider we just built so we specify the fully qualified type name followed by a comma then the assembly name.

PostSharp requires an Output to be provided so we use the /P argument again this time setting the ‘Output’ property to our destination. We don’t want to modify the source so we tell PostSharp to put the result in the output folder.

Optionally we can specify the /attach argument which allows us to attach to Visual Studio to step through the provider (in case there are issues).

When we run the batch file, PostSharp goes to work. When it’s done we see that the output folder has a copy of DummyApp.exe. When we run it we see that our aspect has been applied.

Entering method: ExampleClass.Method1
Method1()
Exiting method: ExampleClass.Method1
Entering method: ExampleClass.Method2
Method2()
Exiting method: ExampleClass.Method2

We can also use ILSpy to look at the resulting assembly.

In another post we’ll go over applying an EventInterceptionAspect based aspect and how to setup project build options to automatically run this process.

I’ve been a member of the Inland Empire .NET User’s Group since 2008 but only since July 2010 have I participated in the MVM contest. I spent the entire year speaking at user groups and code camp, attending meetings and helping with setup and tear down, writing book reviews and whatever else I could do to help out the community and earn MVM points. It paid off. I blew away the competition.

So what does it mean to win the Most Valuable Member content? It means recognition, notoriety and a huge bag of loot & swag that equates to a king’s ransom. Thanks to James Johnson, the group’s founder and president, the prize packages awarded to the top three members are nothing less than overwhelming. James has some magic voodoo that he uses to woo the group’s sponsors into generously filling the loot bags and providing a catered meal at a fancy hotel.

In addition to a nicely framed award, the winners received laptop bags with a nicely embroidered Visual Studio logo on them (thanks to Microsoft) that were filled with goods. Since I was the Most Valuable Member, my bag was the heaviest. Here is what was in my bag

Swag

Pens, stickers, t-shirts and thumb drives from the group’s many sponsors including Red-Gate, ComponentOne, DevExpress and Telerik.

Books

I would estimate that I received 200lbs of books from our book sponsors, Wrox, Apress and O`Reilly. Not only did I get a laptop bag full of books, but I was also handed a giant box full of more books (they wouldn’t fit in the bag is what James told me).

Left to right: Ayyappan, Oscar, Myself, James.

In addition to all of those books I also received certificates for 10 books of my choosing from each publisher. That’s an additional 30 books. O`Reilly also provided a 1 year subscription to Safari Books Online.

Total book count: 42

Software

What would a user group be without software to give away? In my bag were countless envelopes each containing a license for a software package from each of the group’s sponsors.

• Red-Gate Developers Bundle
• JetBrains dotTrace
• TechSmith Camtasia Studio
• EmailVerify.net
• PluralSight annual subscription
• DevExpress DXperience Enterprise subscription
• Telerik Ultimate Collection
• SharpCrafters PostSharp Professional License
• Infragistics Net Advantage

If all of that weren’t enough, James had some very nice words to say about me and the other winners.

What an excellent night. Thanks to James for putting it all together and making it happen, year after year!

By Alberto Población

“What comes after the “…For Dummies” book? There is a big gap between the introductory/beginner books and the rest of them. Beginners looking for that next step usually find it to be a steep climb. This book helps to fill that gap.” – Dustin Davis

Amazon: $37.00

I recently received my copy of “.NET Windows Development: Everyday Tips, Tricks & Optimization”. I was pleasantly surprised when I saw how thin it was. There is only about 250 pages which is exactly how I like my tech books. Some readers like the bible style books with 1000+ pages, but this isn’t that type of book.

“.NET Windows Development: Everyday Tips, Tricks & Optimization” is packed with problem/solution/better solution sections with necessary details where required. There is little, if any, fluff or filler in this book and I appreciate that. Reading is time-consuming and I dislike wasting my time on filler. I usually skim over what I think is wasteful material and try to get back to the good stuff, but sometimes I end up missing something.

The book contains seven chapters of which each is dedicated to its own topic. There is no lead-in so you can jump around the chapters in any order you wish. As the title suggests, each chapter contains either tips & tricks for solving some common issues or improving performance or right-to-the-point introductory text of a feature set.

• Accessing Data - this chapter focuses on data access and performance using easy to implement techniques. I especially found the use of SqlBulkCopy helpful.
• New features in Windows 7 – I found this chapter very interesting as it shows how your applications can integrate with all of the new Windows 7 features such as jump lists and icon overlays.
• Using Graphics - This chapter focuses on GDI via the System.Drawing namespace.
• Creative Use of Serialization - This is one of those chapters where beginners will benefit. The author introduces serialization (Xml, Binary, Soap) and when to use each and then dives into the how by exploring some uses for serialization.
• Some Uses for Reflection – Just as the previous chapter, an introduction that wastes no time.
• Various Techniques that Should Be Well Known, But Sometimes Aren’t – Various techniques including encoding.
• A Few Tips for Windows Forms Applications – Various topics concerning Windows Forms. I enjoyed reading about the new Windows 7 dialogs.

Since this book focuses on Windows Forms instead of WPF,it might be considered outdated even though it was written in 2010. On the contrary, I believe this is what gives the book more respectability. Getting to the point without worrying about the latest and greatest is so refreshing. The contents of this book are still relevant to today’s development and just about everyone can find something to take away and apply to their daily work.

The price for the book is a bit steep at $37.00 (from Amazon), but overall I recommend this book especially to beginners who need that next step to be a small one.

Amazon
http://www.amazon.com/NET-Windows-Development-Everyday-Optimization/dp/8493548936/ref=sr_1_1?ie=UTF8&s=books&qid=1307458970&sr=1-1

CampusMVP
http://campusmvp.net/