Upgrade FakeitEasy to Latest version.

[OnurGumus]

Currently the nuget package of Autofixture.FakeitEasy uses FakeItEasy, Version=1.7.4109.1, Culture=neutral, PublicKeyToken=eff28e2146d5fd2c

This version is very old. Also When I turn on Live Unit Testing with Visual Studio I am getting this error:
System.IO.FileLoadException: Could not load file or assembly 'FakeItEasy, Version=1.7.4109.1, Culture=neutral, PublicKeyToken=eff28e2146d5fd2c' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Putting an assembly binding redirection doesn't fix the problem. I think it just makes sense to upgrade this to the latest version.

[zvirja]

Could you please share the Minimal Example of the solution, so I can try to reproduce it?

Basically, everything should work fine because of the assembly binding redirection. It seems that it isn't configured properly on your solution. Actually, AutoFixture project has a test that we are compatible with v4.0.0. While that is not the latest version, it's the same major version you have.

Putting an assembly binding redirection doesn't fix the problem. I think it just makes sense to upgrade this to the latest version.

We have new releases of the FakeItEasy each couple of months (if not less). It will be impossible to track those updates and release a new version of glue library each time the dependent assembly is updated. Therefore, I don't see much sense to do one-time upgrade as your solution will still become broken in a month.

We should focus on understanding why assembly binding redirection is not working in your case and fix that.

[OnurGumus]

@zvirja I added the binding redirection. If you read the issue, this is related to "Live Unit Testing" which are different than regular tests. Basically Live unit tests, run in separate process at background and perhaps then that process somehow gets confused. I doubt your tests can cover such scenario without you actually trying. I have copied the source your helper to my project and compiled it with the latest fake it easy, then live unit tests started to work fine. You need Visual Studio Enterprise edition for live unit testing. If you have it and want to try I can add a minimal example.

[zvirja]

If you read the issue, this is related to "Live Unit Testing" which are different than regular tests.

Could you confirm that you observe no issues, if you use other runners (e.g. dotnet test, VS runner, R# runner, console runner) for the project you observe issue with?

You need Visual Studio Enterprise edition for live unit testing.

Yep, I know and I don't have that subscription, unfortunately.

Before, I want to ensure that issue is specific to the live testing and doesn't happen without it.

[OnurGumus]

Yes I can say this issue is strictly about live unit testing. It works fine with vsrunner. On the other hand, I am curious about your motivation for sticking with a very old fakeiteasy version.

[zvirja]

Yes I can say this issue is strictly about live unit testing. It works fine with vsrunner.

In this case you probably need to raise that issue to MS, as assembly binding redirection is a very common feature to live without it. As you might see, AutoFixture relies on the officially supported behavior and it's unlikely we can do something about this.

On the other hand, I am curious about your motivation for sticking with a very old fakeiteasy version.

First of all pay attention that it will not solve your issue in a long run term, as I mentioned here. Besides that I see a few other reasons to not update the dependency:

1. It simply brings no value. We don't need the newly appeared API, so we could support all the range of versions. Also the support of old versions costs almost nothing to us (so far it was so).
2. With current approach we support the wider range of clients. Unfortunately, we don't have statistics to say how many clients we'll stop to support if we abandon the older versions.
3. Changing the FakeItEasy dependency range to stricter would be a breaking change. Meaning, that we'll need to release AutoFixture 5 to apply that change.

However, the main point is the first one - it brings no value. If we start to have strong reasons - we could review our strategy.

[OnurGumus]

This may be an issue from Microsoft side, but basically what you are saying people who use live unit tests cannot use your library with live unit testing facility because you are preferring to keep few percent happy instead.
Also this will solve the issue for long time because FakeItEasy's assembly version most likely to stay same for the next couple of years at least. And even if it changes, perhaps by that time Live Unit Testing will not give this error, or this issue could be related only with that very old fakeiteasy thing.
Fine. This is a non issue for me as I have my own fork of that lib now. You may close the issue as you like.

[zvirja]

This may be an issue from Microsoft side, but basically what you are saying people who use live unit tests cannot use your library with live unit testing facility because you are preferring to keep few percent happy instead.

I do understand you confusion and I'm sorry that you cannot the library. However, it doesn't seem that FakeItEasy dependency update is the right strategy. We have a plenty of other glue libraries (Moq, NSubstitute, xunit1/2, NUnit2/3) and if we start to follow the same strategy for them, we'll quickly drop a substantial part of supported libraries. Fix for the issue on our side will create a mess and that mess will be permanent. On other hand, MS will fix that issue in the upcoming update and that performed mess will stop to bring any value at all.

This is a non issue for me as I have my own fork of that lib now

Have you tried to report the issue somewhere or google for the workaround? I believe you are not the first one who observed it (as redirection is a quite common feature).

[zvirja]

@frblondin As far as I remember, you have VS Enterprise 😉 If so, could you please check this issue and assist with the workaround? It might be handy for other clients who face the same issue.

Let me know if you are busy or don't have VS Enterprise.

[frblondin]

Unfortuntaly I'm not using VS Enterprise :-(
I'd suggest using auto binding redirections as documented here.

Also make sure that binding redirects are defined on the unit test assembly directly.

To me, if live unit testing doesn't manage correctly binding redirects it's clearly not an AutoFixture issue.

[zvirja]

@frblondin Oops, sorry for confusing 😅 Thanks for the nice hints - I absolutely agree with you! 👍

@Kralizek Ok, it seems you should have VS Enterprise. Could you please review this issue whether you can test and advise something?

Thanks guys 😉

[Kralizek]

@zvirja do you have a test project I can check out and test? I don't use FakeItEasy and it would take some time for me to get a workable test :)

[zvirja]

Well, I also don't use it, however probably we can use it like NSubstitute or Moq:

1. Install AutoFixture + latest FakeItEasy + AutoFakeItEasy.
2. Customize fixture using AutoFakeItEasyCustomization.
3. Request a custom interface from AutoFixture (use fixture.Create<ICustom>()).

As result, it should return a mock, rather than fail with an exception :)

[Kralizek]

I'll try it from home :)

[zvirja]

@Kralizek Any chance to try? 😊

[Kralizek]

@zvirja sorry for the delay!

Here is a gist https://gist.github.com/Kralizek/1434867d7ca4018c7c5a92e4951b22a8

[zvirja]

@Kralizek Thanks a lot! Yep, the scenario is completely right. I suppose that the highlighted green marks are for the live testing (as everything works fine for the regular testing) 😄

@OnurGumus Could you please follow up on this and clarify how your scenario differs from the tested one?

[OnurGumus]

@zvirja I checked it again. With binding redirections of FakeItEasy it works. Perhaps I made typo with the public key in my previous attempt. Apologies for wasting your time guys :(
Also I heard FakeItEasy 5 is on the way. So my assumption on assembly version 4.0.0.0 will be hold for a while is also wrong I think. Having that said I still don't see your motivation with sticking a version that much old.

[zvirja]

@OnurGumus Thanks for the confirmation, I'm happy to know that everything works fine for you! 😊

@Kralizek One more time thanks for your assistance with with VS Enterprise test 🙏