Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error

Frequent FileLoadException when running tests that call into modified assembly
MarcChu
#1 Posted : Tuesday, June 18, 2019 1:17:38 PM(UTC)
Rank: Member

Groups: Registered
Joined: 9/26/2014(UTC)
Posts: 12

Thanks: 2 times
Was thanked: 1 time(s) in 1 post(s)
We have a large solution, and one particular project that seems to cause problems. This project ("Woti.Xift.Core") contains many common types, and so is taken as a dependency (directly or indirectly) by most other projects in the solution. It seems that whenever this project is modified, the tests that depend on it fail, throwing a System.IO.FileLoadException. Here is a representative stack trace:

Quote:
System.IO.FileLoadException : Could not load file or assembly 'WOTI.Xift.Core, Version=5.10.0.14171, Culture=neutral, PublicKeyToken=null' or one of its dependencies. A strongly-named assembly is required. (Exception from HRESULT: 0x80131044)
at Castle.Proxies.Invocations.IScribeFormService_GetFormViewModel.InvokeMethodOnTarget()
at Castle.DynamicProxy.AbstractInvocation.Proceed()
at Xift.Infrastructure.Aop.UnitOfWorkInterceptor.TryInvokeMethod(IInvocation invocation, String targetDatabaseName, Boolean isQuery, Boolean isReadonlyOperation) in C:\Xift\Libraries\Infrastructure\Aop\UnitOfWorkInterceptor.cs:line 210
at Xift.Infrastructure.Aop.UnitOfWorkInterceptor.Intercept(IInvocation invocation) in C:\Xift\Libraries\Infrastructure\Aop\UnitOfWorkInterceptor.cs:line 83
at Castle.DynamicProxy.AbstractInvocation.Proceed()
at Castle.Proxies.IScribeFormServiceProxy.GetFormViewModel(FormViewParams param)
at Scribe.IntegrationTests.ScribeFormServiceTests.FormViewModelIsCorrect() in C:\Xift\Tests\Scribe.IntegrationTests\ScribeFormServiceTests.cs:line 67


The only way to resolve this is to do something that forces a rebuild and reload of Woti.Xift.Core, e.g. restart the NCrunch engine, reload and rebuild Woti.Xift.Core, etc. This is really annoying, as either one of these options essentially requires a rebuild of every single project.

This error only occurs in the context of running tests in NCrunch, and no where else in our system.

A little background: we use AOP (method intercepters) using Autofac, which in turn uses Castle.DynamicProxy. Autofac, at runtime, creates a proxy for our intercepted object, calls the interception logic, then invokes the actual method on our actual object. It's at this point where the failure seems to happen.

My best guess as to what's going on is that there's some sort of conflict as to which version of the Core assembly should be used. I can confirm that the above test project references both Core, as well as many dependencies that themselves reference Core. Here's a mock-up of the dependency graph (sorry, whitespace isn't being preserved, so it might not be as clear as I'd like).

Test Project ---> Core
|
---->web app project -----> "Infrastructure" project -----> Autofac
| |
| ------> Castle.Core
| |
| ------> Core
|
-------> X ------> Core
|
-------> Y -------> Z ------->Core

I'm looking for any solution available to make this problem go away.
Remco
#2 Posted : Tuesday, June 18, 2019 11:43:37 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 5,692

Thanks: 738 times
Was thanked: 944 time(s) in 899 post(s)
Hi, thanks for sharing this issue.

Looking at the version number of the project, is it possible that this version number is being automatically incremented or somehow changed on each build? If so, does disabling the auto increment help?

Another thing to check is whether you have the prevent signing of assembly setting enabled for any of your projects. If so, you should probably turn this on for ALL of your projects. It may be worth doing this regardless to see if it resolves the issue.

Something else worth trying is to add an 'implicit' dependency from each of your test projects to the WOTI.Xift.Core project using implicit project dependencies. As the types in this assembly are being loaded dynamically, there may be a lack of static link causing resolution issues.
MarcChu
#3 Posted : Friday, July 12, 2019 12:44:07 PM(UTC)
Rank: Member

Groups: Registered
Joined: 9/26/2014(UTC)
Posts: 12

Thanks: 2 times
Was thanked: 1 time(s) in 1 post(s)
Sorry for the delay in responding to this.

Yes, we definitely do auto-increment our versions on build. I didn't try disabling this, as it's done through an AssemblyVersionAttribute in a shared AssemblyInfo.cs, and would affect every project in our solution. And I doubt this is the sort of scenario that would cause us to change that.

We have many, many projects, so I didn't confirm that "prevent signing of assembly" isn't enabled for any projects, but I think it's safe to assume that we wouldn't have seen any reason to enable it.

Adding the Core project as implicit dependency did seem to eliminate this problem...in regard to Core. But I'm now intermittently getting this problem with other assemblies. I had wondered why Core was the only assembly displaying this problem, but maybe it was just the FIRST one blocking tests, since it's the one that is most depended upon by other assemblies.

It would be rather annoying if this leads to having to progressively add more and more assemblies as implicit dependencies as they pop up (due to the auto-incrementing of versions?). Given all this, is there another better solution that might be used?
Remco
#4 Posted : Friday, July 12, 2019 11:59:53 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 5,692

Thanks: 738 times
Was thanked: 944 time(s) in 899 post(s)
The auto incrementing of versions is very likely to be causing this problem. You'll want to suppress this for your NCrunch build, as changing the version number of an assembly will invalidate anything that references it.

Turning on the 'Copy referenced assemblies to workspace' NCrunch configuration setting for ALL the projects in your solution will likely be an effective workaround, but this will impact NCrunch performance.

Placing an '#if !NCRUNCH' block around your AssemblyVersionAttribute declarations will probably disable the auto increment inside the NCrunch builds and may resolve the problem. If you're using a build step to do the auto increment, making this conditional on NCrunch not being resident will likely work too.
Users browsing this topic
Guest
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

YAF | YAF © 2003-2011, Yet Another Forum.NET
This page was generated in 0.043 seconds.