Joe Mayo

If you search for AG_E_PARSER_BAD_TYPE, you’ll find many entries going back to early Betas of Silverlight, which may or may not be applicable today. When I received this error, my search led me to Bill Kratochvil’s blog entry, AG_E_PARSER_BAD_TYPE Adding Silverlight Toolkit control to module.

In my particular problem, I was using Prism and my project with Shell.xaml (Project A) referenced another project module (Project B), which referenced two utility libraries (Project C and Project D). The occurred during the call to InitializeComponent() in a View in Project C. The line number and column in the exception message specified code in the View XAML that referred to an object in Project D.  Going back to Project A, where Shell.xaml resides, I observed that Project A referenced Project B and Project C, but not Project D.  I fixed the problem by adding a reference from Project A to Project D.

So, adding to Bill’s observation, it appears that this problem can be solved by locating the project of the object in the XAML where the error occurs (Project D) and ensuring that the project containing Shell.xaml (Project A) has a reference to Project D. 

The combination of several new features to C# 4.0 result in a better development experience than years before.  Taking optional parameters, named parameters, and the dynamic type, much of the drudgery is gone.  In this post, I’ll explain what I mean.  You’ll see two different samples.  In the first sample, you’ll see how C# 3.0 and earlier perform COM Interop with Excel.  The second example will demonstrate how the new features of C# 4.0 improve the code, making it easier to read and write.

Previous C# 4.0 Blog Posts

If you are unfamiliar with some of the concepts used in this article, you can read my previous posts on the new features of C# 4.0:

• New Features of C# 4.0
• Optional Parameters in C# 4.0
• Named Parameters in C# 4.0
• Dynamic Lookup in C# 4.0

COM Interop with MS-Excel for C# 3.0 and earlier

In C# 3.0 and earlier, we needed to engage in various acrobatics to communicate across the COM Interop layer.  Introduction of PIAs were a welcome improvement, but we still needed more help from the tools.  This example won’t cover every conceivable issue, but will highlight a couple welcome new enhancements that are very helpful: easier type conversions and optional parameters.  Here’s a C# 3.0 example of automating an Excel app that creates a couple worksheets and populates the cells in those worksheets with data:

private static void ExecuteInteropOld()
{
    var excelApp = new Excel.ApplicationClass();

    excelApp.Visible = true;

    var wkBook = excelApp.Workbooks.Add(Missing.Value);
    var wkSheetData = (Excel.Worksheet)wkBook.ActiveSheet;

    wkSheetData.Cells[1, 1] = "Name";
    wkSheetData.Cells[1, 2] = "Email";

    var data = new string[,]
    {
        {"Joe Mayo", "jmayo@mayosoftware.com"},
        {"Jane Doe", "jdoe@smith.com"}
    };

    var dataRange = wkSheetData.get_Range("A2", "B3");
    dataRange.Value2 = data;

    var wkSheetEnd = (Excel.Worksheet)wkBook.Worksheets.Add(
        Missing.Value, wkSheetData, Missing.Value, Missing.Value);

    wkSheetEnd.Cells[2, 2] = "Second Sheet";

    wkBook.SaveAs(
        "myfile.xls", Missing.Value, Missing.Value,
        Missing.Value, Missing.Value, Missing.Value,
        Excel.XlSaveAsAccessMode.xlShared, Missing.Value, Missing.Value,
        Missing.Value, Missing.Value, Missing.Value);
}

There are a couple places above where explicit conversions are required. The wkBook.ActiveSheet returns type object and the wkBook.WorkSheets.Add method returns type object also.  Another annoyance is the required use of Missing.Value for any optional parameters in method calls, such as excelApp.Workbooks.Add, wkBook.Worksheets.Add, and wkBook.SaveAs.  C# 4.0 improves upon this code.

Performing COM Interop with C# 4.0

Because C# 4.0 has dynamic types and optional parameters, you’ll see the annoyances from the previous example disappear.  In the following example, you’ll see how Missing.Value is no longer required and that you don’t need to perform explicit conversion of object types:

private static void ExecuteInteropNew()
{
    var excelApp = new Excel.ApplicationClass();
    excelApp.Visible = true;

    dynamic wkBook = excelApp.Workbooks.Add();
    Excel.Worksheet wkSheetData = wkBook.ActiveSheet;

    wkSheetData.Cells[1, 1] = "Name";
    wkSheetData.Cells[1, 2] = "Email";

    var data = new string[,]
    {
        {"Joe Mayo", "jmayo@mayosoftware.com"},
        {"Jane Doe", "jdoe@smith.com"}
    };

    var dataRange = wkSheetData.get_Range("A2", "B3");
    dataRange.Value2 = data;

    Excel.Worksheet wkSheetEnd =
        wkBook.Worksheets.Add(After: wkSheetData);

    wkSheetEnd.Cells[2, 2] = "Second Sheet";

    wkBook.SaveAs(
        "myfile.xls",
        AccessMode: Excel.XlSaveAsAccessMode.xlShared);
}

On the 3rd line of the application above, you can see dynamic types and optional parameters used right away:

   dynamic wkBook = excelApp.Workbooks.Add();

