Daily Archives: July 16, 2008

.net, microsoft, silverlight, software development

Testing a web service with IIS 7 on Vista

Not long ago I created a simple CRUD example using Silverlight 2.0 beta 2. I used Visual Studio 2008 and the ASP.NET Development Server. I wanted to test the same WCF web service with a different client (more on that soon), so I decided to deploy it to the instance of IIS 7.0 which comes with Windows Vista. I created a new web site on a different port than the default.

Nothing worked. Reason: although I have installed .NET 3.5 SP1 beta and Vista SP1 – which should do this automatically – the IIS 7 mime types and  handler mappings were not configured for Silverlight and WCF. How to fix the mime type is here and the handler mappings, here.

The web service still didn’t work. I got:

A first chance exception of type ‘System.ServiceModel.ProtocolException’ occurred in System.ServiceModel.dll.

I changed the debug options to break on all managed exceptions, and got this further detail:

The remote server returned an unexpected response: (404) Not Found.

Problem: Silverlight is looking for a cross-domain policy file.  The reason was that at this point I was still running the Silverlight app from the ASP.NET Development server, and it considered IIS to be on a separate domain. The 404 error does not make this obvious; but a quick Google for Silverlight 404 shows that this is a common problem.

Silverlight is designed to support cross-domain policy files in either Microsoft’s format (clientaccesspolicy.xml) or Adobe’s format (crossdomain.xml). If the service is just for Silverlight, use Microsoft’s format; otherwise I suggest adding both.

Nearly there; but I still had to fix SQL Server authentication. I normally use Windows authentication, and if you are using the ASP.NET Development server this just works. Move to IIS though, and it does not work unless you set up ASP.NET impersonation, or create a SQL Server login for the account under which the application pool is running. Oddly, when I tried the app without fixing the SQL Server login I still got a 404 exception; I’m not sure why.

Incidentally, I noticed that if you configure ASP.NET impersonation for a web site, the username and password gets written to web.config in plain text (bad). If you configure the application pool to run under a different account, the password is encrypted in applicationHost.config (better). In the end I decided to use good old SQL Server authentication.

One last tip: when debugging a web service, put the following attribute on the class which implements your ServiceContract:

[ServiceBehavior(IncludeExceptionDetailInFaults = true)]

Otherwise you get generic fault messages that don’t help much with debugging. Remove it though for release builds.

Once I’d fixed the SQL server login, everything was fine.

google, microsoft, search

Why I can’t use Microsoft Live Search for real work

16 Comments

I’ve complained before about the quality of Microsoft’s Live Search vs Google; but today’s example seemed too good an illustration not to mention.

I needed to update Windows XP to SP3. In particular, I wanted what Microsoft calls the “network” download; that is, the entire service pack, not the launcher app that initiates a piecemeal download tailored to the specific machine.

I pulled up Live Search and entered “windows xp sp3 download”.

To my surprise, Live Search offered me only third party download sites in its first page of results. Actually, that’s not strictly true. At number 8 is the download for “Windows XP SP3 RC2 Refresh” (obsolete); and at number 10 the general home page for XP downloads:

Find popular Windows XP downloads, including PowerToys, trial software, tools and utilities

I tried Google. Same search. The official network download is in first place. The official piecemeal download is second.

I know: you can argue that this is just an isolated search, and that some other search might show Google in an equally bad light. However, I find this constantly: Google gets me much better results. Further, this case is particularly telling, since a third-party download site is not what you want when patching Windows. Quite likely those other sites do point you to the correct official download eventually; but getting Microsoft downloads from Microsoft’s site is safer.

I am not surprised Microsoft has a tiny share of the search market; and I don’t believe this is simply because of Google’s clever marketing.

Update PS: The above screen grab still matches what I get today. However, users in different countries may get different results; from the comments below I suspect that US users get better results in this instance. Maybe Live Search is worse in the UK than in the US; I’d be interested to know.

Technorati tags: , ,