All posts for the month February, 2010

I'm a winner!

I won a license to Telerik’s premium collection last night at my local .NET user group meeting. I’m incredibly excited to start playing with their controls — right now WinForms and reporting are of most interest to me, but I can see myself branching out into WPF soon.

I don’t have any Windows-based hosting available to me at the moment, so the ASP.NET controls will just have to wait. It’s just as well. I’m sure the rest will keep me busy for quite a while.

Extension methods in .NET 2.0

Due to the nature of our client base, we still target .NET 2.0 at work. The side-effect being, of course, the inability to use the latest and greatest and sexiest of what C# has to offer these days.

I was setting out to write some static helper methods this morning, and on a lark decided to Google for extension method support. Sometimes the compiler is nice enough to take 3.0 features (such as the var keyword) and translate them into code that’s palatable for .NET 2.0.

Truly, ask and ye shall receive! Success! While in newer versions of the framework, you’d import System.Core.dll to add extension support, all that’s really needed is the definition of the ExtensionAttribute class. This can be added anywhere in your code that targets .NET 2.0:

namespace System.Runtime.CompilerServices
{
    public sealed class ExtensionAttribute : Attribute { }
}

Extensions work like a charm after that.

XamlParseException during application startup

If a WPF application encounters any problems during the creation of the main window, you will be presented with a rather useless System.Windows.Markup.XamlParseException:

“Cannot create instance of ‘Window1’ defined in assembly ‘YourAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null’. Exception has been thrown by the target of an invocation. Error in markup file ‘Window1.xaml’ Line 1 Position 9.”

The inner exception is similarly not giving much information:

{“Exception has been thrown by the target of an invocation.”}

The trick to getting to the root of the problem is simple. There are a couple ways to do so:

Wrap the code in the constructor of the Window in a try/catch block. This will provide you with access to the actual exception and its stack trace.

public MainWindow()
{
    try
    {
        InitializeComponent();

        // other code, if any
    }
    catch(Exception ex)
    {
        // log the exception -- this is the real culprit
    }
}

Open the Exceptions window in Visual Studio (Debug -> Exceptions…) and check the “Common Language Runtime Exceptions” checkbox in the Thrown column. Re-run your application with the debugger attached, and the application will break on the exception that’s getting wrapped in XamlParseException.

1 Comment

by Adam Lear on February 15, 2010 • Permalink

Posted in C#, WPF

Posted by Adam Lear on February 15, 2010

https://annalear.ca/2010/02/15/xamlparseexception-during-application-startup/

Creating a New Application: First Lessons Learned

It may or may not come as a surprise, but writing software is hard. Having spent the last 3 years doing it for a living, I’m finally making time to develop a side project. I don’t have a proper name for it yet, but I don’t think I have to worry about that for quite a while.

I’m struck by how easy it is for me to write code at my job, where all products are in well-known locations and I’m very familiar with the code base. Creating an application from scratch is turning out to be a whole different animal.

I’ve been going back and forth on design decisions, agonizing over which features to start with and how to go about implementing it all together. And the main thing I learned is that writing code right away really is the worst thing to do. I made the mistake of ignoring that rule and paid for it by re-writing the same feature 4 or 5 times.

So below is my list of recently learned through experience things to know about writing a new application.

Lesson 1: Gather All Your Features in One Place

No, “it’s in my head” doesn’t count. Have a piece of paper or a text document that lists every feature you can think of. Then walk away from that list. Come back to it in a bit and read it over again — remove features that aren’t essential at first. Trim it down to the bare minimum that gives you a functional application. It may take a few iterations to get down to a short list of prime features.

Once that list is ready, prioritize core features over fancy “wouldn’t it be cool if…?” ones. And last but not least, think over every feature — what is needed to implement it? Will you need to pull in some third-party frameworks? Are there any particular design considerations or concerns?

Lesson 2: Figure Out All Workflows

For each feature on your short list, write out a detailed workflow. For example, in my application, the user can create new “To Do” items. So I write out that workflow:
1. Click File->New…
2. A dialog comes up where the user sets task parameters and notes.
3a. User clicks Cancel and the dialog is closed, discarding the information.
3b. User clicks OK and a new task is created.

I’d even sketch out the UI for each step, as needed. It helps.

Lesson 3: Write Some Tests!

It may be hard to wrap your head around how it will all fit together. The easiest way to get some progress is to write some unit tests. This will help you figure out what your classes might look like and help you arrive at a more easily usable interface.

Lesson 4: Don’t Settle on First Version of Anything

For each of the above lessons, I’ve found it helps to walk away for a bit and think things over. When you come back, you can look at things with fresh eyes and sometimes see things you missed the first time.

Lesson 5: Do One Thing At a Time

I find that I get distracted a lot while I code. Not by outside things like email or Twitter, but by tangential thoughts or ideas about what I’m doing. I keep thinking “oh, it’ll just take 30 seconds to fix up this one thing over here…” and before I know it, it’s been half an hour and I completely forgot what I was working on in the first place.

It is important to stay on track and on target. Make notes of things you think of along the way and schedule them in later.

Conclusion

It all boils down to staying focused and organized. Charging in keyboard blazing and starting to type out code will only slow you down in the end. It’s best to slow down, take stock of where you are and where you need to be, and form a plan to get there. Then work the plan and enjoy the feeling of productivity and motivation as you check things off and see your work produce tangible results.

Adam Lear