ASP.NET Web Api 404 errors

I recently deployed a ASP.NET Web Api web service to a production server and kept getting 404 errors when I made requests.  After extensive research I finally traced the problem to the web.config file.  I don't totally understand why this fixed it, but it has something to do with how IIS resolves the URL.

In the web.config, you'll find this line:

<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />

This needs be changed to:

<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*" verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />

Notice the removal of the period from the "path" attribute.

Response.Redirect

When you redirect to another page using .NET, you normally use the Response.Redirect method.  However, if you only supply the URL as the parameter, you'll get a ThreadAbort exception thrown. This can fill the event log pretty darn quick.  To avoid this, set the second parameter to False.  This will immediately end the response, so no exception is thrown.

The only "exception" to this rule (haha), is when you want code to execute after the Response.Redirect.  In this case you can't immediately end the response.  In this case, you either have to put up with the exceptions in the log, or catch the ThreadAbort exception and just swallow it.

SOAP and REST

I found a really great article that very simply describes the difference between SOAP and REST.  Most articles you read are written by folks that know a lot about one protocol but not the other.  And usually they are very biased toward REST.  For example, you'll see articles like "Why SOAP sucks" and the like.

In my experience SOAP is easier to create clients with if you have an IDE that can generate code using the WSDL file.

REST is easier to create clients with if you're calling the web service from JavaScript or you don't have code generation tools.

http://blog.smartbear.com/apis/understanding-soap-and-rest-basics/

SharePoint 2007 - Determine Configuration Databases

It can be difficult to see which databases are used by which SharePoint farm especially when you have been experimenting with several different environments.

To see what databases are used simply open up Central Administration, and click Operations.  Then go to Perform a Backup.  On this page, you will see all of the configuration databases used by this farm.

Of course, if it's content databases you're interested in, simply go to the Content Databases page under Application Management.

.NET Framework and CLR Versions

In this article, I'm going to attempt to explain what a developer needs to know about the relationship between the .NET CLR version and the .NET Framework version.  I am not attempting to explain what the CLR is or is not.  I am also pretending that version 1.0 did not exist, because I never used it.

First, there was .NET Framework version 2.0 which included .NET CLR version 2.0.  You wrote an application that targets .NET 2.0.  You installed .NET Framework 2.0 on your server, and installed your application.

Then Microsoft released .NET Framework version 3.0 but still included .NET CLR version 2.0.  You installed .NET Framework 3.0 on your server, and since your application was built using a version of the framework that included .NET CLR version 2.0, your application will continue to run with version 3.0 of the Framework.

Then Microsoft released .NET Framework version 3.5 but still included .NET CLR version 2.0.  You installed .NET Framework 3.5 on your server, and again since you application was built using a version of the framework that included .NET CLR version 2.0, you application will continue to run with version 3.5 of the framework.

Then everything changed with .NET Framework version 4.0.  Version 4.0 shipped with CLR version 4.0.  Your app won't work with version 4.0 unless you recompile the app with it targeted to .NET 4.0.  However, on your server, .NET 3.5 will remain installed, so you're app will still work using .NET 3.5 as it did before.

Now, .NET Framework version 4.5 (and 4.5.1) is now out.  These ship with CLR version 4.0.  So if you install 4.5 on your server, your apps built using 4.0 will still work using the new framework.

Determine which version of the .NET Framework is installed

1. Open the Registry Editor (regedit).
2. First look here:  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP.  Expand NDP and you will see all of the versions installed.
3. To see if 4.5 and over is installed, you need to expand the v4 folder and click "Full".  Look at the version entry to see what version of 4 is installed.

Setup Remote Debugging in Visual Studio 2013

Sometimes you need to debug an application running on a different server than the one you have Visual Studio installed on.  You can install something called Remote Tools for Visual Studio on the server where the application is running and debug from the other machine.

1. Download Remote Tools for Visual Studio 20XX Update X.  Make sure you download the version and update number that matches your version of Visual Studio.
2. Install it on the remote server.
3. On the remote server, start up the application called Remote Debugger as administrator.
4. In Visual Studio, choose Attach to Process in the Debug menu.
5. Type the name of the server, and click "Refresh".
6. Highlight any instances of w3wp.exe (assuming you are debugging a web app), and click attach.

You must remember that in order for this to work, you have to build your application in debug configuration, so that the .pdb files are deployed to the remote server.