Skip to content
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

Put ASP.NET Core integration packages in its own repository #779

Open
dotnetjunkie opened this issue Dec 2, 2019 · 4 comments
Open

Put ASP.NET Core integration packages in its own repository #779

dotnetjunkie opened this issue Dec 2, 2019 · 4 comments
Labels
Milestone

Comments

@dotnetjunkie
Copy link
Collaborator

@dotnetjunkie dotnetjunkie commented Dec 2, 2019

No description provided.

@dotnetjunkie dotnetjunkie added the task label Dec 2, 2019
@dotnetjunkie dotnetjunkie added this to the v5.0 milestone Dec 2, 2019
@davidroth

This comment has been minimized.

Copy link

@davidroth davidroth commented Dec 10, 2019

Can you explain the reasons for this change?
Wouldn`t this introduce additional maintenance overhead and tooling complexity?
At the moment its very easy and convenient to browse/debug through the whole solution and see how everything fits together.

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 ...)

@dotnetjunkie

This comment has been minimized.

Copy link
Collaborator Author

@dotnetjunkie dotnetjunkie commented Dec 10, 2019

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.

@davidroth

This comment has been minimized.

Copy link

@davidroth davidroth commented Dec 10, 2019

The binding redirects issue explained in #543 only affects full framework and isnt a thing in dotnet-core because core produces deps.json.
So when ignoring fullfx binding redirects, it shouldn`t be a problem to not publish integration libraries on every core library change. Since fullfx is maintenance-only mode, I guess most users will migrate to core anyhow. So in my opinion, fullfx shouldnt really be the driver on how SI gets published because fullfx users are fading out in the upcoming years. Of course, thats a very opinionated view because I am seeing migrating all of our companies and our customers fullfx projects to core. Others might have a different opinion. But is it really worth splitting everything, mostly because of additional binding redirects for fullfx users?

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 6.0.0.0. It can be annoying, if you cannot get the real assembly version number from an assembly because of this versioning scheme. For example at runtime, typeof(Container).Assembly would always print "5.0.0.0" and when looking up the version on the file system, we would have no clue, which version of SI is in the bin folder. Although I admit that this is rarely a real issue, IMO this feels weird and at least is not really necessary.

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.

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.

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?

It also simplifies the build and publish process.

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 ;-)
What are the issues in the current build/publish process?

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.

@dotnetjunkie

This comment has been minimized.

Copy link
Collaborator Author

@dotnetjunkie dotnetjunkie commented Dec 11, 2019

Hi David,

I'm always in for a bit of discussion to shape my opinions and those of others :) So not annoying at all.

I guess most users will migrate to core anyhow.

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.

What benefits do you see when referencing nuget in the current monorepo approach?

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:

  • Keep the main repository at entry point for discussions
  • Close the other repos down so that only contributors/maintainers can add issues
  • Allow anybody to report bugs on any repo in the main repo
  • Let contributors create issues and task (based on reports in the main repo) for new features, bugs, and changes related to that repo.
  • Have a separate release page per repo.

I hope this makes some sense.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.