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

I wish to join this project to help get it going again #144

Open
jeffreyschultz opened this Issue Oct 27, 2017 · 97 comments

Comments

Projects
None yet
@jeffreyschultz

jeffreyschultz commented Oct 27, 2017

Like the title says, I would like to join the project and help get development started again. There is still a need for Spring.NET in the .NET ecosystem, and it's a shame to see this wonderful code base collect dust.

I have already forked the repo in GitHub, and am wondering what is the state of things that need to be worked? I have used both Spring.NET and Spring, so I have a bit of familiarity with them, which is good, but I have only recently started to poke around the source code.

Also, who is available to provide guidance on implementation decisions and deal with pull requests? Anyone?

@gergroen

This comment has been minimized.

gergroen commented Oct 27, 2017

I am available to contribute. I have used Spring.NET for a while and like it a lot.
Maybe we can focus us on the ".NET Core support" #133
And create some documentation on the github wiki. For example a getting started guide with the config in code. Because i think a lot of users create there configuration in xml files instead of in code.

@jeffreyschultz

This comment has been minimized.

jeffreyschultz commented Oct 27, 2017

At the moment I have included Core, AOP, Web, and Mvc5 into my solution and am attempting to work through a couple minor issues that I have encountered. I am maintaining the existing Spring.NET solution structure by storing it under a folder in my project tree, and am selectively referencing projects into the solution. I think this will go a long way with regards to testing integration with my application, while being able to debug issues that I encounter.

I will also be sure to push changes I make to my fork on GitHub.

Until I can get further direction on things to do this will have to do for now. I think there is a JIRA for this project over at Spring Source, so I will have to take a look at that, too.

@sbohlen

This comment has been minimized.

Collaborator

sbohlen commented Oct 27, 2017

@cptully

This comment has been minimized.

cptully commented Oct 28, 2017

@lahma

This comment has been minimized.

Member

lahma commented Oct 28, 2017

Maybe I'll try to invest some time too. As I've said earlier I have some branches collecting dust that should be completed in the way forward. At least converting from Rhino.Mocks to FakeItEasy will allow as cleaner road towards .NET Core.

@guryanovev

This comment has been minimized.

guryanovev commented Oct 28, 2017

Hey this sounds really exciting, "Spring.NET" was a synonym of "best practice" for me for about 10 years and it was a really hard decision to move to another IoC container. But we had to do it as Spring.NET really outdated. It would be great if you guys get project back to life. But if to talk about actual project tasks, Core support is cool, but honestly, there are a lot of other things that should be done to get Spring.NET back to track. For example, XML looks just ridiculous our days, no one would use it. Modern applications register dozens of dependencies and a preferred way is to do it in code (using lambdas) and to do it automatically everywhere, where it's possible. Also, I think supporting of ancient .NET versions is a road to nowhere as even MS abandoned them. I'm saying that because Spring tried to support .NET 1 and 2 for so long blocking usages of 3.5 features in core modules.

@jeffreyschultz

This comment has been minimized.

jeffreyschultz commented Oct 28, 2017

I am one of those people that’s loves XML. Sorry, but I think XML really has a place in Spring.NET, and I would really like to see more support for generalized XML authoring and consumption.

That being said, any way of configuring a container should be nothing more than a source of configuration definitions. The XML config factory, or fluent configuration, shouldn’t be an intrinsic component of the container. Use what you need and leave the rest behind. As for me, not supporting XML is a no-go.

I think the reason that XML isn’t bigger in the .NET community is because suppor for it is kind of crappy, which means that you end up with crappy implementations that add more of a burden to developers and end consumers. I would like to see this change.

@lahma

This comment has been minimized.

Member

lahma commented Oct 28, 2017

I've used both XML and code configuration and they both have their merits. My Msc work was about product lines and XML played key role when defining readable variation points. Now using CodeConfig mostly to wire things up. XML is not going away and I wonder how the current CodeConfig would not meet requirements. A fee more lines to write compared to some fluent interfaces or auto scanning, I prefer the explicit wiring via CodeConfig, no guesses what is being used.

