.Net Core Service Stack API reference a CredentialsAuthProvider from a .Net Framework 4.5 API project

ServiceStack Authentication
1

Hi all,

We are starting on a new .Net Core Service Stack API project which needs to work along side our current .Net business logic and be able to reuse our existing credentials auth provider.

I tried referencing the CredentialsAuthProvider from a .Net 4.5 project and I keep getting errors that I need to reference ServiceStack 5.0.0. This .Net 4.5 project was also upgraded to the latest version of Service Stack. This .Net 4.5 project is like a shared library of api related code that is currently used by ASP.Net Service Stack apis.

Please advise if this is even possible or is my only solution to move these files across to a .Net core project.

Thanks a lot for your assistance!
Leeny

2

If you want to share the same project between .NET Framework and .NET Core projects you need to multi-target.

The Hello Mobile project shows an example of sharing the same project referenced from multiple projects, e.g. here’s how the ServiceModel project is multi-targeted:

Please see this answer for more details: https://stackoverflow.com/a/49417944/85785

3

Thanks for your prompt response. However, I have not had much luck with multitargeting .netstandard 2.0 and .net 4.5 as VS crashes horribly and then cannot open the project. I have spent nearly a day and nothing sees to resolve this.

Are there any alternatives? Is the response in the SO link with regards to ServiceStack.Core packages still relevant?

4

The HelloMobile project demonstrates a working example referencing the same multi-targeted ServiceModel, Server.Common and Shared.Client Gateway projects referenced in 4 different AppHosts AppHosts:

I recommend starting from an empty working project, then slowly copy everything you want into the working project so you can identify when something causes it to break.

The .Core projects only contain .NET Standard 2.0 builds which can only be used in ASP.NET Core projects running on the .NET Framework and .NET Core platforms.

The only other solution is to copy the source code into the different projects in order to decouple any binary dependencies.

5

Thank you Demis. Appreciate it.

If we decide to start with a .Net Core API (with Service Stack) running on the full .Net Framework, is it going to provide any benefits to us as opposed to an ASP.Net API with Service Stack as we have currently?

Thanks a lot,

Leeny

6

It lets you run the new-style ASP.NET Core Web Apps on the .NET Framework where you will be able to use existing (non System.Web) .NET Framework .dlls. The disadvantages vs .NET Core is that its slower and doesn’t run cross-platform.

ServiceStack has good feature parity across all platforms, although there are some features which are tied to System.Web ASP.NET that can’t run on the new ASP.NET Core Web Framework.

The reason to create new ServiceStack Apps with ASP.NET Core is due to it being the actively developed platform where Microsoft is investing most of their efforts into. It’s also better integrated with ServiceStack since ServiceStack effectively just runs as .NET Core middleware so you’ll be better able to utilize any external ASP.NET Core middleware within the same App and share the same routing space as ServiceStack (Couldn’t do this with classic ASP.NET).

My recommendation is unless you have dependencies that need classic System.Web ASP.NET that you should use ASP.NET Core for new Greenfield Apps. Whether you run on .NET Core or .NET Framework is dependent on whether you need to reference .NET Framework .dll’s as .NET Core is faster and lets you deploy and host on Linux (which is our preference for new Apps).

7

Thank you. This makes sense now.