I spent last week assisting with a Silverlight training.  What a great experience!  I’ve been writing WPF applications for some time now, but I don’t enter the browser-based world very often.  I was there to focus on the developer side and to assist with student projects.  It was a week well-spent.

Since I’m typically on the developer side, I’m not vey comfortable with Blend.  I can see that XAML development/design is easier in Blend than in Visual Studio, but it’s so different.  Blend is nothing like any developer tool I’ve used before.  The UI controls don’t have any of the typical look-and-feel so it’s a real struggle at first.

On top of that, XAML itself is just so different from VB and C#.  It’s a great benefit though.  By learning XAML you can eliminate the need to write most of the code.  Making a control become disabled based on another checkbox, binding data to business objects, even creating advanced effects like motion and highlighting can be achieved in a strictly declarative sense.  Code ends up being used as glue like it’s supposed to be!

There are plenty of things that you can’t do in XAML, but some of those things can be achieved by using code shims called behaviors or converters (a few other things as well).  You write these once, declare them for XAML consumption, then use them declaratively as needed.

Debugging can be a real problem though.  Figuring out which parent element has an explicit size set when you are working for a dynamic layout, or figuring out where a resource went which was being picked up just fine a minute ago can be difficult.  Crashes can even occur at runtime even though everything is well-formed.  For example, if two timelines (animation definitions) that run at the same time make changes to the same property of an object, it will fail.  This might not be obvious during design-time.

For all that though, it’s worth working through the pain.  I went from being a fair WPF programmer to a pretty good one just from what I learned about Silverlight and Blend  Of course I’m much better prepared for Silverlight development now too!

I’ve had the chance to do some SharePoint development and it’s been an experience for sure!  Specifically, I’ve been trying to write a custom HTTP handler.  This was much more difficult than I expected.  I’m not familiar with the Visual Studio extensions for SharePoint, so I was writing and deploying the code pretty manually.

What I ended up doing, for simplicity, was create the entire source file in a single ashx file.  I don’t even register the handler, so it’s really just invoked like any other URL, using an HTTP GET request.  I’m not sure that needed to be an ashx file, but there are no ASP.NET pieces here so it seems cleaner.  I use the Assembly tag to reference assemblies that I need, then move straight to the using statements, and then to my class definition.  No code-behind – all in the ashx.  Again, I’m not sure that this was needed, but it was easier to manage.  I couldn’t do any debugging, and I was manually deploying.

I copied the file to the c:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\##\TEMPLATE\LAYOUTS, then created a subfolder for my code.  Every time I hit the page, I got a “Runtime Error” message.  I never did find a way to see the underlying error, even with changes to Web.config to turn off custom errors.  The only thing I can think of, is that there is another Web.config file at a different level that overrode those settings since even an iisreset didn’t get things working.  Once I got compilation working though, you’d better believe I had a try/catch surrounding everything so I’d know what was going on.

To reference files in the LAYOUTS folder, I just used http://MYHOST/sites/_layouts/MYFOLDER/MYFILE.ashx.  I discovered that I could link to images, XAP files (for Silverlight) or whatever else for ease of deployment with no document libraries involved.

I wasn’t able to reference custom libraries, but I didn’t have a real need so I didn’t try very hard.  I had considered moving my code in compiled form via a DLL, but I ended up merging it all into the uncompiled ashx file and doing a file copy.

The final step was interacting with the SharePoint instance itself.  The SPContext.Current reference was null.  Even passing in the HttpContext object it failed.  What I ended up doing was just passing in the host name of the machine I was working on.  It’s a pain and would need changing on a new deployment, but it’s a pretty small change, and since it’s the code’s deployed as source, you don’t need to recompile.

In the end, I had what I needed.  I realized, afterwards, some things that would have made things better, but the lack of runtime error support was awful.  I didn’t know if my code failed or if it didn’t even compile – it looked the same either way.  Finally getting the handler in place and doing its job is a wonderful feeling.  Now my next SharePoint experience will have a little more knowledge behind it.