We tried using now v5 but unfortunately it fails on .NET Framework with the following exception:
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)
We have a solution with some .net framework apps targeted to .NET Framework 4.6 and some shared libraries targeting .NET Standard 2.0 and the exception is being thrown from the .NET Standard projects. Any ideas?
Are you using the ServiceStack.Text NuGet Package on MyGet? Can you first try clearing your NuGet cache to see if that helps:
$ nuget locals all -clear
Also you won’t be able to share .dll’s between .NET Framework and .NET Standard projects, but for .NET v4.6.1 client projects you can reference ServiceStack.Client.Core package to force it to use .NET Standard version which you will be able to share with other .NET Standard and .NET Core projects.
If it’s still an issue can you put together a stand-alone project where this fails?
Hi @mythz. I have cleared the cache and also tried a new solution but with the same outcome. Below is also a link to the new solution and if you build it you’ll see that the output contains the .NET Framework library which will be an issue when the netstandard class library will try to load and an exception is thrown.
Unfortunately there is no way to solve this because ServiceStack has a dependency on ServiceStack.Text and we can’t have both Text and Text.Core referenced at the same time. This is becoming a huge issue for us because we spent a lot of time upgrading our whole architecture to NetStandard and now we are blocked on this. Any help would be really appreciated.
You can’t mix .NET Standard only project referencing ServiceStack dependencies with a .NET Framework ServiceStack project, this was never supported. Why did you upgrade to .NET Standard if you’re not going to use .NET Core?
A .NET Framework project uses the .NET Framework dependencies whilst .NET Standard and .NET Core projects use the .NET Standard builds. You can go the other way around have a .NET Core Server sharing .NET Standard only projects with a .NET Framework .NET v4.6.1+ client by getting them to reference the .NET Standard builds in the ServiceStack.Client.Core packages, so they’re all only referencing .NET Standard dependencies.
Not sure what you’re trying to achieve with this hybrid mix of projects but if you want to maintain both .NET Standard and .NET Framework projects you can change your .csproj dependency project to create both .NET Standard 2.0 and .NET Framework .NET v4.6 builds with:
looks like I’m also running more or less in the same problem in V5.
We moving torward netstandard but we have some services/projects that rely on FullNet because of some external dependencies.
Short description:
[BaseLib | netstandard | used by all others projects | depends on: SS.Core]
[Service1 | netcoreapp | business | depends on: BaseLib ]
[Service2 | net462 | business | depends on: BaseLib and some external dependencies ]
Service1 and Service2 have no direct dependencies on SS.Core packages because they are resolved by hierachy. Both are working fine.
Since V5:
Service2 complains now that ServiceStack.dll is missing when trying to access e.g. a property from UserAuth.
I created a servicestack.core.nuspec with only targetFramework=".netstandard2.0" (so no net45) without
any other changes and everything was working fine again after referencing in BaseLib. Looks like if targetFramework=“net45”> exists, resolving of hierachy dependencies is not working - even if I add ServiceStack nuget package to the Service2 the problem exists.
I would like to avoid to target netstandard2.0 and net46 for all the base libs because this introduce other problems. For example Newtonsoft.Json is also added in the BaseLib and its working fine in all projects/services.
Any suggestions? Can SS behave like Newtonsoft.Json? Can we bring *.Core packages back with V5? Looks like its only a problem with resolving so only nuspecs need to be added.
Hey @mythz is there a reason these packages were suffixed with .Core instead of . Standard (or similar)? Just interested and checking my understanding.
I just find that a bit confusing, as the .Core packages can also be be used with .NET Framework clients, they are not exclusively for use with .NET core. I’ll get used to it. I get that they are named from the server perspective.
The purpose of the .Core packages was to only work with .NET Core. For v5 we dropped PCL builds and converted everything to .NET Standard 2.0 which we wanted to ensure had the broadest compatibility which supports .NET Core, iOS, Android, latest UWP and .NET Framework. We’re specifically continuing ti publish the .Core packages to support the additional use-case of allowing .NET Framework v4.6.1+ clients to be able to have binary coupling with .NET Core Server .dlls.
But the server libraries like ServiceStack.Core can’t be used on the .NET Framework, the .NET Standard builds was designed specifically to create a version of ServiceStack that runs on .NET Core. ServiceStack’s single code-base and implementation strives for max source code compatibility where essentially the same ServiceStack App can run on both .NET Framework and .NET Core. It was never planned or supported to run a ASP.NET Core ServiceStack App using the .NET Standard builds of ServiceStack on the .NET Framework.
It’s not a supported use-case but I expect the .NET Standard builds of Redis to be able to run on .NET Framework since it has no external dependencies and very little added support was needed to support .NET Core.
The .NET Standard builds of OrmLite is less likely to be able to run in .NET Framework since some RDBMS’s reference different packages depending of if it’s for .NET Core or .NET Framework and given the existence separate packages it’s unlikely the version that works on .NET Core will be able to run on .NET Framework.
Either way the only supported use-case we want the broadest support for are the Service Clients libraries which we’d like to be able to run on any popular client platform that supports .NET Standard 2.0.
Maybe I’m missing something. What I did now is to copy all netstandard libs (NuGet//lib/netstandard2.0/) to one large package and referenced it in the BaseLib so hierachy resolving of dependencies is working now and all services are runing without any problems (netcoreapp2.0 and net462). We are using AspNetCore (2.0.3) with netcoreapp and net462 as TargetFramework . So all services using WebHostBuilder etc. and the only one difference is the TargetFramework. If I use the official package than I’m getting compile errors like “ServiceStack.dll” is missing for net462 projects - if the package only contains netstandard2.0 everything works fine. Ofc we are using the lowest feature set of ServiceStack for netstandard and not everything thats available for .Net Framework. But this setup worked befor out-of-the-box and now I have to create my own package with only netstandard bits. netstandard2.0 libs can be used by .Net Framework (with support of NETStandard.Library and from 4.7.1 as far I understood even without the supporting lib). So the behaviour should be the same independently of the TargetFramework, or?
Applications that target .NET Framework 4.6.1 through 4.7 must deploy additional .NET Standard 2.0 support files in order to consume .NET Standard 2.0 libraries. This situation occurred because the .NET Standard 2.0 spec was finalized after .NET Framework 4.6.1 was released. .NET Framework 4.7.1 is the first .NET Framework release after .NET Standard 2.0, enabling us to provide comprehensive .NET Standard 2.0 support.
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
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.
- 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.