One of The Code Trip sponsors, InnerWorkings, has teamed up to have a coding challenge for developers.  This is open to everyone to participate.  The winner gets an annual subscription to InnerWorkings as well as an XBOX 360 game console.

If you aren't familiar with InnerWorkings, consider this a shameless plug.  I really do believe in their product as it is a unique learning experience from what we traditionally have (i.e., lab manuals with step-by-step instructions).  They have a wide catalog of topics including ASP.NET, WCF, WPF, Silverlight, CSS, etc. for organizations to choose from.  You really need to check them out if you haven't before.

All the details are available on The Code Trip web site recent post.  Head over there for information on InnerWorkings and the information on the contest.

In a previous post, I wrote about some samples of calling various types of services from Silverlight 2.  In the code, I was using constructors in my ASMX and WCF services with specifying a binding type and endpoint address.

It was called out to me that in other demonstrations, people did not use this construct.  While the method I demonstrated works (explicitly specifying the binding and endpoint), in some cases it may not be necessary.  One such case would be if you only have one endpoint and it is basicHttpBinding.

The error in my code/instructions was about changing the binding information in web.config.  The information is correct, however I wasn't clear on when/what you needed to do.  For example, the default information in web.config for the Silverlight project created for you uses wsHttpBinding.  If you add a service reference in your Silverlight project PRIOR to changing that binding information, your generated proxy will require you to specify a binding and endpoint as Silverlight doesn't support wsHttpBinding and it would be trying to use that as a default method.

So the appropriate way is to change the binding type in your web.config FIRST.  Then generate the service reference in your Silverlight application and your proxy code generated will then allow you to new up the service using:

WcfServiceClient wcf = new WcfServiceClient();

for both WCF and ASMX services...which is probably more familiar to most web developers implementing services in their applications.

Again, EITHER way is fine.  Providing no information in the constructor will use the default binding/endpoint information for that service, and if it isn't supported, you'll get a nasty exception.  Whether or not it is best practice to always explicitly call it out in your code is up to you.  I'd argue it is.  In looking at the code above do you know what binding/endpoint is being used at the time of the service call?  No.  You could make some reasonable assumptions (hey, I'm in Silverlight and I know I must use basicHttpBinding), but for maintainability, maybe someone else coming to the code doesn't have the same understanding.

To each his own.  Either way, I hope this clarifies and I've updated my post with the note about this as well.

If you are like me, you probably create a lot of projects in Visual Studio that end up getting thrown away and are intended just to test out a theory you have, double-check yourself when you are going mad because you can't find a bug, testing out something you read on a blog post, whatever.

Most of the projects I create are web projects.  I've started to adopt the "_Delete" mechanism to help me identify what I can truly delete in my folders later.  But is not the point here.  One thing that I do when creating web projects is use the Empty Web Site template:

I choose this template because it is the cleanest...it's actually what it says it is: empty.  It allows me to really isolate things as I'm the one adding things in, not the IDE.  So I usually follow that up with a new WebForm to get an ASP.NET page in there.  I write some code then CTRL+F5 it to run.  The first thing I hit is a build error.  Can you guess what it is?

Here's the thing.  When you choose the Empty Web Site template, you literally get nothing...no web.config, no default pages, no references, nada.  Like I said, it is what it is: empty.  But herein lies the problem.  The WebForm item template doesn't know that.  The WebForm item template is shared with all the web template types, which generally would be fine.  Let's do some digging to find out why I get a build error.

The WebForm item template is located in %ProgramFiles%\Microsoft Visual Studio 9.0\Common7\IDE\ItemTemplates\CSharp\Web\1033\WebForm.zip.  This file contains the WebForm.aspx and code beside templates.  If you look at the CodeBeside.cs template within there you will see this line:

$if$ ($targetframeworkversion$ == 3.5)using System.Linq;

And there is the problem!  When I create a new web site, i'm using the .NET Framework 3.5 setting:

instead of any other target.  It makes sense because I'm doing 3.5 stuff anyway and I don't want to have to change it later.  But the problem is that the WebForm template now thinks that I already have web.config settings for LINQ, a reference, etc. and that is why I can't run...no references to System.Linq assemblies anywhere.

It's quite annoying for me, but I would imagine not most.  In talking with some product team folks, and I concur, people who choose the empty template are usually likely going to know what is up and make whatever changes needed.  Fair enough, but still slightly annoying only because I keep forgetting about it!

So since I find myself removing those using statements a lot, I decided to just change the template.  This, of course, is completely going to get overwritten any update in the future.  But for me, I think it made sense to remove them rather than to assume that I, the developer, will always be using LINQ in my web forms...which I'm not.  I'll choose to add it back in when I need!  So I simply removed the $if$ statements and I'm good to go.  I wish there was a way to say $if$ (3.5 && !empty)using System.Linq, but I'm okay with my minor change for me.

Anyhow, I thought I'd share this useless piece of knowledge as you might have come across it while checking out new development, tinkering with ASP.NET, creating shell Silverlight web hosts, etc.  Hope it helps.

The MountainWest RubyConf 2008 is upon us just 2 weeks away in Salt Lake City, Utah.  Unfortunately I'm not going to be able to be there given my travel with The Code Trip.  IronRuby, however, was able to be a sponsor of this year's conference as a Gold Sponsor.  This sponsorship is one part that enables video production of the conference for afterwards as well as a few other things.  The organizers have done a great job getting great sponsors to make this happen, and IronRuby is grateful to be a part of that.

One thing that was recently released was the Dynamic Silverlight support in Silverlight 2.  This enables Ruby (via IronRuby) to be the language that you can write Silverlight applications with.  I would have loved to be at MountainWest this year to demonstrate this as I think some Ruby developers doing web programming with Rails would find this interesting.  Essentially writing Ruby on the server and Ruby on the client (not Ruby translated to Javascript, but real Ruby).  That end-to-end language implementation I think might be interesting for some developers.  So in case I'm confusing the issue...IronRuby enables a developer to use Ruby as the scripting language in the browser using Silverlight as that bridge in the browser.  The Dynamic Silverlight site has the bits and John Lam's blog has a 3 part quick tutorial of implementation that you can check out.

I've been clamoring to get some Ruby in my Silverlight for a while and hope to post some samples of that scenario of using IronRuby in Silveright and Ruby on Rails on the server...anyone got a scenario that is common that you may want to see?

Our current route on The Code Trip takes us to Boulder, Colorado on March 18 to the Boulder .NET User Group!  I'm really excited about this stop in Boulder, CO as we've managed to get some help from great partners to demonstrate some very cool developer stuff they are working on.

Specifically, Quark and me.dium will be there to talk to the group.  Quark will be showing us some stuff they've been working on for WPF and Silverlight.  me.dium is a company that I met at MIX08 last week that were showing off some great stuff they've done with Internet Explorer 8.  They will be there to show the group some of that stuff and share their experiences working with IE8 early bits.

And, of course, we'll be giving stuff away.  We've got software, Windows Mobile devices, books, and more.  Be sure to show up to participate.  You can view the details of the visit on the Code Trip event section here.

See you in Boulder!!!