MyGet pre-release packages upgraded to v5

If it is possible that the .NET Standard builds of OrmLite and OrmLite.SqlServer could run on the .NET Framework that would be helpful for me.

Our .NET 4.6.1 Win Forms app (a SS client) has dependencies on our Proj.Logic and Proj.ServiceModel libraries. The ServiceStack.Client.Core package means the same Proj.ServiceModel DLL (which has a dependency on ServiceStack.Client.dll) can be shared by the server and client apps. However Proj.Logic has a dependency on ServiceStack.OrmLite.SqlServer so no luck there. If ServiceStack.OrmLite.SqlServer.Core is never going to happen I’ll just go down the multi-targeting route as I appreciate this probably isn’t a typical use-case :smile:

I’ve just added .NET Standard only packages for:

  • ServiceStack.OrmLite.Core
  • ServiceStack.OrmLite.Sqlite.Core
  • ServiceStack.OrmLite.SqlServer.Core
  • ServiceStack.OrmLite.PostgreSQL.Core
  • ServiceStack.OrmLite.MySql.Core
  • ServiceStack.OrmLite.MySqlConnector.Core
  • ServiceStack.Common.Core
  • ServiceStack.Redis.Core
  • ServiceStack.Core
  • ServiceStack.Server.Core
  • ServiceStack.Aws.Core

Whether it runs on .NET Framework will still be dependent on the external NuGet packages if any, I’m assuming Microsoft packages will support it and PostgreSQL + MySqlConnector use the same NuGet package so there’s a good chance they’ll support it as well. These packages are available from v5.0.1 that’s now available on MyGet.

2 Likes

Awesome - big thx. :rocket:

Is it possible to add this packages too?

  • ServiceStack.Mvc.Core
  • ServiceStack.Aws.Core

This would allow us to get rid of creating own packages and would also provide a full option to use AspCore + SS.Core with .Net Framework.

This still doesn’t mean you can run .NET Standard of ServiceStack on .NET Framework, that’s not supported.

These packages are only if your shared libraries needs to reference types in the server libraries. MVC shouldn’t be referenced by shared libraries, but I’ve just added ServiceStack.Aws.Core which is now available on MyGet as well.

1 Like

Thanks - now we are back again on official packages :+1: - but I had to create my custom RazorFormat as it’s located in ServiceStack.Mvc :smile:. Still not got the point “that’s not supported” as the package ServiceStack.Mvc contains netstandard bits :flushed:. Is it a license issue - so no official support? We basically not using .NET Standard of ServiceStack on .NET Framework, we use .NET Standard of ServiceStack with .NET Standard. All “Hosts” are using the same BaseLib.Hosting and some of them are just running on .net471 (but still with AspCore - so nothing changes and everything is done the same way), instead of netcoreapp, with references to external .NET Framework libs. Maybe it’s really not typical use-case but it would be really helpful to have ServiceStack.Mvc.Core, too.

The issue is that the main ServiceStack NuGet packages contains 2 builds:

  • net45 - Which can only run ASP.NET Web Apps or Self-Hosting HttpListener App Hosts
  • netstandard2.0 - Which can only run .NET Core Web Apps

This is a hard limitation from consolidating the .NET Core version into the main ServiceStack NuGet packages since installing the ServiceStack NuGet package in a .NET Framework project will always bring the .NET Framework version of ServiceStack which can only run on ASP.NET or HttpListener Self Hosts. Our goal with .NET Core was to make it as easy as possible to port from .NET Framework to .NET Core by maximizing source code compatibility.

This means it’s not possible for Customers who want to move their libraries to .NET Standard 2.0 builds but still run on the classic ASP.NET Framework because the .NET Standard 2.0 does not include ASP.NET Framework classes so the .NET Standard build of ServiceStack cannot run on the classic ASP.NET Framework.

We also didn’t expect running a .NET Core App on the .NET Framework to be a popular use-case so after we consolidated the .NET Core builds into the main ServiceStack NuGet packages we deprecated the .Core packages as everyone running ServiceStack on .NET Core should now be using the main NuGet packages.

But as it looks running ASP.NET Core Apps on the .NET Framework may turn out to be a popular use-case I’ve restored all the .Core packages which now contains the .NET Standard 2.0 builds of ServiceStack so these new .Core packages are now available on MyGet:

  • ServiceStack.Mvc.Core
  • ServiceStack.RabbitMq.Core
  • ServiceStack.Api.OpenApi.Core
  • ServiceStack.Admin.Core
  • ServiceStack.Azure.Core
  • ServiceStack.Stripe.Core

I’ve also created a NetFrameworkCoreTemplates GitHub organization containing popular starting templates for running ASP.NET Core Apps on .NET Framework (default v4.7) which all have the -corefx suffix:

