During the building of the WCF service mentioned in my previous post, I came across an error when trying to access the WCF service when running it within the local development fabric. It worked fine when just running the web role, and when deployed into Azure. So, this led me to investigating if the IIS as used by the local development fabric to see if it was not configured to serve .SVC files.
One of the first things that I did to investigate was to just navigate to the service in the browser with a brand new service project that I put together. When doing this, I received the following:

There should be a page showing the information about the service, instead a 403.3 error. Likewise, when stepping through the debugger, similar errors could be seen when checkin the exceptions.
After a bit of googling, the solution to this turns out to be the following. Apparently, WCF is not configured properly with IIS. This feels very similar to the problem when ASP.NET sometimes is not configured properly, in that the solution is very similar.
To solve the problem, navigate to the windows communication foundation folder as shown here, and run the "ServiceModelReg.exe -i" command.

After running that program, you will see output similar to the following and the problem will then be solved.
cec2d1a7-e12f-47b0-b749-5a787a19b42d|0|.0
In my previous post I showed how to rewrite urls which where applied to .asmx web service proxies. In the last couple of days I needed to convert WCF client proxies for Silveright to do the same thing. Turns out this is very similar (if not identical), but I found a new syntax for doing it which makes things a little bit easier. Here is an example:

The ManagementServiceClient class is the proxy class generated for the WCF service. The change is to use the App.Current.Host.Source variable and append the path to the .svc file. Works like a champ and looks real nice.
e83b5f14-30ed-4f54-8e1e-5773678d7e31|0|.0
When you deploy your web role to Azure (or the local development fabric), it will be assigned a url which is different from the one assigned by VS.NET, and which usually has a port of 81. This can cause problems in your Silverlight application if you call web services within the web role project. This is because VS.NET assigned a port to your web services (such as 43039). When deploying to Azure (or again the local development fabric), the app has a new (localhost:81 on the local dev fabric, and yet a different one in Azure), but the old ports (and a reference to localhost) remains in the proxy configuration(s).
So how can you solve this? The best scenario that I have found is to reconfigure your proxy URLs in the start up of the silverlight application. As an example:

What I'm doing here is calling this method during the startup of the Silverlight application object. It uses the HtmlPage.Document.DocumentUri object to determine the url to the application, and truncates it to contain just the address and port of the page that the application is served from the web server. The last two lines then create two proxy objects that I use in this app, and pass a new enpoint address object which is the base URI determined before appended with the asmx filename of the service. Note that you'll also need to pass in a binding object too; I change some parameters on mine, but using just a default BasicHttpBinding object should do fine (and it has to be a basic HTTP binding object as that is all that is supported by Silverlight).
This works for all deployments of the Silverlight application, either running locally in VS.NET, the local development fabric, or in Azure.
8e4c739f-b796-45c2-a4e2-85192e1f4ee2|0|.0
Posted by
mheydt on
4/17/2009 9:44 PM |
Comments (0)
Just loaded up the mac with 8GB of RAM. Sweet! Much more elbow room for those virtual machines!
9e3cd156-92be-4130-b8f6-a39b1e57b947|0|.0
I'm building an application to front Twitter and provide some other services to the user around Twitter. I think it's kind of neat looking with what I've done so far, but I have a bunch of list boxes (and scrollviewers) that I think just look ugly:
I was figuring that I would want to make them look more like the scroll bars on the iPhone or in other apps I use like EventBox:
So I googled a little and came up with this, which looks to exactly fit the bill:
Mark .NET: Styling a ListBox With Silverlight 2 Beta 2 (Part 2) - Scrollbars
With some modifications, my app now looks like this....
Much Nicer!
One thing to note about the code on that site. Don't cut and paste it from the blog pages - it does not work. Get the actual
solution that is posted and use the XAML in that as it works great.
efd5cf8a-d4b3-49d5-bf69-8ee47469ff4d|0|.0
Categories: Win7
Posted by
mheydt on
4/2/2009 7:05 PM |
Comments (0)
Got windows 7 build 7068 running in a VM today on my mac. Haven't done much with it yet other than a few basic settings, but it installed real fast and seems to run pretty quickly. I'll be loading up development tools tonight and we'll see how it performs under load. One thing I did notice different is that many of the panels in various windows (like control panel) have slide transitions, which I kind of liked.
Here's a few pictures:
How about with some mac wallpaper?
98255c78-7969-4c10-b874-27eabf487de0|0|.0