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
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.
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.
Thanks - now we are back again on official packages - but I had to create my custom RazorFormat as itās located in ServiceStack.Mvc . Still not got the point āthatās not supportedā as the package ServiceStack.Mvc contains netstandard bits . 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.
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:
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) }
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?
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.
- but I had to create my custom RazorFormat as itās located in ServiceStack.Mvc 
. 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.