@jeffreyschultz

This comment has been minimized.

jeffreyschultz commented Oct 29, 2017

I have used both as well, but I feel that configuration stops being "configuration" once you write it in code. That's kind of the point of external declarative configuration schemes, there is already a lot of code to deal with, so the goal is to have a separate representation of it that is focused on the task at hand, configuration. I feel that Spring.NET provides a pretty good mechanism for accomplishing this, but it still leaves a lot of room for developers to muddle it, hence what everyone has experienced before when dealing with large amounts of declarative configuration. With that said, I do believe that you should have the option to use either, and that they should be able to be used together. There are some parts of applications configuration that I want left internal, which could accomplished by embedded the XML in the assembly, or using code config, but when thinking about it from an end-users perspective, there is some that I want to expose. I think a lot of these mechanisms are for the people that consume our products, rather than the ones that develop using them, even though the developers do benefit from them.

Now, besides the obvious steps that need to be taken to get this project back on track, such as ensuring unit tests correctly represent expected behavior and are passing, and establishing platforms that will be supported in the way forward (and how to better structure the project to support that), I think a little life needs to be injected into some of the public facing parts of this project, such as updating the website to announce a call for contributors, etc. Whatever we can do to wake people up needs to be done.

I also have some ideas for other Spring.NET initiatives. The way that I look at the Java version of Spring is that it provides a foundational framework for structuring your applications, while attempting to smooth over differences that are encountered when using the various application servers that are used, and then providing a lot of integrations using those same concepts that become available to your application out of the box. With Microsoft's divergence from a couple of frameworks for .NET that are pretty much the same in general, to now with several frameworks to choose from, each having their own caveats and restrictions on usage of accepted .NET features, there needs to be some middle ground project that provides a solid base to build off while minimizing effort required by developers to support as many targets as possible. That can be the new niche that Spring.NET aims to fill.

There have been so many new developments in the .NET ecosystem over the past few years that it can make your head spin. Now with the shift in efforts to self-host services within your own process, there could be an initiative to provide guidance and frameworks to support these developers. Spring.NET could become that set of abstractions and default implementations to ensure best practices are present from the beginning. I personally love OSGi and Apache Karaf, and would like to see something like those available for .NET. Yes, I know there are some aspects of .NET that make OSGi for .NET not completely feasible, but you could capitalize on the benefits while accounting for limitations in the platform.

Also, I think a few of things are extremely critical for the longevity of the project (those will be described later), and one of them is Project Alliances. Spring.NET should position itself as an integration platform where developers can opt-out of default implementations to integrate another project's implementation. Spring.NET should be more than just an IoC/DI framework. Yes, I know there are other projects, but the focal point has always been the container for me.

I think we should also evaluate where the Java Spring project has gone in relation to where Spring.NET currently is, and see if there is anything else that could be taken from that set of projects.

I am serious about this, and I hope that anyone interested in being a part of this would join me.

@jeffreyschultz

This comment has been minimized.

jeffreyschultz commented Oct 29, 2017

I would also like to help move the .NET community towards an old idea, but what I think could be a new paradigm for .NET.

Composition is Configuration

Pretty self explanatory, but it shifts the perspective of how application configuration is handled. It should not be an after thought where classes grab needed values from AppSettings (ick!). An objects configuration should be a definition of that class for a particular instance, and that is addressed with composition.

@jeffreyschultz

This comment has been minimized.

jeffreyschultz commented Oct 30, 2017

It looks like there is a lot of good stuff in JIRA, along with some Futures tasks. Are these still valid?

https://jira.spring.io/browse/SPRNET/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel

Is JIRA available for us to use? Or have ties been severed? I am not really sure how the current Spring.NET projects tie in with the original project that used to be available from the Spring Source site.

@jeffreyschultz

This comment has been minimized.

jeffreyschultz commented Oct 30, 2017

As for porting to other platforms, would it be a better bet to aim for the .NET Standard targets, rather than .NET Core itself?

