Csla Unit Tests - Failing when building 'Release' assemblies

PatrickVD posted on Wednesday, June 21, 2006

Hello All,

I was just wondering if anybody else has experienced this problem.
I recently downloaded the v2.0.2 of the framework (C#) and the accompanying 'UnitTests'.
(I have used CSLA before, but now I really wanted to use the 'unit tests' as I plan to implement a few tweaks/suggestions from other posts on this forum to the base Csla framework, and don't which to 'break' anything)

I created a new solution where I included both the Csla.Test and the Csla projects.
Additionally I created an MSBuild script to compile the solution and at the same time run the 'UnitTests' (NUnit).

As long as I create a 'Debug' versions and run the NUnit task on the 'debug' version of the assemblies, all tests pass successfully... but as soon as I try to create a 'Release' build of the assemblies and run the tests, I have 5 failures (see below is the test results log):

------ Test started: Assembly: Csla.Test.dll ------

TestCase 'Csla.Test.Authorization.AuthTests.TestAuthCloneRules'
failed: System.Security.SecurityException : Not allowed 2
    D:\Development\DevBrains\Csla.NET\src\tests\Csla.Test\Authorization\AuthTests.cs(40,0): at Csla.Test.Authorization.AuthTests.TestAuthCloneRules()

TestCase 'Csla.Test.Authorization.AuthTests.TestAuthBeginEditRules'
failed: System.Security.SecurityException : Not allowed 2
    D:\Development\DevBrains\Csla.NET\src\tests\Csla.Test\Authorization\AuthTests.cs(125,0): at Csla.Test.Authorization.AuthTests.TestAuthBeginEditRules()

TestCase 'Csla.Test.ValidationRules.ValidationTests.TestValidationRulesWithPublicProperty'
failed:
    expected: <False>
    but was: <True>
    D:\Development\DevBrains\Csla.NET\src\tests\Csla.Test\ValidationRules\ValidationTests.cs(71,0): at Csla.Test.ValidationRules.ValidationTests.TestValidationRulesWithPublicProperty()

TestCase 'Csla.Test.ValidationRules.ValidationTests.TestValidationRulesAfterClone'
failed:
    expected: <False>
    but was: <True>
    D:\Development\DevBrains\Csla.NET\src\tests\Csla.Test\ValidationRules\ValidationTests.cs(160,0): at Csla.Test.ValidationRules.ValidationTests.TestValidationRulesAfterClone()

TestCase 'Csla.Test.ValidationRules.ValidationTests.RegExSSN' failed: Ssn should not be valid
    D:\Development\DevBrains\Csla.NET\src\tests\Csla.Test\ValidationRules\ValidationTests.cs(229,0): at Csla.Test.ValidationRules.ValidationTests.RegExSSN()

131 passed, 5 failed, 0 skipped, took 5.00 seconds.

Any suggestions to solve this would be welcome.

Thanks,

Patrick.

PS:
I did run into issues with the unit tests for the different 'Date/SmartDate' related Asserts. These are based on the 'US date format (MM/DD/YYYY) and use hardcoded strings in this format to perform Asserts.
I managed to correct this and change those tests into a 'regional settings' indepent test... But these are unrelated to the failing tests.

ajj3085 replied on Thursday, June 22, 2006

PatrickVD:
Well I actually tried running the unittests several ways ... with NUnit GUI, with TestDriven.NET VS Addin, with NUnit (MSBuild Community Task).. and always have the same results...

Only the Authorization and ValidationRules related tests are failing in 'Release' version.. but are successfull in 'Debug' build ... that's what seems so strange ...

Hmm, I know there was a problem because release mode makes it so that PropertyHasChanged can't get teh correct stack trace. When you raise your PropertyHasChanged, or call CanReadProperty, CanWriteProperty, are you specifying the property name as a parameter, or are you letting the methods use the stack?

Andy

PatrickVD replied on Thursday, June 22, 2006

ajj3085:

Hmm, I know there was a problem because release mode makes it so that PropertyHasChanged can't get teh correct stack trace. When you raise your PropertyHasChanged, or call CanReadProperty, CanWriteProperty, are you specifying the property name as a parameter, or are you letting the methods use the stack?

Andy

Hi Andy,

I'm actually currently only trying to run the 'Csla.Tests'. I downloaded them from Rocky's website.

But as a matter of fact, I you are right on the problem. I looked at the 'BusinessBase' object's properties and it does not specify the name of the property in the 'PropertyHasChanged', 'CanReadProperty' and 'CanWriteProperty' methods.

After I added the explicit property name in the different calls to these methods, all tests ran successfully in 'Release' mode.

Thanks a lot for pointing this out to me !!

This actually brings up a few questions to me... I don't see the point of having the 'no parameter' calls in the framework if they do not work in 'Release' mode. It is generally 'Release' versions that are distributed to the 'users'...

If I understand you correctly, I would be forced to distribute 'debug' versions or always specify the name of the property when using these methods.

Thanks again... Regards,

Patrick.

DennisWelu replied on Thursday, June 22, 2006

Sounds like it might be related to the inlining problem described in the 2.0.1 change log:

Csla\Snippets

Updated property generation to mark the properties with a compiler directive to prevent inlining – thus ensuring that PropertyHasChanged(), CanReadProperty() and CanWriteProperty() work in release mode.

public int NewProperty

{

[System.Runtime.CompilerServices.MethodImpl(Runtime.CompilerServices.MethodImplOptions.NoInlining)]

get

{

CanReadProperty(true);

return newPropertyValue;

}

[System.Runtime.CompilerServices.MethodImpl(Runtime.CompilerServices.MethodImplOptions.NoInlining)]

set

{

CanWriteProperty(true);

if (!newPropertyValue.Equals(value))

{

newPropertyValue = value;

PropertyHasChanged();

}

}

}

I remember reading about this someplace else but can't remember where that was now...

RanceDowner1234 replied on Tuesday, July 11, 2006

Hey all... just thought I'd chime in since I just ran into a very similiar problem when running the release build of my app...

I've been working on an App for the last several months, and just went to compile version 1.x for release. When I used the debug version of the app I get no errors, when I used the release version I am getting a boatload of intermittent errors not only loading BusinessBase inherited classes, but also ReadOnlyBase inherited classes. I read the above post on "inlining" and tried the "NoInlining" method attributes on my gets/sets, to no avail. I also downloaded the latest CSLA 2.0.2 build, since I had been using 2.0.0 and the 2.0.1 change log mentions it fixes an issue with "inlining". But still no go....

I then turned off all optimizations by going to [Project Properties]/Compile/Advanced Compile Options and unchecking "Enable Optimizations" (note: in vb.net 2005). I only did this on my Business Objects tier, didn't have to do on the GUI tier, or any other tiers. "Enable Optimizations" seems to handle all inlining and code compacting (See following article... http://www.panopticoncentral.net/archive/2004/02/03/267.aspx). This did the trick!!!!! All the intermittent runtime errors went away and I'm sailing ever so smoothely.

I think the problem is more with .net than CSLA. I think MS needs to work on their Optimizations algorithm as it seems to go a little far, atleast in my case.

Anyway, just thought I'd post this for whoever else might be banging their head against the wall.

Csla Unit Tests - Failing when building 'Release' assemblies

PatrickVD posted on Wednesday, June 21, 2006

jwooley replied on Wednesday, June 21, 2006

PatrickVD replied on Wednesday, June 21, 2006

ajj3085 replied on Thursday, June 22, 2006

PatrickVD replied on Thursday, June 22, 2006

DennisWelu replied on Thursday, June 22, 2006

PatrickVD replied on Thursday, June 22, 2006

RanceDowner1234 replied on Tuesday, July 11, 2006

RockfordLhotka replied on Wednesday, July 12, 2006