I’m running into this situation where a field up the inheritance structure will simply not set. In this case the _IsEntityDirty field was just assigned a value of true, yet the debugger (and not just the debugger – conditional code actually sees this value as false!) sees the value as false. Note this is a protected field defined 2 levels up the hierarchy.
I can’t figure out WTF is going on. Actually the field shuldn’t be accessible at this level – I have a public property for this but to simplify the debugging I actually made the field public so I can see the value change. With the property assignment I can step into the assignment and see the field value change to true, then when I step back out to the current level the value changes immediately back to false. No other code runs…
WTF is going on here?
The hierarchy is something like this:
wwBusiness
wwBusinessGeneric<t>
busStatus<StatusEntity>
IsEntityDirty is defined at the wwBusiness level as:
/// <summary>
/// internal flag used to tell when the entity needs to be refreshed.
/// </summary>
protected bool IsEntityDirty
{
get
{
return this._IsEntityDirty;
}
set
{
this._IsEntityDirty = value;
}
}
protected bool _IsEntityDirty = true;
(the protected _IsEntityDirty is temporary so I could test direct assignment up the hierarchy).
I even took out the property and just created a field:
protected bool IsEntityDirty = true;
and used that field and it still didn’t work. Added another field
protected bool IsEntityDirty2 = true;
Same identical signature right? And IT WORKS just fine.
I have several other protected and public properties that are defined identically, yet they all work fine. I can’t set the value in the debugger either.
Am I having a bad dream? Somebody pinch me… <s>
I’ve run into stuff like this before and in those situations it seems that the problem usually had to do with an out of date assembly where a minor change ended up causing weird inconsistencies like this. But I double checked all assembly references and ensured the right assemblies are getting referenced and compiled into the output directory. That’s not it this time…
… Later after endless fiddling …
It turns out the problem had something to do with the Solution file. I’m not clear on what the issue is exactly, but I stuck the component into another solution for testing and it worked fine. Added a new project to the existing ‘bad’ solution and regardless of project – console, web the code simply did not work exhibiting the above behavior.
So I created a brand new project and solution added the assembly and sure enough it worked. So there appears to be some configuration problem in the solution.
Looked at the existing solution and found:
Some remnant Test files – I had played around with the built in test generation in Visual Studio, but it was such a pain in the ass I switched back to using nUnit. However, even though I removed the VS test project it left behind a bunch of shit in the solution and in the folder structure. After clearing out those files and nuking the solution .suo file and starting the original solution back up – everything is back to normal and my code once again runs correctly.
I can’t figure out what in the world could have made for this behavior. I double checked the assemblies generated and the failure occurred even when running outside of Visual Studio. But even if it was only inside of VS.NET – what could possibly cause code to not be able to assign a value to a specific field? The only thing I can think of is a version mismatch but I checked and double checked the assembly signatures and even double checked the GAC to ensure there wasn't a stray reference in some other location getting called.
I can’t believe this just cost me an hour and a half worth of time…