Add dependency on System.Xml.Linq

[abatishchev]

Currently FluentAssertions.dll is tightly dependent on System.Xml.Linq.dll. Its unreferencing causes a compiler error:

The type 'XDocument' is required here and is unavailable. You must add a reference to assembly 'System.Xml.Linq, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.

Please consider re-designing to remove such necessity..

[dennisdoomen]

That's because it offers specific assertions for XML types. But what's your problem with its dependency?

[abatishchev]

I understand the reason.
But my point this is not a usual library design approach. Usually libraries have no such dependency,
I don't have real problem with this but I don't like reference what I don't need because don't use it. Here I don't use XElement assertions but have to reference both System.Xml.dll and System.Xml.Linq.dll still.

[dennisdoomen]

But that would mean splitting off the XML stuff into a dedicated assembly. However, I still don't see why this is such a big deal for you. Isn't it just a unit test project? It's not like you're going to ship that project, aren't you?

[comecme]

If FluentAssertions has this dependency, why doesn't the NuGet-package show this as a dependency?

[dennisdoomen]

It's something from the past.

[comecme]

What do you mean?

1. It the need for System.Xml.Linq something from the past?
2. It the fact that the dependencies is not present in the NuGet package from the past?

I created a new Unit Test Project (.NET Framework) in VS2019, added FluentAssertions, and tried to use it, but I had to manually add System.Xml.Linq using NuGet Package Manager.

Ah, but if I create a new MSTest Test Project (.NET Core) I do not have to ad System.Xml.Linq. I suppose that is what you mean by "something from the past" then.

I think the NuGet package should have a dependency on System.Xml.Linq for its .NETFramework v4.7 and v4.5 targets.

[dennisdoomen]

Yeah, you're right. Somehow we lost that dependency.

[comecme]

Thanks for reopening the issue, but technically, the issue I mentioned is not the same as this issue. You still won't remove the dependency on System.Xml.Linq, but you will (re)add it to the package.

[dennisdoomen]

You're right @comecme.