| Comments

The first of my Silverlight videos have posted which cover some networking stuff that I’ve been blogging about already.  If you want to see a walk through of things you might have already read, please take a look at them:

There are more coming and I’m interested in hearing your comments so please give them.  If you have suggestions for things that need to be demonstrated to help others (or yourself), please let me know about them as well!

| Comments

I’ve started a dialog with a few of you about getting Silverlight and service integration working, specifically with ASP.NET web services (and even WCF ones).  A few have downloaded some of my samples, but others have started from scratch.  A few have reported getting some interesting errors, ASYNC_blahblah and NotFound errors specifically.  While this was boggling my mind (as I wasn’t getting them), a reader’s comments pointed me along the lines of something…he mentioned “maybe it is because my web service is ASP.NET 2.0 and not 3.5” – of which that shouldn’t be the case, so I went to test that.

The Situation

Most of the samples you are likely seeing (including mine) are implementing web services within the same project that the Silverlight host is implementing.  What I mean to say is probably you are doing File…New…Silverlight Project and then incorporating the web service into the web site project that comes with that template.  If you do so, you probably aren’t running into problems.  Also note that the target framework of that default web site project is .NET 3.5.  This doesn’t make a difference, but I’m just noting it here.

But what if you have an existing service, or you have an existing web site project that you are running in Visual Studio and running into problems…and l think I know why…let’s investigate by doing this step-by-step.

The Web Service

First open an instance of Visual Studio 2008 and choose to create a new ASP.NET Web Service (I’m calling mine ‘FooService’).  Be sure to select .NET Framework 2.0 for this experiment:

Do nothing more to the service.  We’re just going to use the HelloWorld stub for this experiment.  We know we’re going to simulate a cross-domain situation so create a clientaccesspolicy.xml file at the root of this project.  You can use my snippet to do the default public policy quickly if you’d like, it’s wickedly cool and awesomely awesome.  I recommend it ;-).  Moving on… We are done here.  CTRL+F5 this bad boy to start it running (or select Service.asmx and view in browser) – we just need to get the service running.  Make note of the URL, it is likely http://localhost:XXXXX/FooService/Service.asmx where “XXXXX” is the random port assigned by VS.  Just note that URL.  Obviously if you didn’t call yours FooService, then it will be different.

The Silverlight Application

Start another instance of VS2008 and choose File…New…Project…Silverlight Application.  I’m calling mine FooApp.  Now, if you don’t see any of the Silverlight templates, just change the target framework back to .NET Framework 3.5 if you haven’t done so already.  Accept the default for creating the FooApp_Web project for you, we’ll need a host here anyway under HTTP.

Modify nothing in the Page.xaml file but add a service reference to the Silverlight application by right-clicking on the app and choosing ‘Add Service Reference.’  Put the URL of the ASP.NET 2.0 service (from previous step) in the box and click GO.  You should get it discovered and have ‘ServiceReference1’ as the name:

Just keep the lame name because we’re just playing around remember?  Now, go to Page.xaml.cs and add the following code:

public Page()
{
    InitializeComponent();
    Loaded += new RoutedEventHandler(Page_Loaded);
}

void Page_Loaded(object sender, RoutedEventArgs e)
{
    ServiceReference1.ServiceSoapClient proxy = new FooApp.ServiceReference1.ServiceSoapClient();
    proxy.HelloWorldCompleted += new EventHandler<FooApp.ServiceReference1.HelloWorldCompletedEventArgs>(proxy_HelloWorldCompleted);
    proxy.HelloWorldAsync();
}

void proxy_HelloWorldCompleted(object sender, FooApp.ServiceReference1.HelloWorldCompletedEventArgs e)
{
    try
    {
        TextBlock tb = new TextBlock();
        tb.Text = e.Result;
        LayoutRoot.Children.Add(tb);
    }
    catch (Exception ex)
    {
        string wtf = ex.Message;
    }
}

What we are doing here is calling the service (asynchronously of course) and wiring up the completion event to emit a new TextBlock with the result of the web service.  The Page() constructor just adds a Loaded event so we aren’t doing anything in the constructor to the XAML before it is done loading.

Okay, so we are done.  We have our web service with an appropriate clientaccesspolicy.xml file and it is running.  We have our Silverlight application with a service reference to that and proxy code generated.  We are using that proxy code to call the service, and use the result in a new TextBlock in our root layout element.  Sweet.  Put a breakpoint on the exception catch (should be line 37) and hit F5 (choose yes to enable debugging in web.config).

