New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

.NET Core support #133

lahma opened this Issue Oct 25, 2016 · 5 comments


None yet
3 participants

lahma commented Oct 25, 2016

This is an umbrella issue listing some things that need to be taken care of in order to get .NET Core support working.

  • make Common.Logging support .NET Core
  • upgrade NUnit
  • replace Rhino.Mocks with FakeItEasy (in progress)
  • replace packages.config with project.json
  • replace project.json with new csproj
  • investigate spring-net-futures fork and bring in commits where appropriate

@lahma lahma changed the title from .NET core support to .NET Core support Oct 25, 2016


This comment has been minimized.

gabrielsimas commented Oct 27, 2016

@lahma which branch?


This comment has been minimized.


lahma commented Oct 27, 2016

Multiple branches, I'm currently working on getting NUnit 3.5 working, which is a prequisite on branch , then I'll proceed with changing from Rhino.Mocks to FakeItEasy . These two then can go to master when working properly.

I guess initial project.json can go to master too if determined as functioning.

After that I can rebase branch on top of master again. So easier changes first and building .NET in parallel. It's a big undertaking.


This comment has been minimized.

gabrielsimas commented Oct 28, 2016

@lahma Thanks my friend.


This comment has been minimized.

luizcarlosfaria commented Sep 26, 2017

Starting a few hours, i have some data to share and i think that can help on migrating Spring.NET to .NET Standard 2.0.

Isolating only Spring.Core i have great results on basic tests.

But i have issues to work on.

Default application context load, based on ConfigurationManager infrastructure are broken overall, but XmlApplicationContext still working fine on linux. The challenge today is adapt configuration models to run ubiquitous on windows and on linux.

To make a basic funcionality i have to replace things, using fake implementations about:

  • All Common.Logging
  • System.Runtime.Remoting.RemotingServices (replaced with fake implementation)
  • System.Runtime.Remoting.RealProxy(replaced with fake implementation)
  • System.Runtime.Remoting.IRemotingTypeInfo(replaced with fake implementation)

Other changes:

  • System.Runtime.Remoting.Messaging.CallContext (replaced with ConcurrentDictionary<string, AsyncLocal>)
  • Replace many references from Type to TypeInfo
  • Remove Windows RegistryKeyConverter (and references to windows Registry)
  • Remove RGBColorConverter (maybe in i can found any replacement for that)
  • --

    Later, this week i'll share the project. It's not a fork, is a sugar to explain that is possible, and we are near to solve that. We are going to .NET Core! It's awesome!


    Classes, Configuration, Using
    spring net-on-dotnetstandard2

    Docker Instance and MachineName

    spring net-on-dotnetstandard2-docker

    AOP is now working too

    spring net-on-dotnetstandard2-aop


This comment has been minimized.


lahma commented Sep 30, 2018

Following projects now compile under netstandard2.0:

  • Spring.Aop
  • Spring.Core
  • Spring.Data
  • Spring.Messaging
  • Spring.Testing.NUnit

Basically things not supported in netstandard/.NET Core have been left out of compilation (remoting, enterprise services etc).

Closing this as the main steps have been completed. There probably are more improvements that can be made as separate issues.

@lahma lahma closed this Sep 30, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment