I’m committed to Two Tool Development
I confess. After years of developing with separate debuggers, editors and compilers it was a wondrous thing to have an Integrated development environment in which all three and more were combined. I love Visual Studio. And for the past year or so I imagined that Blend, while wonderful, was a temporary solution until Dev10 (shorthand for Visual Studio 2010) was ready.
Bzzzz. No! But thanks for playing!
After reviewing Dev10 (which is wonderful) and talking with the team, I’m now convinced that while many developers will do all their development in Visual Studio, serious (and certainly advanced) Silverlight programmers will in fact opt to work with two tools indefinitely. It isn’t just that Blend is better suite for some types of work and VS for others; it is that there are real limitations (did I say that?); places where they do not overlap, and won’t any time soon.
For example, and taking this from the perspective of a developer; I’m thrilled that I can now create rows and columns in my grid in VS and that I can drag and drop controls on the design surface. That greatly simplifies the design process and while Blend may have some advantage there, only time will tell whether it is worth switching back and forth to accomplish these goals.
On the other hand, if I want to add animation I have two realistic choices: hand code it in Xaml in Visual Studio (always fun, might be dangerous, maybe tomorrow) or open Blend (where it just keeps getting easier).
Similarly, if I want to template a control (which, interestingly, I want to do more and more, especially as I work more with Data Validation), then once more Blend is not only the tool of choice, it is my only viable alternative: Visual Studio just isn’t designed to make that easy.
Coding In Blend
“Well,” I hear you say, “why go to VS at all? You can code right in Blend, with Intellisense and etc.” Yah, you can. But as my buddy Dave Platt says (I’m cleaning this up) you can have an appendectomy through your mouth; it just takes longer and hurts more. The ability to do bits of coding in Blend is a great convenience, but it wasn’t designed to be a programmer’s environment and there is no comparison between the level of support if offers and the level of support offered in Visual Studio. Not even close. (OK, I owe you a list of specifics, but for now let’s take it as given).
That’s Not A Bug It’s A Feature
It is tempting to be somewhat defensive about this; almost as if this were a step backwards. But on reflection, I think it is actually a great leap forwards. Rather than trying to make VS into an almost adequate designer, the folks who own Visual Studio decided to create a great developer tool. When you need to go beyond that, to take on relatively advanced design problems (such as managing view state and the associated story boards) it makes sense to use a tool that does that for a living.
And since the two tools work on the same project at the same time, with no need to “import” or “export” cycling between them is (nearly) painless.
Caveat: You Can’t Get There From Here (Yet)
While I strongly encourage you to create a machine with VS2010 (on Win7 if you can!) and with Blend 3, please note that as of this writing you can not open a Silverlight 3 project written for .NET 4 with the Blend 3 currently available (remember, we released Blend 3 back in March, years ago in web time). To overcome this horrific limitation <smile>, you need only create a .NET 3.5 application. To do so, create a new solution, click on C# (or VB or Silverlight) and then drop down the framework and select ..Net Framework 3.5 as shown here,
You’re back in business, though you will not for now be able to take advantage of the new .NET 4.0 framework features.
I will be returning to this theme of two-tools quite a bit, but wanted to open the door for discussion right away as I explore the myriad features in Silverlight 3.