My Life and Code

I learned something interesting yesterday. After we did a new production deployment at work for one of our websites, we ran into a few issues that hadn't occurred in QA or staging. The first was that, for some reason, calls from the website (which is an ASP.NET MVC 4.5 site) to one of our WCF services, was failing. The service in question is used to retrieve images from Sharepoint. Later, we found another issue, wherein attempts to contact a different service for the purposes of sending email were failing. As it turned out, the two issues, while seemingly unrelated, were caused by the exact same problem. In addition to the endpoints for the two aforementioned services, our Web.config file also contained an endpoint for a third service, that is not yet in use, but is defined and in development. But somehow, the binding for this service didn't make it into the production version of the Web.config file, and therefore when the app tried to make use of any service, an exception wa...

The other day I worked on some new code that ran fine locally, but when deployed to one of our internal web servers threw the following exception: "System.Runtime.Serialization.InvalidDataContractException: Type 'System.Threading.Tasks.Task`1[NameOfTheOffendingType]' cannot be serialized." This had me scratching my head -- after all, to use that old developer's saying, "it worked fine on my machine". Not only that, but the exception was occurring when I was calling a method that didn't use the type mentioned in the exception (according to the stack trace it looks like the exception was happening during one of the many calls made under the hood during the use of a proxy class method). But once I found the cause of the problem, it made total sense. In this case, I had added a new WCF service reference to the project, and the proxy class that was generated for it was including some new task-based asynchronous operations that are supported in .NET 4....

I was working on some code today in a WCF service that required me to know the directory containing the service itself. This is one of those things that by the next time I need to do it, I'll be asking myself "How did I do that last time?" Well, here it is: System.Web.Hosting.HostingEnvironment.ApplicationPhysicalPath;

Awhile ago, I was having issues adding a WCF service reference to a project I was working on. I was getting an error when trying to add the reference that said “Custom tool error: Failed to generate code for the service reference”. Looking at the Reference.cs file for the service, it was blank except for the comment block at the top. The answer lied in one of the warning messages (I've changed some of the assembly and namespace names below to protect my company's privacy): Custom tool warning: Cannot import wsdl:portType Detail: An exception was thrown while running a WSDL import extension: System.ServiceModel.Description.DataContractSerializerMessageContractImporter Error: List of referenced types contains more than one type with data contract name 'Content' in namespace 'http://www.mycompany.com/backoffice/core/services'. Need to exclude all but one of the following types. Only matching types can be valid references: "MyCompany.BackOffice.Core.Domain.Pack...

A project I was working on recently made use of several WCF services, but we were having trouble sending large amounts of data to them (specifically, large integer arrays). We spent days trying to figure out how to resolve the issue, trying every config param imaginable (maxRequestMessageSize, maxItemsInObjectGraph, etc), but to no avail. Finally, at the 11th hour, one of the developers found the problem: IIS 7 was interpreting this large message as a Denial of Service attack and returning a false error message. The solution was to add the following to the web.config files of the affected services: < system.webServer > < security > < requestFiltering > < requestLimits maxAllowedContentLength = " 2147483647 " /> </ requestFiltering > </ security > </ system.webServer > Note that the value being used in the maxAllowedContentLength attribute is the maximum integer value and was used only for testing. In ...

One of the projects I work on involves a WCF service that is set up to run under IIS instead of the Visual Studio Development Server. This project has a couple of branches that from time to time are merged back into the trunk, which sometimes leads to the following error if the developer is prompted by Visual Studio to automatically create the virtual directory for the service to run under: Creation of the virtual directory (URL) failed with the error: The URL '(URL)' is already mapped to a different folder location. The reason this error occurs is because, based on which branch was being used when the file was committed to source control, the directory could be different. I figured this would be a pretty easy thing to fix -- just delete the virtual directory in question. But I was surprised to go into IIS Manager and find that...it wasn't there. Yet I could go to the URL in question and receive an error page that suggested that the URL was, in fact, valid. The fix was some...

I was recently working on a WCF project in VS2010. Originally, the service was configured to run under the development server, but was later reconfigured to run under IIS -- but once this happened, it would fail when I'd try to start it up for debugging in the IDE, giving me the following error: The page you are requesting cannot be served because of the extension configuration. If the page is a script, add a handler. If the file should be downloaded, add a MIME map. To correct this issue, follow these steps (these steps apply to Windows 7 and may differ slightly depending on which version of Windows you're using): 1. Go to Control Panel 2. Select Add/Remove Programs 3. Select Turn Windows features on or off (from the left pane if you're using the modern view) 4. Go to Microsoft .NET Framework 3.5.1 (or something similar -- may very depending on your system). Expand this node and make sure the check boxes for any WCF options are checked. Then click OK. But wait, there...

I've been doing some development lately involving calling WCF services from client-side script using jQuery's ajax function, and ran into some strange behavior. I had some code written that would run successfully without error, but then added some additional, un-related code, which would also attempt to call a WCF service via jQuery and AJAX. The original, working code remained untouched. The new code would be unsuccessful -- however, the old, previously working code would now also fail. The error was Error 500, Internal Server Error . Stopping and restarting the development server didn't solve the issue, nor did exiting and restarting Visual Studio. Even rebooting my machine didn't help. It just didn't make any sense. I finally resolved the problem by deleting the Temporary ASP.NET files for the site. By default, these are located in C:\WINDOWS\Microsoft.NET\Framework\(Framework Version)\Temporary ASP.NET Files , in a sub-folder matching the name of your site. Not...