Save yourself from pulling your hair and reading countless pointless/useless/incorrect posts on similarly useless Google results by following the following simple step: XmlIgnore and ScriptIgnore do not work for JSON.net serialization (using version 5.0) within the ASP.net Web API. You must use the [JsonIgnore] attribute. /// <summary> /// Gets or sets the model action state /// </summary> [XmlIgnore, ScriptIgnore] public virtual ModelActionStates ActionState { get; set; } JSON.net serializer returns this property in both XML and JSON results. WHY?! /// <summary> /// Gets or sets the model action state /// </summary> [XmlIgnore, ScriptIgnore, JsonIgnore] public virtual ModelActionStates ActionState { get; set; } JSON.net serializer ignores this property for both XML and JSON results. Carry ...
I've written an article over at the Daily Slack titled "How Telecommuting Can Save You Money, Cure Baldness, and Help Save The World" highlighting some pretty significant statistics on the benefits of having a telecommuting workforce. In fact, I found out that by having just 3/4 of the 50 million potential teleworkers actually working from home could reduce the U.S. petroleum-based CO2 output by 13%! Check it out!: http://dailyslack.com/2013/02/how-telecommuting-can-save-you-money-cure-baldness-and-help-save-the-world/
As a visual learner I think this tool is absolutely fantastical. It takes in a RegEx string and renders it out into a visual railroad diagram, giving a developer a quick and easy way to visualize what exactly the RegEx string is looking for. I highly suggest you check out RegExper to help debug those pesky RegEx strings!
We recently ran into an issue at work where our custom MVC4 error handler, which utlizes the global.asax Application_Error event, stopped firing on our remote IIS 7 web server. It didn't appear to be a code change that caused the issue so I searched for a good hour trying different fixes across the Internet. It was until I found the following issue that our handling began to work once again. <system.webServer> <httpErrors existingResponse="PassThrough" /> </system.webServer> Adding that httpErrors parameter to the web.config of the application enabled our custom error handling once again. Hopefully this helps you in your debugging adventures!
Forgive my brevity on this post but I am writing to you today from my cell phone. You may run into the problem I just had and I wanted to let you know what the issue was and how I solved it. Suppose you have the following code: DECLARE @decimalValue1 decimal = 5 DECLARE @decimalValue2 decimal = 10 DECLARE @resultValue decimal SET @resultVaule = @decimalValue1 / @decimalValue2 PRINT @resultValue You would expect to get a value of .5 but in fact the value is always 1. The problem here is that we did not specify the precision of the decimal data types. DECLARE @decimalValue1 decimal(18,2) = 5 DECLARE @decimalValue2 decimal(18,2) ...
Save yourself from pulling your hair and reading countless pointless/useless/incorrect posts on similarly useless Google results by following the following simple step:
XmlIgnore and ScriptIgnore do not work for JSON.net serialization (using version 5.0) within the ASP.net Web API. You must use the [JsonIgnore] attribute.
/// <summary>
/// Gets or sets the model action state
/// </summary>
[XmlIgnore, ScriptIgnore]
public virtual ModelActionStates ActionState { get; set; }
JSON.net serializer returns this property in both XML and JSON results. WHY?!
/// <summary>
/// Gets or sets the model action state
/// </summary>
[XmlIgnore, ScriptIgnore, JsonIgnore]
public virtual ModelActionStates ActionState { get; set; }
JSON.net serializer ignores this property for both XML and JSON results.
Carry on!
I’ve written an article over at the Daily Slack titled “How Telecommuting Can Save You Money, Cure Baldness, and Help Save The World” highlighting some pretty significant statistics on the benefits of having a telecommuting workforce. In fact, I found out that by having just 3/4 of the 50 million potential teleworkers actually working from home could reduce the U.S. petroleum-based CO2 output by 13%!
Check it out!: http://dailyslack.com/2013/02/how-telecommuting-can-save-you-money-cure-baldness-and-help-save-the-world/
As a visual learner I think this tool is absolutely fantastical. It takes in a RegEx string and renders it out into a visual railroad diagram, giving a developer a quick and easy way to visualize what exactly the RegEx string is looking for. I highly suggest you check out RegExper to help debug those pesky RegEx strings!
We recently ran into an issue at work where our custom MVC4 error handler, which utlizes the global.asax Application_Error event, stopped firing on our remote IIS 7 web server. It didn’t appear to be a code change that caused the issue so I searched for a good hour trying different fixes across the Internet. It was until I found the following issue that our handling began to work once again.
<system.webServer>
<httpErrors existingResponse=”PassThrough” />
</system.webServer>
Adding that httpErrors parameter to the web.config of the application enabled our custom error handling once again.
Hopefully this helps you in your debugging adventures!
Forgive my brevity on this post but I am writing to you today from my cell phone.
You may run into the problem I just had and I wanted to let you know what the issue was and how I solved it.
Suppose you have the following code:
DECLARE @decimalValue1 decimal = 5
DECLARE @decimalValue2 decimal = 10
DECLARE @resultValue decimal
SET @resultVaule = @decimalValue1 / @decimalValue2
PRINT @resultValue
You would expect to get a value of .5 but in fact the value is always 1. The problem here is that we did not specify the precision of the decimal data types.
DECLARE @decimalValue1 decimal(18,2) = 5
DECLARE @decimalValue2 decimal(18,2) = 10
DECLARE @resultValue decimal(18,2)
Now when the code is executed the correct decimal value will be displayed.