Now, we truly have support for optional parameters, because the Missing.Value is no longer required. Looking through the code, you can see that wkBook.Worksheets.Add and wkBook.SaveAs no longer require the Missing.Value placeholder.

The other aspect of the previous statement is that although Add returns a WorkBook, the return value is assigned to a variable of type dynamic.  According to the C# 4.0 specs, the dynamic type allows us to “suspend belief” until runtime for operations performed on dynamic objects.  That means we can “do things” to wkBook at compile time without explicit conversions or reflection.  This capability of dynamic types, to “do things” to an object is illustrated in the next statement that references the active worksheet:

    Excel.Worksheet wkSheetData = wkBook.ActiveSheet;

In the C# 3.0 example, you needed a cast operator to convert ActiveSheet from type object to type Worksheet.  In the code above, the cast operator is no longer required because wkBook is dynamic and the compiler trusts that you know what you’re doing. Of course, the type check will occur at runtime, which is the intrinsic behavior of a dynamic type, but your code becomes easier to work with because you can directly call the type members that you know exist without adding the extra syntax for the cast operator.  Looking through the code, you can see that wkBook.Worksheets.Add doesn’t require the cast operator either.

Another point I’d like to demonstrate is named parameters, as used in the following call to SaveAs:

    wkBook.SaveAs(
        "myfile.xls",
        AccessMode: Excel.XlSaveAsAccessMode.xlShared);

The named parameter, AccessMode, works hand-in-hand with the C# 4.0 optional parameters feature. Because all of the other parameters were optional, it was convenient to explicitly specify which parameter that the Excel.XlSaveAsAccessMode.xlShared applied to.  In this example, naming the parameter wasn’t required because there is only one parameter of enum type Excel.XLSaveAsAccessMode.  However, if the parameter type had been declared across multiple parameters in the type definition, the name would have been required.

If you’ve ever opened the Visual Studio Entity Designer and spent more than a few seconds searching for a specific entity, you’ll quickly wonder if there must be a better way to do this.  Fortunately there is, through the Model Browser.  Finding the specific entity is only a few clicks away:

1. Open the Model browser.  You can select View > Other Windows > Model Browser:

2. When you see the Model Browser window, open the Conceptual Entity Model, which often has the “Model” suffix if you created the model with the default naming scheme.  In this example, I’m using the Northwind database, which is named NORTHWINDModel. Then open the Entity Types branch and you’ll see something like this:

3. To find the Customer entity, right-click on the Customer entity in the Model Browser and select Show in Designer, like this:

4. The designer automatically centers on your entity.

Got to looking at the Laconica API and noticed that they built a Twitter compatible API.  This got me thinking that LINQ to Twitter might work with Laconica.  So, I pointed LINQ to Twitter at http://jtweeter.com and fired it up:

var twitterCtx = new TwitterContext(userName, password, "http://jtweeter.com/api/", "http://search.twitter.com/");

var publicTweets =
    from tweet in twitterCtx.Status
    where tweet.Type == StatusType.Public
    select tweet;

publicTweets.ToList().ForEach(
    tweet => Console.WriteLine(
        "User Name: {0}, Tweet: {1}",
        tweet.User.Name,
        tweet.Text));

And Success!

The buzz is on for a release date for Silverlight 3.  Pulling info from Silverlight.net Forums, ScottGu’s Linked .NET User Group presentation, and TweetSphere, it looks like we’ll see something around July 10th.

Delphi Prism that is.  Since Delphi Prism supports LINQ, I wondered if LINQ to Twitter would work with it.  It broke on my first try because the enum parameters were being parsed differently than in C#.  So, I fixed this and checked in the new fix: http://linqtotwitter.codeplex.com/SourceControl/ListDownloadableCommits.aspx.  Be sure to grab ChangeSet #53131 or later.  Here's a small demo application:

namespace TwitterTest;
 
interface
 
uses
  System.Linq,
  LinqToTwitter;

type
  TwitterTestClass = class
  public
    class method Main; 
  end;

implementation

class method TwitterTestClass.Main;
begin

  var TwitterCtx : LinqToTwitter.TwitterContext := 
    new LinqToTwitter.TwitterContext;

  var Tweets :=
    from tweet in TwitterCtx.Status
    where tweet.Type = StatusType.Public
    select tweet;

  for tweet : Status in Tweets do begin
     System.Console.WriteLine(
        "User Name: {0}, Tweet: {1}",
            Tweet.User.Name,
            Tweet.Text);
  end;

end;
 
end.

Now my Delphi friends have an easy way to program Twitter applications.

IE8 has a feature called accelerators that allows you to highlight screen artifacts and do things to them.  One of the neat features that I used today was the translator accelerator, shown in the following image:

As you can see, this was on Twitter.  I highlighted the tweet, which showed the accelerator icon.  Then I picked Translate with Live Search, selected the from/to languages, and viewed the translation.

Another step in making the world a smaller and friendlier place to be.

