Consider renaming to FluentAssertions.Ioc.Autofac about fluentassertions.autofac

[mkoertgen]

Sure, good idea. Having consistent package names set a good sign for the community. We will try to get to this this week, i guess /cc @ThomasMentzel.

@mkoertgen and I discussed this during our last jog out. We found out that introducing an artificial separation into "technology type" does not make sense for two reasons.

1st the separation is redundant information. ninject and autofac are ioc frameworks
2nd what would you do with frameworks like spring.net which are more complex? Is spring an ioc framework or a framework aspect oriented development or something else?

A separation only would make sense, if you have disjoined functionality which can be defined without any overlaps. In that case -and only in that case- you can have FluentAssertions.Ioc.Spring and FluentAssertions.Aop.Spring. Two api which test an entiry different aspect of a framework.

On the other hand it would be confusing to search for spring either in ioc, or in aop or somewhere else.

/cc @dennisdoomen @mkoertgen

[mkoertgen]

Hm, yes. We tried to think of use cases where adding "IoC" in the package name, namespace, etc. is helping users locating the package or has other advantages.

Maybe you are aware of scenarios where the token "IoC" is helpful?

[kevinkuszyk]

@mkoertgen and I discussed this during our last jog out. We found out that introducing an artificial separation into "technology type" does not make sense for two reasons.

@ThomasMentzel I take the point.

Maybe you are aware of scenarios where the token "IoC" is helpful?

We included Ioc in the package name because we always put our IOC config in an Project.Ioc namespace. Naming the NuGet package FluentAssertions.Ioc.Ninjectmade sense at the time. Perhaps in hindsight that was not such a good choice.

Thanks for the discussion. Do you want a copy of this issue for your project ;)

[kevinkuszyk]

Done, but I think it's too late for me to rename now.