The Production Publish that went south


So let me start by saying that last nights published sucked big time. All the publishing went well, but what I I’m about to talk about here took a 5-10 minute publish and turned it into a 4 hour chaotic hot mess. So anyone doing  WCF Web Services, MVC or Entity listen up, because I think the tragedy of me losing more hair is enough and no one else should have to suffer this fate.

Tragedy #1 – Slow Cheetah

For those of you that do not know, Slow Cheetah is a tool that allows you to Build  separate app.config and web.config files for each environment using very simple aspects of  the XSLT language. This allows you to publish  each environment in Visual Studio for that project / solution without needing to touch code. For the most part, it’s great. 3 caveats I ran into last night.

1.) In order for it to “always” work properly, even in VS2012, you must make sure that you have compiled the Release environment if you were working in Debug ( even if you  made the change in Web.Release.config.

2.) This one caught me, and I have preached it before, make sure all your Web.config files are set to “Compile Always”. Do not trust the fact that it should be looking at the date modified, cause it doesn’t always work.

Tragedy #2 – Nlog in VS2012

NLog is an awesome tool, and other than setting the config file to “Copy Always” I have been hard pressed to find any major issues with it, and Sentinel and Insider both use it  religiously. I ran into an issue with VS2012 that took the majority of the night and I wanted to share what happened and then how I found it out. I think that if anything is more important than the first.

So NLog works great in VS 2012, but one thing that is missing if you are used to it in VS 2010 is the nlogger snippet. If you are not used to it, this may not be a problem, but in my world, I was used to it and then typing it out was not something I was used to and was obviously prone to mistakes.

Here was the problematic code that caused ne heartache. Anyone know what is missing without looking below?

private Logger logger = NLog.LogManager.GetCurrentClassLogger();

It was the static attribute in the statement. That was throwing exceptions in both my new web services that only returned the dreaded “service unavailable” error in WCFTestClient. For those of you that don’t know, that’s about as useful as Object Reference Null. This is what the code should look like.

private static Logger logger = NLog.LogManager.GetCurrentClassLogger();

At the end of the email, I’ll go over how I figured this all out.

Tragedy #3 – Razor DOES NOT play completely nice with ASPX

So I was told a few weeks ago that ASPX and Razor play wonderfully together like 2 peas in a pod in the same project. Let me start by saying that this statement is utter crap. First, Each area OR Sitemaster / Layout is given their own Web.Config if and when you combine the two engines in the same area. On top of that, the engine works great on your own machine, but not so muchon the server unless you have MVC 4 installed on the server ( I am guessing on this as it is the only core difference I can come up with as of now. This is still an issue on production unfortunately and we will be investigating the answers.

How I figured out #2

So there are a few things I used to figure this all out. One of which was to turn on fault exceptions to be sent to the client. This was done by the following line of code.

<serviceDebug includeExceptionDetailInFaults=”true” />

It is probably currently set to false on your code. The next thing was to use a tool called SOAPUI ( Completely free and awesome… just sayin). This tool is like the WCFTestClient on the best steroids on the market. It allows you to consume a WSDL, make test calls, see your methods available in a clean non cryptic environment. If you look below, you will notice that upon making a call to a particular method, I Got an exception like I mentioned above that states the old Object Reference hell. One thing you will notice though is that underneath that, It references The error being at NLog.LogManager.GetCurrentClassLogger(). I recognized this immediately and started comparing the log statements to old ones and found the static issue. Prior to turning on trace for WCF, I was looking at Entities or procedure issues and possible issues with the objects themselves not being serializable, but in the end it came down to this.


I hope that this helps someone else come back from the edge of the cliff one day 🙂


As Always Happy Coding


About Gregg Coleman

I am Senior-level Software Engineer working primarily these days with .NET. I have a good working knowledge of ASP.NET MVC, Web Forms, WCF web services and Windows Services. I spend much of my time in the Web Services (SOAP and REST) world in my current job designing and implementing various SOA architectures. I have been in the software engineering industry for about 6 years now and will not now nor ever consider myself an "expert" in programming because there is always so much to learn. My favorite thing about designing software is there are always new emerging technologies and something to learn every day! My current job has me spending much of my job on the bleeding edge of technologies and changing gears all the time, so I'm never bored and always challenged. On my spare time I enjoy weight training, reading and venturing to new places near by. Of course programing and learning new technologies are another hobby of mine.
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s