Csla.resources file not found exception in unit testing

Michael posted on Monday, January 10, 2011

Hi everyone

On the very first test in a batch of MbUnit unit tests, regardless of which tests are selected, I get a System.IO.FileNotFoundException: Could not load file or assembly 'Csla.resources, Version=3.8.3.0, Culture=en, PublicKeyToken=93be5fdc093e4c30'

Every test after this runs fine. I can get around this by having a blank test execute before the real tests, but naturally I'd prefer to solve the problem. This has only recently started happening, either after upgrading Gallio/MbUnit or moving to Visual Studio 2010 (compiling to .NET 3.5).

I'm posting this to both the CSLA forum and Gallio Dev Google Group.

The stack track is listed below.

Kind regards
Michael

JonnyBee replied on Monday, January 10, 2011

Hi Michael,

Does your app use a custom assembly resolver? 

The problem is loading Csla.resources for culture 'en'. Since this is the default language it is compiled into Csla.dll.

So check the output folder structure where your unit tests run:

1. Verifiy there is no csla.resources.dll in the bin folder
2. Verify there is no .\en\csla.resources.dll in the bin folder.

If all else fails - use filemon or procmon from Sysinternals to trace file access and check where/what is csla.resources attempted to be  loaded.

Michael replied on Monday, January 10, 2011

Hi Jonny

There is no csla.resources.dll in the bin or \en folder.

The exception is thrown in the CSLA DataPortal assembly resolver, which is for the serialization bug workaround. It is triggered by a CommonRule. The funny thing is, it doesn't try to load the assembly on the subsequent tests.

Regards
Michael

RockfordLhotka replied on Tuesday, January 11, 2011

It could have something to do with how their test framework is initializing the AppDomain that runs the test code. This doesn't happen with mstest or nunit - at least not in any of the CSLA tests, or the tests Magenic has built for various customers.

Serialization, AppDomain creation, and type resolution are tricky - hard to get right. CSLA includes that resolution code to address the approaches taken by IIS and COM+, so it seems likely that this unit test framework is using some model similar to those technologies - but obviously not quite the same.

Michael replied on Tuesday, January 11, 2011

Hi Rocky

I'm still awaiting a reply from the Gallio dev guys. It may be something they changed in the latest release. I'll post any relevant answers here also in case someone else runs into the problem.

Regards
Michael

Michael replied on Friday, July 22, 2011

Hi Rocky and Jonny

We are porting our application from AutoCAD 2011 to 2012. We are still supporting both. AutoCAD 2011 runs .NET 3.5; 2012 runs 4.0. We are still using CSLA 3.8.3.

In 2012, I am getting this same exception whenever the CSLA resources is accessed. It's looking for Csla.resources, Version=3.8.3.0, Culture=en-US. I have found two temporary solutions:

• Change CSLA's neutral language from none to English (United States); or
• Manually load a non-English Csla.resources.dll file when our application is starting up. I have no idea why this even works! All the expected strings used from CSLA's resource file are still in English. If I load one of these other resource assemblies after getting the above exception, the trick does not work.

I have reproduced the problem on my dev machine running Win 7 x64, and on Win 7 x86 and x64 virtual machines. It only happens inside the AutoCAD 2012 process; in our own separate exe, it works fine. Changing the Windows region and language to English (United States) makes no difference.

I will be asking Autodesk for their thoughts also, but I'd really appreciate some help.

Kind regards
Michael

Michael replied on Saturday, July 23, 2011

OK, I have found a more tolerable solution. In the serialisation workaround, if the requested assembly name contains "Csla.resources, Version=3.8.3.0, Culture=en" I don't try to load the assembly and return null.