PDC08 Day -2

I’m in Los Angeles for PDC. Now that all the prep work is done, I’m going to to try and get back to regular blogging and I figure that daily reports from PDC is as good a way as any to get started.

I’m in town early for two reasons. We’re doing some last minute dry runs tomorrow afternoon and I wanted to make sure I was in town in case there was any other last minute stuff to do. Additionally, there’s a Code Camp in SoCal this weekend, so I volunteered to do my Pumping Iron talk.

The talk went pretty well – the room was mostly full (though small) and many folks stayed as much as 30 minutes over to ask questions. The Code Camp is being held at USC, my alma mater, so it was kind of strange to be standing in the front of the classroom in Vivian Hall rather than taking notes at the back. I made a trip over to the campus bookstore (thought I kept calling it the ‘company store’) for a new T-shirt for me and some SC gear for the kids.

Hung out most of the day with Mike Vincent whom I’ve gotten to know over the past couple of years thru his IASA and INETA involvement. He’s doing a talk on Dynamic Languages and the DLR tomorrow at Code Camp, so I’m looking forward to that. Also spent time with Chris Smith (F# SDET), Dustin Campbell (VB PM), Charlie Calvert (C# PM) and ran into DonXML as I was heading out.

I headed out early because I’m going up over the hill to Burbank tonight to see some of my old college / LA buddies, drink some beer and watch the SC game. With our early loss to Oregon State, we can’t make the Rose Bowl, much less the BCS Championship, without help. If win out but don’t get help, we’ll still probably get a BCS at-large bid. For a team that’s been in the championship hunt for the past five years, it’s disappointing, but it’s also like “no pressure” – at least for me, an non-obsessive alumni fan. (I typically save my obsession for Capitals hockey, but even that takes a back seat to the presidential election for the next 11 days.)

I forget who said it, but someone said today that “Los Angeles was like paradise 50 years ago”. Truer words were rarely ever said. It’s nice to be on campus and see friends and all that, but I can’t wait to go home. Why does PDC always have to be in LA? Mike? Well, at least it’s not on fire this time.

IronPython 2.0 Release Candidate

I’ve been so busy with last minute PDC prep that I totally missed that my teammates shipped the IronPython 2.0 Release Candidate. Awesome work guys!

If you’re an IPy user, this is your last chance to hammer on the release and raise any issues to our attention before we ship. If you find anything, please file a bug and report it on the mailing list right away. For those who haven’t seen it, Dave from our test team has a handy guide for reporting bugs, including a link to the bug template.

Next step, RTM!

The Fifth Assembly

As I’ve written previously, we’ve had a few challenges recently with name collisions in the DLR. In that post, I described how we had solved – or thought we solved, as it turned out – the problem with ExtensionAttribute name collisions between Microsoft.Scripting.Core.dll and System.dll.

However, as it turns out, having lots of copies of the same type didn’t solve the problem. Since ExtensionAttribute is a known type to the C# 3.0 compiler, it has to choose one of the multiple copies that are in the project. We thought that given a choice, it would favor the System.Core version. However, what folks discovered after we released Beta 5 is that C# 3.0 will choose the first copy of ExtensionAttribute that it finds. So if you have System.Core.dll and IronPython referenced in your project, and you define your own extension methods, the compile fails if the C# 3.0 compiler finds one of the IronPython or DLR private copies of ExtensionAttribute before the public copy in System.Core.

Furthermore, there doesn’t seem to be any way to set the reference order in MSBuild files. I’ve never dug deep into the MSBuild file format, but changing the order of the references in the csproj file didn’t seem to effect the order the references were passed to the C# compiler. I’m guessing we might be able to change this by fiddling with the ResolveAssemblyReference task, but we didn’t want to force low level MSBuild file hacking on our user base.

We looked at a variety of other solutions, including rewriting the IL after compilation to change the namespace of the ExtensionAttribute. However, we had trouble making that solution work and besides, changing the ExtensionAttribute namespace would have broken anyone using the existing DLR or IPy extension methods. So instead, we went with a different solution that we like to refer to as “The Fifth Assembly” around the office.

IPy References

In IronPython 2.0 Beta 5, there were four DLLs that implement IronPython: IronPython.dll, IronPython.Modules.dll, Microsoft.Scripting.dll and Microsoft.Scripting.Core.dll. In our RC1 release, we’ve added “The Fifth Assembly”: Microsoft.Scripting.ExtensionAttribute.dll. As you might guess from its name, it has only a single public type: ExtensionAttribute. By having ExtensionAttribute in its own dedicated assembly, we can avoid the type collision at compile time by not referencing both System.Core.dll and Microsoft.Scripting.ExtensionAttribute.dll in the same project.

In IronPython, we reference the ExtensionAttribute assembly because we use the C# 3.0 complier but IPy has to be able to run on .NET Framework 2.0 SP1.

However, projects that embed IronPython in a .NET 3.5 project (aka C# 3.0 or VB 9.0) will reference System.Core instead. The only reason why you would explicitly use the ExtensionAttribute assembly was that if you, like us, wanted to build your app with .NET 3.5, use extension methods but still be compatible with .NET 2.0 SP1. We’re guessing there aren’t many of our customers doing that, but if you are, explicitly referencing ExtensionAttribute will work just as it does for compiling IronPython itself.

It’s important to remember two things about the Fifth Assembly:

  1. Never reference System.Core and Microsoft.Scripting.ExtensionAttribute in the same project.
  2. Always deploy Microsoft.Scripting.ExtensionAttribute.dll as part of any solution that embeds IronPython (or IronRuby or vanilla DLR for that matter), even if you don’t reference it explicitly within your project.

This change is public in the source code as of change set 42076 and will also be in the nearly-ready RC1 release of IronPython 2.0. If you’ve got any questions or <shudder> find any more issues with this solution, please let us know right away.

The PDC Prep Death March – It’s Almost Over

So it’s been just over a month since my last post, and I think it’s safe to say it’s been one of the busiest of my career to date. If you’ve been following my Twitter stream, you already know that I’ve spent the last two weeks in PDC dry runs – we went thru almost every session in the track, reviewing content and giving feedback to the speakers. Some were very good (as I twittered at the time, Ed Pinto’sBuilding WCF Services with WF blew my mind). Others, needed more work, but I think will be great by PDC. I got into several disagreements about the best way to present content, had to raise my voice once, and called some speakers “a little creepy”. (No, I’m not telling you which sessions those were.)

After 9 days of dry runs, I spent Friday with Jason Zander, General Manager for Visual Studio, again reviewing almost all the decks with him and some marketing folks. Frankly, spending that much time with my boss’s boss’s boss’s boss is a bit intimidating, but Jason’s been great and I’m guessing the visibility will be great for my career. I mean, come review time, he won’t be saying “Harry who?” I’ve also gotten to meet people from far and wide across my division, which has been great since I’m still new over here.

Unfortunately,  I can’t talk much about what I’ve seen, since as you know most of it is new and being revealed at PDC for the first time publicly. For example, I can tell you Ed’s talk was frakking awesome, but I can’t tell you why I think it’s frakking awesome, yet. But I’m queuing up some posts now that I will publish later once the sessions are public.

Tomorrow, I’m back to my “day job” as the IronPython PM. My teammates have been soldering on in my absence – the one time I was in my office in the past two weeks I joked that no one would recognize me since I’ve been gone so long. We’re coming up on the final release of IronPython 2.0, and my exclusive focus on PDC has left me a mountain of work to do here in the final stretch.

In addition to my teammates, I need to give a quick shout out to Shoshanna Budzianowski and Mike Swanson, without whom I’m not sure I would have survived the past two weeks. Mike is the PDC content owner, so as hard as the past two weeks have been for me, I’m sure they’re worse for him. Shoshanna is the track owner for the “Tools and Languages” track (that’s what the TL in the session codes stands for) and I’ve been the main representative for the VS group in the track. I don’t know if she’s ever done something like PDC before, but she’s awesome.

I leave Friday for southern California. I’m going down early to see a few friends and to do my Pumping Iron talk at the SoCal Code Camp next Saturday. That should be fun since it’s being held at my alma mater. Then Monday starts PDC proper. If you’re going to PDC, some find me in the PDC Lounges. I’ll be spending the vast majority of my time there, since I’ve seen all the content in my track already!