![Smile [:)]](/emoticons/emotion-1.gif)
(for me, at least). On a side note, since I was using VB 2005 Express, this implied (just to be really sure) manually modifying the .vbproj files of my projects, with Notepad, to make them actually generate the "Debug" and "Release" versions of the binaries into specific, clearly marked directories, and to rebuild the references to make sure the UI project was using the "Release" biz-layer assembly. Oh, how I wish I could get my hands on VS 2005 Pro...![Tongue Tied [:S]](/emoticons/emotion-7.gif)
). Of course, Rocky wouldn't possibly know that this was going to happen; if you declare a method with <MethodImpl(NoInlining)>, just like PropertyChanged() method was, the JIT compiler should at least become aware of that, and try to take precautions when compiling code that contains such attributed method calls. ![Big Smile [:D]](/emoticons/emotion-2.gif)
. I'm conscious that the previous paragraph sounded like I was demanding you, Rocky, to do something. But that wasn't the idea. That idea alone is going to make me sick, I'm sure. What I wanted is to make sure future generations of users of CSLA.NET wouldn't have to face these issues on their own. I'm pretty sure CSLA.NET usage is rapidly growing, and it will continue to be for a while. And it's not without a reason. Izhido:
On a side note, since I was using VB 2005 Express, this implied (just to be really sure) manually modifying the .vbproj files of my projects, with Notepad, to make them actually generate the "Debug" and "Release" versions of the binaries into specific, clearly marked directories, and to rebuild the references to make sure the UI project was using the "Release" biz-layer assembly. Oh, how I wish I could get my hands on VS 2005 Pro...
Y'know, I think this is becoming more and more of an important issue. This bug is of the kind of bugs that will invariably go unnoticed during the development stage of a project, and when detected it might be too late for a "quick fix" (except if that "quick fix" becomes deploying "Debug"-only versions of the components
The thing here is, since .NET 2.0 was already released as RTM, and everyone is using it, well, anyone using CSLA.NET 2.0.(0/1/2/3/...) will be hit by this bug sooner or later. And, to be honest, it took me a while to find out why suddenly my application was rejecting every single customer, product, warehouse, you name it, that was being added using my input forms when I deployed it at the testing machine, when the very same exact code (or, at least, I thought so) was working just fine in my development computer!
Rocky, I know it's not your fault. You did what it seemed to be the right thing when creating the PropertyHasChanged() method. But something else outside your code broke it. And the workarounds for that particularly ugly bug are either ugly (deploying "Debug" assemblies) or will require a long time to implement (including <MethodImpl(NoInlining)> into every single business property). What I want to ask of you is, please, write something about it. Write any thoughts you have about it, but please, do it. Write about it in your blog, or at your web site, or in a place that everyone will see. Everyone using your excellent framework is also visiting your (also excelent) web site, and reading your (also excellent) web blog. You're the Commander in Chief of all things CSLA-related. Please, at least issue a warning telling us that this particular bug might happen to us some day. And that we should take precautions. Please!!!
And there's a thread on this forum about this issue. Perhaps an errata to the book itself is called for, and a <remarks /> for that particular overload that explains this issue is warranted.Ugh... my head... my stomach hurts so bad
I can't believe I didn't see the article... got a little lost since the web site redesign. Again, thanks!!!I have to pipe in on this thread to share a case where noinlining appears not to work. We are going to start passing in parameters by name. We are on .Net 2.0 and CSLA 2.14. This code works for about 100 of our properties, but seems to not work for 1 or 2. There is no pattern to the 1 or 2 where it fails, they are just like all the others. Even though we specify noinlining, in a few cases the method appears to get inlined.
Here is our code that succeeds:
public Int16 SequenceNum{
get { return _SRN_SEQ; } set {SetPropertyValue<Int16>(ref _SRN_SEQ, value, 0); }}Here is our code that fails:
public Int16 Sequence{
get { return _SR_SEQ; } set {SetPropertyValue<Int16>(ref _SR_SEQ, value, 0); }}And here is the method they both call.
1: [System.Runtime.CompilerServices.MethodImpl(System.Runtime.CompilerServices.MethodImplOptions.NoInlining)]
2: protected bool SetPropertyValue<V>(ref V memberVariable, V newValue, V ValueIfNothing)
3: {4: bool result = false;
5: if (memberVariable == null && newValue == null)
6: {7: result = false; //Nothing changed. memberVariable is still nothing.
8: }9: else if (memberVariable == null && newValue != null)
10: {11: result = true; //new value passed in; memberVariable was null - make the change.
12: }13: else if (memberVariable != null && newValue == null)
14: {15: newValue = ValueIfNothing; //newValue = null, so reset newValue to the ValueIfNothing Value.
16: result = true;
17: }18: else if (memberVariable != null && newValue != null)
19: {20: if (memberVariable.Equals(newValue))
21: {22: result = false; //newValued, but no change.
23: }24: else
25: {26: result = true; //newValued, changed newValue.
27: } 28: } 29: 30: if (result == true)
31: {32: string propName = new System.Diagnostics.StackTrace().GetFrame(1).GetMethod().Name.Substring(4);
33: if (CanWriteProperty(propName, true)) // checks user's authorization
34: { 35: memberVariable = newValue; 36: PropertyHasChanged(propName); 37: }38: else
39: {40: result = false;
41: } 42: }43: return result;
44: } //End function
Copyright (c) Marimer LLC