Failed to resolve assembly.

[pms1969]

Hi. Firstly, thanks for your efforts. By far the best approach I've seen so far in this space.

I've got a rather large solution with many interdependencies between projects. When I run my tests, for almost all of the projects I see the following error:

tests/MyAssembly.Tests
/src/packages/coverlet.msbuild/1.0.1/build/netstandard2.0/coverlet.msbuild.targets(7,5): error : Failed to resolve assembly: 'AnotherAssembly, Version=0.1.0.0, Culture=neutral, PublicKeyToken=null' [/src/tests/MyAssembly.Tests/MyAssembly.Tests.csproj]

obviously sanitised.

AnotherAssembly isn't a direct dependency of the TestProject, but is built - to the version specified, and is in the bin directory along with all the other dependencies.

Any idea what might be wrong? Or better still, teach a bloke to fish: Is there some way of turning up the logging on coverlet to help debug? (can't actually say I've seen anything in the code which looks like it might help with this, but I haven't specifically been looking for it. will look now)

Cheers,
Paul

[tonerdo]

Debug logging is something I've been hoping to add to coverlet. Do you have a simple repro project I can take a look at?

[pms1969]

Unfortunately not. I did try to set one up, but not knowing what the problem was, meant I couldn't get the test repo into the same state as our production one. :-( And I can't hand that over. :-s

I've added some Console.WriteLines in the spots I think will give me some kind of understanding and am in the process of trying to compile and publish locally. Will let you know how I get on.

[pms1969]

I'm not there yet, but here's an update:
It's happening on the module.Write(stream) line in Instrumenter: InstrumentModule method.

So basically inside Cecil.

I'm working on a theory. If it pans out, I'll report back. Otherwise, any thoughts?

[tonerdo]

My best guess is that when Cecil rewrites the assembly it misses out the references but I can't be so sure. Lemme know how your theory pans out

[pms1969]

Theory didn't pan out. Looks like it's 2 specific Assemblies that have the issue. Ensuring that the dependency it's failing to find is instrumented first didn't do anything to improve the situation, so still stumbling around in the dark.

[pms1969]

Just opening and re-writing the assemblies with mono.cecil causes the error. Something fishy there :-( Might take me a while to track down.

[tonerdo]

Can I see the unsanitized error output?

[pms1969]

@tonerdo I could, but it's literally the same as what you see. It's just the assembly names that were changed.

As it turns out. I have been able to track down the error, and come up with a solution. mono.cecil's assembly resolver doesn't search the module path. Some context here: (jbevain/cecil#306) and (jbevain/cecil#487). By taking the DotnetAssemblyResolver that @uhrm outlines in issue 306, and modifying it a touch, I was able to get what I needed. I've literally just got that working, so I'll try and get it tidied up, and get a PR back to you shortly.

[tonerdo]

@pms1969 #23 has been merged in

[Structed]

If still running into this issue though you consume a package which has the fix included, this fixed it for me: #33 (comment)