Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Put ASP.NET Core integration packages in its own repository #779
Can you explain the reasons for this change?
IMO splitting the solution in multiple repositories would increase tooling/deployment/maintenance overhead and could possibly make it harder for individual contributors to work with the simple injector source code.
Would be interesting to hear your thoughts on this. Also: What about the other integration packages? (MVC, WCF ...)
The plan is, with the introduction of v5, to only release the integration libraries when there are actual changes. But a few changes need to be made to facilitate this. One of the things is the assembly numbering scheme. Another change is that the integration projects start referencing the SimpleInjector Nuget library. I recently tried this on the current code base, but this causes problems, because the mix between the external (Nuget) library and the internal (project) reference.
Moving the ASP.NET Core integration libraries (and possibly other integration libraries) to other repository/reposities, it solves this reference problem. But there's more. The repositories become smaller, and the volatile parts (ASP.NET Core) is separated from the stable code library. It also simplifies the build and publish process.
The binding redirects issue explained in #543 only affects full framework and isnt a thing in dotnet-core because core produces
Furthermore, when diagnosing things, it can be annoying if a library does not expose its real version. We already have this in EntityFramework6 because its always published as
Additionally, there is another aspect when creating multiple repos: Managing github repositories and issues / mrs gets distributed as well. Personally, from a user endpoint, its really nice to have the centralized issue management like its at the moment. With multiple repos/issue-trackers, it will get harder for users to find the right project for reporting bugs/questions and to participate in general.
What benefits do you see when referencing nuget in the current monorepo approach? Of course, when splitting repos, this would be the only way. But I would like to understand what advantages you would see using nuget references in the current monorepo?
IMO at the price of making managing the project itself more complicated. More repos, more issue trackers, is also more complexity. Multiple locations to find a source code as well ;-)
I hope I am not annoying bringing up this questions/thoughts. I am sure you already thought this through, and as the main driver, you are seeing things others can not see. Just trying to bring in some external feedback and maybe learning something new.
I'm always in for a bit of discussion to shape my opinions and those of others :) So not annoying at all.
Don't count on this. My experience is that organizations keep working with old versions for a long time and developers have to maintain legacy software. From experience already I know that migrating to .NET Core is not a simple thing, but I want to ensure that upgrading Simple Injector stays simple for our users. Many users of Simple Injector will keep using .NET FX for years to come, that's something I dare to put my money on (whether I like it or not). Being able to upgrade to the latest Simple Injector library is an important feature. It will take several years for Simple Injector to be able to ditch .NET FX, just as Simple Injector v4 still supports .NET 4.0. We planned to stop supporting .NET 4.0 in Simple Injector v5 (#692).
I agree with the diagnostics of things, but to me this is a much smaller issue compared to the binding redirect issues. This is something that .NET (fx) users keep bumping into. Although binding redirects make sense, the "Simple" in Simple Injector is there for a reason. Of course, once Simple Injector is only compatible with .NET Core (which, again, will take a few years), and the binding redirects are something of the past, I'm certainly willing to reconsider syncing the assembly versions with the NuGet versions again.
This is especially important from a package perspective. Starting with v5, I want to only publish a new version of, say, the ASP.NET Core integration libraries, when there are actually changes. And I want those packages to reference the lowest possible Simple Injector version. What this means is that, even though both core library and the ASP.NET Core integration libraries will evolve and get new minor releases, it is unlikely that they will depend on new features in the core library and will, therefore, likely keep depending on 5.0.0. I noticed, however, that this is much harder to achieve in an automated, and compile-time-safe way.
Having a reference to the NuGet package means there is compile-time support of whether that specific referenced version of the core library contains the expected version. This is impossible with a project reference, because the core library will evolve at the same time.
When setting the version number of the core library in a post-build or publish step, this compile-time support is completely done. This already did byte me in the ass in the past. Technically, I could still reference the NuGet package from projects in a mono-repo approach, but I recently tried this, and this causes all sorts of compile and reference problems, because there are shared (test) projects that than reference both the core project and the (older) NuGet version.
So from that perspective, having a reference to the NuGet is perfect: it gives compile-time support while still allowing Visual Studio's NuGet packaging feature to automatically set the correct NuGet package. There's only one feature I'm missing, and that's setting a max version number. But that's a different discussion.
Another thing I'm currently quite hesitant of, is adding new projects to the solution. That's because I think the solution is already getting big. This size, for instance, is the reason I have a test project for the ASP.NET Core integration packages that I didn't check in. This is something I'm less hesitant off, when separating unrelated parts.
I think there are pros and cons for both the mono-repo approach and the multi-repo approach. I've tried this mono approach now for almost ten years, and I think it's good to, at least, try out how this works. It it doesn't work out as intended, I can just as easily move back.
There are certainly a few things that need to be ironed out, but I'll likely want to:
I hope this makes some sense.