As an update, I have found a few issues while developing my prototypes for a new project we are working on at work, and will be creating corresponding issues to be worked. I have also updated my GitHub profile to show my email address, so that anybody interested can contact me directly and assist.

I think there is another effort to port to the .NET Standard 2.0 platform, called Summer, so I will also be reaching out to that developer in an attempt to combine our efforts if they are still interested.

@luizcarlosfaria

This comment has been minimized.

luizcarlosfaria commented Oct 30, 2017

Hi guys,

i've working with spring.net since ~2007/2008 and a really appreciate this project.
It's help-me do to more, and about that i have some special feelings about this projetct.

What i did

At september 26 i've started a independently and unpretentious port of Spring.Core and Spring.AOP to .NET Standard. This port is a success, i'm working with this port on production, using misc of code and xml configuration, AOP and some daily features as well.

The port that i did is based on 4 solid steps:

1 - New Projects

Create a new projects based on .NET Standard 2.0, copying all code files to new project mantaining the assembly name, namespaces.

2 - Switch and Adapt

Addind nuget packages for known dependencies and creating a fake classes to replace some behavior that not portable, like Common.Logging and System.Runtime.Remoting and System.Runtime.Remoting.Messaging. These fake classes was created to garantee that i don't add a new issues or mistakes during remove your utilization, instead that, i create a fake implementations to maintain codebase intact. The only not ported thing is registry32, that was removed.

3 - Tests

The third step is make tests working. About first and second step, i'm talking exclusively about the Spring.Core and Spring.AOP projects, without your test projects. At third step and this is a most dificult on this port, is make tests working fine and Rhino.Mocks has maked it mor dificult. I really had some dificults to mantain same contract, wrapping other framework to do that using NSubstitute. But, on my work plan, i'm still here.

4 - Growing up

The last continuous step is make this project live!
But, it's depend of have or not this talk. I'm waiting for that. I really don't planed create any fork, the mindset behind this work is prove that can be done. And if i'm done, and was done, that i can use on my projects, until the official version was released.
If this talk was not exists, i'will think about the for in a few months or never, it's depends.

what i will do

If anybody ask me about work on this project. My answer is yes! i Will be glad to contribute!
I'm in!

@jeffreyschultz

This comment has been minimized.

jeffreyschultz commented Oct 30, 2017

@luizcarlosfaria Wonderful!

I got excited when I saw that I had a new GitHub notification.

I would certainly appreciate your help in getting this going. Perhaps, we can start taking a look at the changes you made to get the core projects onto .NET Standard 2.0, and then create a new branch for this work that only contains the source code for those projects that are being migrated to .NET Standard 2.0. This way we can selectively bring over projects as their dependencies become available, leading to an eventual merge back into master. I prefer the Git Flow methodology, but the current repo isn't setup for it. I don't know what I was thinking, but the repo is already structured for it.

Did you work out of your GitHub repo so that all commits are available, instead of one dump to GitHub? It would be great if we had diffs against the individual files to be able to see each and every change.

@jeffreyschultz

This comment has been minimized.

jeffreyschultz commented Oct 30, 2017

I wasn't sure doubted that we would be given committer access to this repository, so I went ahead and created a new organization with a fork of spring-net:master. I have already invited several people from this thread, but if you didn't get an invite and are interested in contributing be sure to let me know. You can either reply to this thread or drop me a line.

Eventually, once we have a stable team structure, we can move to the pull-request model of contributing. I just wanted to make sure that a number of people were included from the start. If things change or issues pop up, we can adjust to address it.

The organization is spring-net-futures.

@luizcarlosfaria

This comment has been minimized.

luizcarlosfaria commented Oct 30, 2017

Great @jeffreyschultz !

Sorry, i've talk so much but "where's the code?"

https://github.com/luizcarlosfaria/summer-net

This name is a joke! Ok?! don't judge me about that!

@jeffreyschultz

This comment has been minimized.

jeffreyschultz commented Oct 30, 2017

Summer makes sense, since Summer is after Spring, but I intend to stick with the Spring name for historical purposes, since this isn't a true fork of the project and just a continuation that hopefully will be merged back into this repository.

