We’re all spoiled. For years, we’ve been able to drag/drop controls onto a design surface in Visual Studio and then write the code-behind. Traditionally, our world has consisted of these two things–the design surface and the code-behind.
But with WPF and Silverlight, we really have three views: the design surface, the XAML code that defines the visual layout, and the code-behind.
When working on WPF projects then, you typically have a split window where you can work in either the design surface or the XAML code. You can drag controls from the toolbox onto the design surface and the changes are reflected immediately in the XAML. Conversely, you can edit the XAML and see changes on the design surface. It looks like this.
This is beautiful. You can work in the classic drag/drop paradigm to quickly gen up your GUI. And then you can tweak things in the XAML, or the property editor. Life is good.
Silverlight – Something’s Missing!
But there is a bit of a difference when you’re working with Silverlight projects. Take a look at that same split designer view:
Notice the difference? “Preview”, rather than “Design”. You’ll also notice right away that you can’t drag controls onto the design surface. Argh, I can’t live without drag/drop—these are habits that I picked up back in the days of VB3!
Relax. Turns out that you can still drag/drop into the XAML, and your changes will be reflected in the Preview window. The Silverlight designer is different from WPF in that this window is a read-only view of your GUI, rather than a directly-editable designer. The other bad news is that there is no property window when editing Silverlight XAML, whereas there is when you’re working with the XAML in a WPF application.
You can read all about the Silverlight designer and its limitations here: Silverlight Tools for Visual Studio 2008 Designer Support
While this isn’t ideal, it’s workable. Perhaps we’ll see the ability to edit directly on the design-surface in future versions of Visual Studio. Being a newer technology, it’s sensible that Silverlight lags a bit behind WPF in terms of tooling support, in the same way that WPF seems to still lag a bit behind Win Forms.
Sean's Stuff 
Someone should really smack me in the head. The incredibly obvious answer is–don’t edit the GUI in VS2008–do it in Blend. Blend is designed for laying out your GUI, you can do split-view with XAML and the designer and then edit directly on the design surface. There is also a phenomenal property editor.
I’ve just been a Visual Studio developer for too many years. I focus on what’s missing, and temporarily forget that VS really isn’t the best tool for the job at hand. The lesson? Don’t be afraid to use Blend–it should be part of your daily routine, even if you’re a developer rather than a designer. (I’ve said this before).
That said, Visual Studio does need to catch up, tooling-wise. And I’m sure that it will at some point. Until then, however, Blend is the way to go.
Sean,
If you really want me to – I’m willing to smack you upside the head just for the fun of it.
Yep, Blend is the UI awesomeness tool recommended for Silverlight 2.
— Justin
But blend doesn’t support intellisense for the XAML editor. And I do know there are plugins to support it but MS should have made it part of the design
that switching between VS and blend is really annoying. I really preffer to stay with visual studio and have intellisense. I dont like drag and drop and let the designer add tons of code without much control.
Blend is NOT provided with Visual Studio 2008, nor is it provided with an MSDN Pro subscription (which is what I have). I just finished up an MSDN concierge chat confirming this.
Although, the guy I was chatting with insisted that Visual Studio 2008 DOES have drag and drop ability for SilverLight apps and he claimed that he cranked it up and used it while we were chatting. I have a very difficult time believing him though, because MY Visual Studio does NOT do this and EVERYTHING I’ve read and all the SilverLight coding sessions I’ve attended claim there is no visual designer and that you HAVE to use Blend.
So, I’m sitting here have paid for an overpriced MSDN Pro subscription and STILL don’t have the ability to do early 1990’s visual designer drag and drop in a 2009 product!!! :( No SilverLight for me!
This sux… REALLY BADLY!!! This is inexcusable for M$ to not provide a basic visual designer. It is most definitely a game changer.
Yeah, it’s too bad that MS doesn’t provide Blend with EVERY MSDN subs that includes Visual Studio–at least until the tooling for Silverlight improves. One might even argue that the tooling for WPF in VS2008, though supporting drag/drop, is inferior enough, in terms of developing rich WPF apps, that you really need Blend.
That’s sort of a side question/discussion–for simple development teams, where you don’t have an actual designer, do you need/want Blend? Clearly you don’t strictly NEED it, but I’d argue that you should definitely be developing in Blend. And so it would be nice if it was just always available.
I have an MSDN Universal subscription and I definitely do get Blend.
Also note, that VS 2008 does support drag/drop into your XAML code for Silverlight. Then it re-renders the Preview pane to show you the GUI. So not ideal, but at least you’re not having to type XAML.
Does your subscription include beta copies of VS 2010? If so, you could jump to VS2010, which does have full drag-drop support in the designer, for both Silverlight 2 and (also beta until next week) Silverlight 3.
“Although, the guy I was chatting with insisted that Visual Studio 2008 DOES have drag and drop ability for SilverLight apps and he claimed that he cranked it up and used it while we were chatting. I have a very difficult time believing him though, because MY Visual Studio does NOT do this and EVERYTHING I’ve read and all the SilverLight coding sessions I’ve attended claim there is no visual designer and that you HAVE to use Blend.”
Open in designer(right click on xaml file – designer) not thru double click – then you have drag&drop.