WTF?

Did you get ‘Async_ExceptionOccurred’ like I did?  Sonofa…  Maybe it is because I’m accessing an ASP.NET 2.0 service? No.  Maybe it is because my app is on port YYYY and my service is on port XXXX?  Nope.  Ah, cross-domain issues?  Try again.

Investigating the Problem

Okay, on to figuring out what is going on. 

If you are a web developer and you aren’t using an HTTP sniffing tool, shame on you.  This should be one of your biggest assets when doing web client development like Flash, Silverlight, AJAX, whatever.  For Microsoft developers there are usually 2 tools (both free) that come to the top: Fiddler and Web Development Helper.  I’m a HUGE fan of WebDevHelper (which I just noticed is on CodePlex now, cool Nikhil!) for 2 reasons.  First, it doesn’t require me to change my proxy settings or anything, which is a pain when using Fiddler and the built-in web server with VS because of the dynamic ports it uses.  Second, it is IN THE BROWSER!  I turn it on and I get an explorer bar at the bottom that shows me everything.  Me likey.

Ok, so using WebDevHelper I turn it on and spot the problem:

Spot it?  Remember our service was created on http://localhost:XXXX/FooService/Service.asmx?  If you read my previous post on cross-domain access (and soon a how-do-I video will be posted on this topic), you’ll note that the client access policy file must be at the ROOT of the service site. 

But Tim, it is!

Well, it is according to the file system, but look at the request Silverlight is making.  The problem here is the web development server in VS.  By default it not only grabs a random port, but also serves things up under a virtual directory (i.e., /FooService/Service.asmx instead of /Service.asmx).  So even though we have our policy file in the root, the web server isn’t treating our app like a root.  Notice the web service project properties:

The core problem was that it couldn’t find the clientaccesspolicy.xml file and thus denying the request to the service.

The Solution

For *this* scenario, the solution (or one of them, easiest in my opinion) is to change the service properties and just change the /FooService to “/” only.  This will restart the server for that project (browser to Service.asmx again just to make sure) and will then be operating under http://localhost:XXXX/Service.asmx

The next thing we need to do is go back to our Silverlight application and remove the service reference (as it is now invalid because the endpoint is no longer there).  Just select it and delete.  Choose ‘Add Service Reference’ again and point to the newly updated URL.  No need to change/delete the actual code in Page.xaml.cs because it will stay the same as long as you keep the SericeReference1 default name for this example.

Once you have that, F5 your Silverlight application again and you should see:

If we turn on WebDevHelper again we can see the policy file being requested and found, then the service call allowed through:

Again for this scenario (if you are playing around with Silverlight and just messing with services), this may be one of the issues you are running into.  A lot of the time cross-domain policy files may be the issue and that is why an HTTP sniffer is going to be your best friend to see what request is failing and why.  Even though this is an ASMX sample, if you were testing with a WCF service hosted in an ASPNET web site and running under VS2008 web development server, you'd likely run into the same issue.

Hope this helps!

| Comments

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, , 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.

| Comments

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 web hosts, etc.  Hope it helps.

| Comments

I just saw two links that I simply have to promote as they are very helpful to people doing Silverlight development and one specifically with ASP.NET.

The first is a site on silverlight.net (you should bookmark this site as a resource and subscribe to all the feeds), there is now a Silverlight 2 Beta 1 control sample page, which hosts all the new Silverlight controls on the site.  It shows some different usage of all the controls:

Silverlight Controls Sample

Very cool to see all the controls implemented in one section, play around with them and see different styles in some as well.

The second link is awesome because when I read it I laughed out loud.  The reason wasn't because of the post, but because of a conversation I had with Pete Brown over email.  It is best described simply by showing you the email (privacy information blurred to protect the innocent):

Alas, Cameron Albert created an <asp:Silverlight> override control that enables using the control and supplying a splash screen XAML file and event handler.  This is great!  It enables you to still use the server control with ease but adds some customized functionality so that you can enhance the user load experience.  Essentially it boils down to:

<lg:Silverlight ID="silverlight1" runat="server" Source="~/ClientBin/Perenthia.xap" 
                Version="2.0" Width="800" Height="500" SplashScreenSource="~/Common/Xaml/Splash.xaml" 
                OnSourceDownloadProgressChanged="onSourceDownloadProgressChanged" />

Anyhow, I couldn't help but laugh when I saw that -- but it is a great post and control!  Great job Cameron!