https://github.com/spring-net-futures/spring-net

@jeffreyschultz

This comment has been minimized.

jeffreyschultz commented Oct 30, 2017

Also, just so that everyone knows, we will be using the Git Flow methodology. That means that you do not directly work in master or develop, but that you create feature branches that will be merged into develop, and eventually develop into master.

This important as we should be establishing a baseline to work against.

@luizcarlosfaria

This comment has been minimized.

luizcarlosfaria commented Oct 31, 2017

GitFlow is a standard, it's ok for me.
I'm really care about maintain a unique and large repository with core and subprojects. I really think that can be splitted in (git) submodules.

@jeffreyschultz

This comment has been minimized.

jeffreyschultz commented Oct 31, 2017

Yeah, I like using git modules, too. I was contemplating doing this as well at some point, but wanted to talk it over with the team first. It has my vote.

@ynauls

This comment has been minimized.

Contributor

ynauls commented Oct 31, 2017

@jeffreyschultz , I can assist too. My current need is upgrading the current 2.0 release to NHibernate 5. After that, I can continue supporting this effort.

@Salgat

This comment has been minimized.

Salgat commented Nov 1, 2017

Would love to see this support .NET Standard. It's one of the only dependencies left holding us back.

@luizcarlosfaria

This comment has been minimized.

luizcarlosfaria commented Nov 4, 2017

@Salgat, In my tests, only default configuration model (using app.config or web.config) stay broken. XML and Code configurations still working fine, side-by-side, nested contexts are working fine too. The port of core and aop projects are very simple, but port of test projects still need a lot workhours.

@jeffreyschultz

This comment has been minimized.

jeffreyschultz commented Nov 4, 2017

I have been playing around with Spring.NET under Mono and majority of the tests throw a fault when executing. I am still looking into the issue, and am considering just doing this work on Windows. It might be too much to try and develop from another platform while trying to port it to .NET Standard 2.0.

@jeffreyschultz

This comment has been minimized.

jeffreyschultz commented Nov 4, 2017

I have migrated the Core project to netstandard 2.0 as a test and have been looking through your project, @luizcarlosfaria. I am exploring the possibility of creating a Spring.Logging namespace that defines an container-level ILogger interface to be used and managed by the container. It would be available to Spring.NET consumers as well, and would provide an abstraction to develop against, while allowing for developers to configure logging implementations. I would like to eliminate as many external dependencies as possible.

@jeffreyschultz

This comment has been minimized.

jeffreyschultz commented Nov 6, 2017

I had to revert some changes because I had ran a Resharper Clean Code against the entire solution, and it really made it hard to tell what had changed in the diffs because it moved things around. Too many file changes for this task to properly track what is going on, so I reverted my initial commit in hopes to make the future pull request more easily accepted. So I backed out those changes, and made the changes to Spring.Core again to get it to compile on .NET Standard 2.0.

https://github.com/spring-net-futures/spring-net/commits/feature/netstandard-2.0

@jeffreyschultz

This comment has been minimized.

jeffreyschultz commented Nov 6, 2017

I just committed changes to Spring.Aop to get it to compile with .NET Standard 2.0.

At this point, I really don't know if the code works, just that it compiles. I have also broken the build configuration where it used to copy files to certain folders, and now only produces the artifacts under the project folder, so this will need to be revisited when looking to merge changes back into original repository. There is also the potential for us to handle builds differently... really don't know at this point.

What is a good build system to use for .NET these days? I would really like a maven or gradle alternative for .NET with good dependency management where a local repo is maintained with build artifacts from recent builds so that these projects could easily be split up and developed separately instead of being tied to a single solution. Does anything like that exist for .NET yet? Nuget doesn't really hit the mark, and I don't see it as a viable dependency management tool, and is more like an "app store" for released libraries--what about a nightly build that was just ran and not yet uploaded to Nuget? I have some ideas for a new build system that would accomplish this for .NET that I have dubbed "mason", but haven't begun any work on it other than the name.

@luizcarlosfaria

