For the same reason that we're doing #102 we should split the actual core femah library from its other dependencies.
By definition the Femah Admin UI and Femah API are only usable when Femah is hosted in a web application. It would be a lot of work now to refactor those parts out to a Femah.Web repo and Nuget package and create the build for another Nuget package, so instead, assuming that initial uptake will be by web developers we will simply retire the Femah.Core nuget package and publish a Femah.Web nuget package instead.
Justification
We don't want to force any early Femah adopters to consume a totally different nuget package if we were to rip the web related stuff out of Femah.Core in the future.
When we're ready to build in new features for Windows applications, WPF, services etc, we can then refactor the core Femah library out into another repository and publish a new Femah.Core nuget package that everything then depends on.
For the same reason that we're doing #102 we should split the actual core femah library from its other dependencies.
By definition the Femah Admin UI and Femah API are only usable when Femah is hosted in a web application. It would be a lot of work now to refactor those parts out to a Femah.Web repo and Nuget package and create the build for another Nuget package, so instead, assuming that initial uptake will be by web developers we will simply retire the
Femah.Corenuget package and publish aFemah.Webnuget package instead.Justification
We don't want to force any early Femah adopters to consume a totally different nuget package if we were to rip the web related stuff out of Femah.Core in the future.
When we're ready to build in new features for Windows applications, WPF, services etc, we can then refactor the core Femah library out into another repository and publish a new
Femah.Corenuget package that everything then depends on.