Problem

I had just upgraded NuGet packages - a seemingly innocent thing to do. Everything compiles fine and I tried to run my ASP.NET WebAPI service. Testing in Postman works fine, but when I try to let the browser call an endpoint (any endpoint), I get a mysterious 500 server error with a rather unhelpful payload message of {"message":"An error has occurred."}. However, even with Chrome accessing the service, a breakpoint in the endpoint showed me that the code was executing fine. The problem is clearly occurring inside the ASP.NET engine when trying to send the response back to the browser.

Solution

Chrome sends several headers that Postman does not, so I tried copying those headers into Postman to see if any of them made the difference. About half of them required use of the Postman interceptor, and I decided to do some googling before fiddling with that. Couldn't turn anything up. I couldn't even find a way to trace down the error, although I had a nagging feeling that the compression header might be related, since it was one of the key headers that Postman wouldn't send (Accept-Encoding:gzip, deflate, sdch).

And that's when I suddenly remember to look at the Windows Event Viewer. And sure enough, in the Application log I find a pair of error messages:

1. Server cannot set status after HTTP headers have been sent.
2. The directory specified for caching compressed content C:\Users\XYZ\AppData\Local\Temp\iisexpress\IIS Temporary Compressed Files\Clr4IntegratedAppPool is invalid. Static compression is being disabled.

My hunch was right: something wrong with the compression. Why did this suddenly occur? I have no idea. I hadn't deleted files out of Temp recently. My NuGet package upgrades were for ancillary libraries, but not for ASP.NET itself. But the solution was trivial: as suggested by Event ID 2264 -- IIS W3SVC Configuration, I just had to create the directory manually, and then everything was working again.

FlightNode technical memo on the release of the second beta version, which includes:

• Self registration
• Approval of pending users
• User de-activation
• Account self-maintenance

Read the full article on the FlightNode project site.

FlightNode technical memo, describing the rationale and process of consolidating several Git repositories down to a single repository.

Read the full article on the FlightNode project site.

FlightNode technical memo on the release of the first beta version.

The first beta release of FlightNode is now alive and in the hands of testers. So what's been delivered?

Read the full article on the FlightNode project site.

FlightNode technical memo.

"Wow, you'd think nothing had been happening for the past two months. But that's not the case at all. There are now 6 different GitHub repositories (perhaps a few too many). November and December were heads-down coding months. But now the product is almost ready for an MVP launch... and that has me thinking about error handling. Specifically, logging."

Read the complete article on the FlightNode project site

FlightNode technical memo, for FlightNode contributors who are new to Git. Provides several tutorials, a summary of a typical workflow, and brief review of features in Visual Studio 2015 and Visual Studio Code.

Read the complete article on the FlightNode project site

FlightNode technical memo:

"Here is a a brief demonstration of authentication and authorization using the FlightNode.Identity API. Significant help developing this received from ASP.NET Identity 2.1 with ASP.NET Web API 2.2 (Accounts Management) by Taiseer Joudeh."

Read the complete article on the FlightNode project site

Citizen-science: meet open source software. I'm starting an open source project called FlightNode, which will be a platform for citizen science bird conservation monitoring projects.

This project builds off the IbaMonitoring.org project I took on in 2010. I've been approached by a conservation organization here in Texas, asking for my help to build something similar to that site, but tailored for their purpose (I need to get their permission before using their name). What they want and need is more than I can provide in my "spare time." And I know of other programs that would be interested in using components of these projects.

NuGet has been helping .NET developers maintain package dependencies for a number of years now, and any good dev should know the basic operations from within Visual Studio – how to add, update, and remove packages in a solution, using the NuGet Gallery. But to use only the NuGet Gallery is to know only half – or less – of the story. You might be missing out on…

• Testing out pre-release versions of your projects key dependencies.
• Reverting to older versions of libraries.
• Stand-alone tool installations using NuGet.
• Full-fledged Windows installations using Chocolatey.
• Placing your custom packages into private repositories.

Here are a few tips for moving toward mastery of this crucial part of the .NET development ecosystem.

Does Visual Studio Code measure up to its close kin, Atom?

A friend asked me what I thought of Code. When I installed it a few weeks ago, my first reaction was: this is nice, if you're not used to Atom already. Never satisfied with a simple gut reaction, I thought for a moment, and realized that I had not looked closely at Microsoft's additions – particularly, debugging.