This comment has been minimized.

luizcarlosfaria commented Nov 6, 2017

  1. @jeffreyschultz , i think that create a Spring.Logging is a good idea, maybe Spring.Logging.Internal to explain that is not for external implementations is about infrastructure of project.

  2. These changes made using Resharper will be helpfull, but until a full port of a test projects it can put unknow bugs. When i decide split the work in 4 big steps, the mindset behind these steps is, doesn't change anything that i not need change now. It's a garantee about mantainence and rastreability.

  3. About build system, the old fashion msbuild is incorporated on dotnet cli, and nuget still the big project about dependencies on .net. In regards, we have some others support tools. Nightly builds repo is addressed by myget, proget (inedo) and others. One of most interesting features on this case, that can just point to night build endpoint and work side-by-side.

I think that we have decisions to make, and my first tradoff is solved looking around asp.net core, .net core and some open source projects designed for the community today. They have myget, still using nuget, runnig under jenkins... some big annd simple deals.

@jeffreyschultz

This comment has been minimized.

jeffreyschultz commented Nov 29, 2017

There has been so much development in the set of Spring projects that it's exciting to think about all that we can take and bring over to the .NET implementation. I could have sworn there was a local-file:// protocol in Spring, but maybe I am thinking of another technology I have used in the past. Not sure, but it makes sense to have one.

@sbalhoff

This comment has been minimized.

sbalhoff commented Nov 30, 2017

I'm interested in upgrading antlr from v2.7.6 to v4.7.

@jeffreyschultz

This comment has been minimized.

jeffreyschultz commented Nov 30, 2017

@sbalhoff, that is currently something I plan to do when I have verified all of the behavior of the new port.

I will be upgrading all technologies used within Spring.NET to the latest versions as long as there are no significant issues.

@jeffreyschultz

This comment has been minimized.

jeffreyschultz commented Nov 30, 2017

I still need to come up with a solution to integrate .NET Remoting back into the container. I have a couple of ideas, such as attempting to resolve .NET Remoting support classes using reflection, or extending the container with additional interfaces and constructs that allow you plug additional object handling behavior into the container so that .NET Remoting could be supported without the Core project having to understand it.

Is .NET Remoting supported on non-Windows platforms? I don't know off the top of my head, and will have to look that up. Anyone?

@sbalhoff

This comment has been minimized.

sbalhoff commented Nov 30, 2017

@jeffreyschultz Let me know if you encounter significant issues with antlr. I took a compiler course recently and wouldn't mind the extra exposure. The grammar looks simple enough though, so I don't expect that it will be a problem.

Do you have a time range goal for releasing the next version yet? I'm working on a project that is deciding whether to abandon spring.net or wait for a new version.

@jeffreyschultz

This comment has been minimized.

jeffreyschultz commented Dec 1, 2017

I am hoping to have the .NET Standard 2.0 port wrapped up by the end of the month given my current rate. I do have some more free time coming up, so it could be sooner.

You can certainly help out with the ANTLR upgrade. I have no problem with that at all. Was that compiler course any good? I love working with compilers. I started programming when I was 7 years old, and had a deep interest in operating systems and language/compilers, and took quite an interest in them and database management systems during college.

@sbalhoff

This comment has been minimized.

sbalhoff commented Dec 4, 2017

Ok. I'll pull down the project this weekend after my classes are over.

I learned a lot from the course. I wish we'd gone further into parsing than we did, and we didn't cover any optimization. We wrote a Pascal -> C compiler, which was a nice experience.

@sbalhoff

This comment has been minimized.

sbalhoff commented Dec 18, 2017

Just reporting back.

I got the antlr4 book (I can use it for personal projects anyway and online docs were not very helpful) and read through the reference chapter. v4 is pretty different from v2, summed up as so:

  1. v2 was LL(k) and v4 is Adapative LL(*)
  2. v4 generates ASTs with listeners / visitors instead of using buildAST and some inline syntax

My preference is using the visitor pattern over the listener pattern so that the AST nodes can be returned by the visitor functions. Let me know if anyone has opinions.

