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