I’m building a data model for a pretty good sized database.  I’ve used the SQL Server data designer in the past and that has been useful. You get a nice visual on tables and relationships and can build different views.  For this job, I wanted something simple where I could communicate the data model, have documentation, and make quick changes.  SQL Server data diagrams are the actual database as opposed to the abstraction you get when modeling, print out very poorly, and are slow as a dog to do anything with.  So, I took a look at Visio.

I’ve used the Visio entity model designer before, but it just didn’t click with me.  Maybe it was something I wasn’t used to or maybe I preferred having the larger workspace of the SQL Server designer; I don’t know.  However, this go round, Visio is working quite well.  It lets me model at a higher level of abstraction, concentrating on properly capturing data requirements without too much focus on detailed design. Since it’s page based, it will print out nicely, which is well suited to what I want.  Another big advantage is that working with Visio is remarkably quick.  Drag-and-drop is quick, naming is easy, and adding fields is a simple matter of clicking a tab and everything I care about for defining a field is on one line, including field description.  Associations are quick drag-and-drop and the FK/PK relationship is immediately inferred, which is what I want to do most of the time anyway.  Cool stuff that Visio; now if I could just figure out how to push my model into SQL Server real quick…

Something interesting happened today in Twitter.  It started when someone was reading the C# Tutorial.  At the same time, I was updating Lesson 12, which that person was reading. The site bugged out during the update, but came back to normal. I tweeted the update, which appeared on a Twitter badge that I put on C# Station. The reader saw the tweet on the badge, realized what had just happened to them, and responded to me on Twitter.

Maybe I’m a easily fascinated by shiny things, but this is one of the moments that demonstrates the power of social networking. Whether its a blog, Twitter, or any other Web 2.0 site, the possibilities for enhanced communication and interaction are huge. It’s no wonder why new on-line mediums, such as Twitter, are getting so much attention in the news. Journalists are in the business of communication and they get it as well, if not better, than the rest of us.

Not only did the structs lesson in the C# Tutorial have code smells, but the writing wasn't too fresh either.  Got an email this morning that something in the lesson wasn't quite right, so I took a look.  The result is that I felt a compelling need to rewrite 99% of the lesson. This version incorporates earlier feedback from other people, such as a little more explanation of the differences between class and struct and example code that was closer to best practice.  I think the code is at least not bad practice anymore, but any small example will be limited in accomplishing anything other than the specific goal it is written to achieve.  Anyway, here's the link and I hope people find it useful:

The C# Tutorial @ C# Station - Lesson 12: Structs

A lot of developers jump straight into a project and begin coding.  The boss gives a vague “do this” instruction and the programmer starts writing code, which is fun.  Maybe it continues to be fun until the boss starts bugging for the application to be done.  If they haven’t done so in the beginning, they’ll ask for an estimate of when it will be done.  Of course, they get a vague or incorrect answer back because “do this” is very vague itself.  If the developer is inexperienced and/or is using a new technology, in addition to “do this” requirements, who knows what the end result of the project will be.  Making matters even worse, the boss’ perspective of “do this” is totally different from the developer’s view of “do this”.  A lot of times, the end result will be a failed project, or one survived through heroics.

The result on the companies that write software this way is an incredible waste of money, late deliveries, and lost revenue.  A lot of companies get started with software projects, having no idea what the true cost is.  Many people have used productivity tools like MS-Access, Excel, or some other RAD tool and have been given the false impression that they can build enterprise applications with a few drag-and-drop operations and maybe some VB glue code here and there.  In reality, these applications have no optimizations, proper data definitions, constraints, validations, error checking, or any other QoS considerations.  So, their perception of what a true enterprise application costs is skewed by their own inexperience.  They regard formal requirements/scenarios, architecture, design, test, stabilization, and deployment as non-essential overhead or trivialities they have no time for.  Furthermore, they want to save money any way they can, and they’re often unaware of the consequences.

Solving this problem is a matter of fixing two sides of the equation, which includes both the company and the programmer.  Just like the company relies on proper planning and execution for its core business, it must regard software engineering as an important enabler to the success of their business and invest in a process that facilitates proper development. There are many processes out there, but any business person who has an ounce of education should understand organization, planning, execution, and coordination management functions.  Regardless of what pundits and zealots preach, these management functions translate directly into many software processes.  Rather than just jumping in head first and coding, a developer should have a methodology in mind that they subscribe to for their software development process.  Essentially, all of the processes boil down to some form of requirements, design, coding, testing, and deployment.  Both the developer and boss need to communicate on the process they will use and then make it work, which will go a long way to avoiding the problems described in the first two paragraphs.

Split screen in Visual Studio can be used for various reasons, but it really excels when writing tests.  To split a screen, right click on the Tab in the editor, and select New Horizontal Tab Group.  You can tab vertical too.  To undo the split, right-click on the bottom (or right) tab and select Move to Previous Tab Group. 

The following figure shows a test in the top pane and the method being tested in the bottom pane:

I’ve been doing a lot of manual parsing on Twitter dates with LINQ to Twitter and it kind of bugged me how primitive the implementation was.  Messing around today, I put this together:

var twitterDate = DateTime.ParseExact("Thu Jan 24 22:14:29 -0700 2008", "ddd MMM dd HH:mm:ss %zzzz yyyy", null);

One statement; That’s more like it.