The antlr4 grammar is pretty different, so a large percentage of lines in the file will be modified. A few relevant changes are: options such as "k" and "buildAST" are no longer used, some options will be added at the command line (e.g. -visitor vs -no-visitor), and token values aren't specified in the "tokens" section anymore. I haven't looked into differences in error reporting yet.

I'm on vacation for the next couple weeks, so I don't think I'll get much done on this in that time frame.

@jeffreyschultz

This comment has been minimized.

jeffreyschultz commented Dec 18, 2017

I like the visitor pattern approach in most cases, so that is fine with me. It sounds good, to be honest. I haven't looked into antlr4 all that much yet.

I am about to pick this back up since the last couple of weeks have been hectic, so you should be seeing more activity from me soon.

@luizcarlosfaria

This comment has been minimized.

luizcarlosfaria commented Dec 21, 2017

Hello guys,

i'm reviewing dependencies not resolved on my port and i have news! Since version 3.4.0, Common.Logging adds .NET Standard support.

It's a great news!

@jeffreyschultz

This comment has been minimized.

jeffreyschultz commented Jan 5, 2018

I ended up switching jobs from a .NET job to one where I will be working in Java, and had to give back my .NET development machine since it was my work computer. I will continue this work either in a VM or using VS Code/Rider on my MBP. I am still here, and have't left, just in a bit of a transition.

I apologize for the delays.

@jeffreyschultz

This comment has been minimized.

jeffreyschultz commented Jan 5, 2018

@luizcarlosfaria, do you think Spring.NET should have dependencies on Common.Logging? I would like your opinion.

I thought it would be better if Spring.NET didn't directly depend on a specific logging implementation, but instead used an abstraction where logging could be plugged in. The default logging would be to the debugger log or to std out. That's just my belief, though.

@jeffreyschultz

This comment has been minimized.

jeffreyschultz commented Jan 5, 2018

I hope you guys had a great holiday season!

@cptully

This comment has been minimized.

cptully commented Jan 5, 2018

@swalters

This comment has been minimized.

swalters commented Jan 5, 2018

@jeffreyschultz Common.logging IS a logging abstraction layer so you can use Log4net, NLog, etc. It provides exactly what you are saying - no dependency on a specific logging library.

@jeffreyschultz

This comment has been minimized.

jeffreyschultz commented Jan 5, 2018

@swalters, I understand. My question is whether it should be decoupled from such a library, or any other library for that matter. This removes a direct dependency of the core code from a specific version of a third party library, and adds a level of indirection between them. This does mean that adapter libraries have to be written for each specific logging library to be brought in.

My belief is that the core parts of Spring.NET should be self-contained to the maximum extent within reason. Where we draw the line it is fuzzy in my mind. This is more of a philosophical question, but does have huge real world ramifications as a result.

@cptully

This comment has been minimized.

cptully commented Jan 5, 2018

@luizcarlosfaria

This comment has been minimized.

luizcarlosfaria commented Jan 10, 2018

Hi guys, happy new year for us!

@jeffreyschultz,
In regards of be or not to be dependent of Common.logging, i'm repeating the old discourse: The primary goal of my port is no add or remove anything, is work on .NET Standard, likely works well on .NET Framework. I'm not thinking about changes, evolutions, anything else.

Specifically about Common.logging, this is a kind of abstractions of logging. About be or not be dependent ot this? It's a choice, like everything else. It's a tradoff to consider when choose implements or reference other libraries.

The workaround to avoid external dependences maybe does not make sense. Projects like Polly, Common.logging, Newtonsoft.Json and others, can be considered essentials.

Just in case of Common.logging, this is a good project, can help to abstract and connect logging about spring and others loggers and this is a cool feature. It's must be considered.

Thanks!
Best regards!

@luizcarlosfaria

This comment has been minimized.

luizcarlosfaria commented Jan 10, 2018

About the future of Spring.NET, I'm getting more sure that Spring.NET must be a downsize.
Mantain all specific features, except these inside Spring.Core and Spring.Aop, does not sounds good for me.

