This blog entry from a fellow developer nailed it.  It behaves exactly like a web.config transform (without using any third-party libraries), except you have to set it up manually in your SL project.

I don’t get it: why the heck does this new HttpClient have to be ALL asynchronous methods?  What if you just need a simple synchronous method?  Perhaps it’s just that I haven’t grasped why Microsoft created this in the first place.  I think it’s supposed to simplify threading, but the code I’m seeing is more confusing than it has to be.

Or maybe I’m just getting to old for this sh!t.

A co-worker introduced the whole team to a cloud-based logging facility called Loggly.  Integration with Loggly is very easy and pretty much serves me for the most part, however as I use it more, the more I become annoyed at how clunky the UI is (no unix tail equivalent, very limited searching/filtering) and how delayed refresh rates are (which could span several seconds).

So I started looking at an alternative and came across PaperTrailApp.  It’s similar in concept with Loggly, but it’s more integrated with standard logging facilities like syslog and its OOB support for NLog is a welcome addition.  Its UI is a lot more polished than Loggly’s (auto-refresh and tail-like features supported) and there’s practically no delay that I can detect.  Searching/Filtering is much better as well.

I haven’t played with PaperTrailApp that long (literally started only an hour ago), but I’m almost positive that between Loggly and PaperTrailApp, the latter gets my vote.

It turns out that one of the WCF services that we’re using was forced to be running in a single thread.

[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single)]

Somehow, one of the previous developers was probably unit-testing the WCF and forgot to remove the directive before he checked in the code.

I think this option, IMO, is ultimately evil and very destructive; it should throw an ERROR in the Event Viewer when something like this is set in WCF implementation.

This, my friends, is why load testing is very important in any customer-facing API.

Exception message: Could not load file or assembly ‘msshrtmi’ or one of its dependencies. An attempt was made to load a program with an incorrect format.

What is this?!  Most google results will point you to some Azure-related forum threads and will advise you to remove <PlatformTarget> tags in your .csproj files.  That didn’t work for me.  What did work is manually deleting msshrtmi.dll from the target directory.  Now, adding this in the pre- or post-build step should work, but for some reason, it doesn’t…maybe because it’s almost midnight and I’m still dealing with this crap.  I’m getting too old for this.

curl(18): transfer closed with outstanding read data remaining

The funny thing is, when I run the REST HTTP service under Visual Studio debugger using the built-in web server, i don’t get this error!  it only appears when I deploy it on an IIS server.

Here’s the original code:

if (...)
{
  HttpContext.Current.Response.Redirect(new_url);
}

I changed it to:

if (...)
{
  HttpContext.Current.Response.Rediect(new_url, false);
}

The problem now is that status code is being set to HTTP 200!  To get around this (after a lot of trial and error),

I added this code:

WebOperationContext.Current.OutgoingResponse.StatusCode = System.Net.HttpStatusCode.Redirect;

BAM!  Fixed.  No more curl errors!

Having said all of that, this blog post of his is the ONLY useful source out there about enabling IIS 7 Dynamic Compression.

If you’re using Web Deploy 2.0 and you try to deploy your web application to a remote server by using https://remote_server:8172/msdeploy.axd you may encounter an error message that is along the lines of the destination is unreachable, or the required process “The Web Management Service” is started.

If you encounter this, try to check the services on the REMOTE SERVER if Web Management Service exists and is running.  Chances are, it’s missing.  If it’s missing, you need to launch the Web Platform Installer and install “IIS: Management Service” then go to Services and make sure it’s running.

Update: If you’re still having problems, like getting a 404 or 403 errors on deploying the app to a remote IIS (i.e., using TFS), there’s something else you need to do : check out this thread from stack overflow and read the response from simbolo.

I am not a SilverLight expert–far from it.  I don’t intend to learn this, and the only reason I’m going through the motions is because some system that I happen to have inherited uses SilverLight.  SilverLight is probably one of the top 5 things I hate that came out of the Microsoft pile of trainwreck (WiX being the #1).

Anyway, enough with the rant.

I upgraded the UI from SilverLight 2.x to 4.x and one of the things that Microsoft got rid of is the asp:SilverLight tag to plop in your SL app on a page; it’s recommended that you use the object.  The issue with this is that the silverlight object is now not accessible from code-behind…so in SL 2.x where it’s easy to pass a dynamic initParams string with:

mySLApp.InitParameters = “O HAI LOL”;

…now with SL 4, this becomes a nuisance.  Fortunately with this blog posting, I have found an elegant way to pass initialization parameters…make sure you read the comment from Jelgab.