We’ll make these new templates available in the dotnet-new templating tool tomorrow.

I’d also want to make clear that support for running .NET Core Apps on .NET Framework are subject to the .NET Standard builds of external NuGet package dependencies also supporting running on .NET Framework.

2 Likes

Ok these templates are now available in dotnet-new but as it required adding the new NetFrameworkCoreTemplates GitHub Organization config source, it will require upgrading @servicestack/cli to 1.0.1 with:

$ npm uninstall -g @servicestack/cli
$ npm install -g @servicestack/cli

After which running dotnet-new will include the list of new .NET Framework ASP.NET Core templates:

1 Like

This topic is now unpinned. It will no longer appear at the top of its category.

After reading the above, I’m confused. I have two projects:
MyEndpoint and MyContracts.

  • MyEndpoint is a .NET Framework project that uses ORMLite to interact with databases and has a project reference to MyContracts since some of the objects it is storing are public. It also has a NuGet of OrmLite (which brings with it ServiceStack Interfaces)
  • MyContracts is a class library I distribute and is a .NET Standard project so that those who consume it can do so in .NET Framework or .NET Core projects. In MyContracts, I use ServiceStack Interfaces.

I’ve tried using both the regular Interfaces and the Interfaces.Core in MyContracts, but I can’t get around the runtime error mentioned above:

Could not load file or assembly 'ServiceStack.Text, Version=5.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Am I supposed to change the OrmLite reference in MyEndpoint (a .NET Framework project) to be the .Core version?

After spending the last hour converting all 20 projects ServiceStack references to .Core versions (very odd that I use the .Core version for the Framework projects), I am ‘almost’ out of the woods; 19 of the 20 project run correctly now. I need to expand the example above now to explain the problem.

In addition to MyEndpoint and MyContracts, I also have MyAPI. MyAPI is a ServiceStack .NET Framework API. It too needs a reference to MyContracts. And therein is the problem. Unless all the ServiceStack packages in the API are .NET Core, I get the exception above at runtime. However, if I convert them all to .NET Core, I get this issue:

The type or namespace name ‘AspNet’ does not exist in the namespace ‘ServiceStack.Host’ (are you missing an assembly reference?)

using ServiceStack.Host.AspNet;
  Plugins.Add(new RequestLogsFeature {
                    RequestLogger = new MyRequestLogger(dbFactory.Open()),                
                    ExcludeRequestDtoTypes = new System.Type[] { typeof(OpenApiSpecification), typeof(RequestLogs), typeof(AspNetRequest) }

@mythz - what to do?

I don’t know how to be any clearer than what I have already been, I’ve answered this issue recently with the only 2 options available when trying to share projects between .NET Standard and .NET Framework: https://stackoverflow.com/a/49417944/85785

You still can’t access .NET Framework specific functionality in .NET Standard builds. Please checkout the Hello Mobile multiple Server AppHosts for a reference example of sharing the same multi targeted projects between multiple AppHosts.

Please just take a minute to read the issue here - I understand you feel like you’ve explained this enough already. I have read through everything above, plus the posts you linked to.

Per the guidance you gave above - I followed the supported option of converting every reference to .Core in all of my Framework projects. That has left me with the issue I described above. Your .Core version of ServiceStack.Host doesn’t have an AspNet or AspNewRequest object. As such, how do I support the above ExcludeRequestDtoType in my declaration of the RequestLogsFeature in my Asp.Net Framework project?

Run ASP.NET Core Apps on the .NET Framework

  • net45 - Contains support for running ASP.NET Web or Self-Hosting HttpListener App Hosts
  • netstandard2.0 - Contains support for only running on ASP.NET Core App Hosts

Only the .NET v4.5 builds contains support for hosting on classic ASP.NET Hosts (i.e. AspNetRequest/AspNetResponse). You cannot use .NET Standard builds on ServiceStack in classic ASP.NET Web projects, the build does not physically contain the dependencies and functionality for it - this is simply not available in .NET Standard 2.0 (which only covers running ASP.NET Core Apps).

So if you need to share any dependencies/projects from a classic ASP.NET Web project with .NET Standard or .NET Core targets you need to multi-target.

Classic ASP.NET Web App = ASP.NET before .NET Core, e.g. with global.asax

ASP.NET Core App = the new Web Framework for developing Web Apps, e.g with Startup.cs

If you want to host on Classic ASP.NET you must multi-target.

If you’re hosting on ASP.NET Core you can also use and share .Core projects with v4.6.1+ and .NET Core projects provided you don’t need any .NET Framework specific functionality, like the old classic ASP.NET Web HttpRequest/HttpResponse/HttpContext classes.