My opinion is:

  • Spring.NET must be only Spring.Core and Spring.Aop merged on a single assembly (merged during build or has a codebase merged). Maybe Spring.Services too.
  • Other projects like data access, WCF, Web, MVC and technology specific projects must be bloom from the community, with variants, competition. It's my way to see how to grow up.
  • .NET Framework must be directly desconsidered to move all kind of implementations to .NET Standard (this represents indirectly .net framework features). Users that use .NET Framework in versions not compatible with .Net Standard cannot use a new Spring.NET, they still using old versions.

It's sounds so pragmatically for me, but on same time i can see two important things: Community sense, and viability.

@jeffreyschultz

This comment has been minimized.

jeffreyschultz commented Feb 13, 2018

@luizcarlosfaria, I understand your perspective, and it makes a lot of sense.

I have moved back to the Java Spring libraries for my new job, so have been focused on working with them. I want to continue to work on the Spring.NET port, but need some others to pick up some of the work. All of my changes are available in the spring-net-futures/spring-net repo under the netstandard-2.0 branch.

https://github.com/spring-net-futures/spring-net/tree/feature/netstandard-2.0

@jeffreyschultz

This comment has been minimized.

jeffreyschultz commented Feb 13, 2018

@luizcarlosfaria I think it might be prudent to take your suggestion and upgrade Common Logging for now, but personally, I would like to see a facility built into Spring.NET for this sort of thing.

@luizcarlosfaria

This comment has been minimized.

luizcarlosfaria commented Feb 27, 2018

Today i'm writing about these projects and i've found the proposal and decisions of future of Common.Logging. It's like i've proposed for Spring.NET.

best regards!

@sravansurabhi

This comment has been minimized.

sravansurabhi commented Sep 17, 2018

We used Spring.NET and nHibernate heavily in an Application built around 2010. As we have noticed no updates to Spring.NET and at the same time nHiberante got new releases, Spring.NET was posing a bottleneck for us to move to latest version of nHibernate. Somehow we managed to decouple Spring.NET and nHiberante and use them independently. Meantime we are making major enhancements to Application and thinking of replacing Spring.NET with Unity. This requires considerable amount of work as we have used Spring.NET for IOC and all the cross cutting concerns( Logging, Exception, Transaction, caching, Validation etc..). Lately noticed some interest in bringing back life to Spring.NET from community. Given that there is some community interest in Spring.NET, is it worth taking effort to replace Spring.NET? Hope community can provide some input.

@meshpaul

This comment has been minimized.

meshpaul commented Sep 29, 2018

HI Guys .. I would love to contribute.. I am in the same boat ... I used this back in 2008-2010... and I feel strongly Spring-NET was awesome... just let me know if this will have a life here... or should we move this outside ?

@lahma

This comment has been minimized.

Member

lahma commented Sep 30, 2018

I've completed the somewhat long journey for .NET Core compilation and master now has the capabilities, see #133 (comment). I "stole" a commit from @jeffreyschultz to get some functionality in that he already had implemented, I hope that is OK.

So anyone wanting to build a beta'ish release it can be done from current master.

@sbohlen

This comment has been minimized.

Collaborator

sbohlen commented Sep 30, 2018

@jeffreyschultz

This comment has been minimized.

jeffreyschultz commented Oct 5, 2018

I now have one leg in the Java world, and the other in the .NET world with a new web app that we have been gifted by our parent company. It isn't using Spring, but this still reinvigorates my interest in this project. I am working in a Virtual Box instance with Windows 10/Visual Studio 2017, so I am good to go.

@lahma You won't get any complaints from me. 👍

@athinboy

This comment has been minimized.

athinboy commented Oct 10, 2018

Good idea!
I Love .Net and I think Spring is good!
Offers support!

@Simulacrux

This comment has been minimized.

Simulacrux commented Oct 31, 2018

Nice seeing the project comes back to life
@lahma a gold medal 🥇 for getting it running again

Would be happy to get the new release a test drive soon.
Maybe a "Prerelease" Nuget could be provided

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