Discussion about Solution files, filters and CI

I found it hard to get my head around this:

Mainly because:

1. Sentry.sln vs Sentry.Full.sln was not very intuitive to me. Shouldn’t Sentry.sln already be “full”? In that case, could it be Sentry.sln with everything, and just the filters on top? I understand there’s some logic based on the solution file to avoid compiling the mobile targets:

https://github.com/getsentry/sentry-dotnet/blob/b3f81f1cf18c877029076e184ddef4b04acdef7e/Directory.Build.props#L18-L20

Is there another approach?

1. Sentry-CI-Pack.slnf: What does give us? Since pack happens on the same workflow where things are built, I imagine this saves from looking what projects need to be backed (<IsPackable>true..)? Samples are all marked as not packable already:

https://github.com/getsentry/sentry-dotnet/blob/b3f81f1cf18c877029076e184ddef4b04acdef7e/samples/Directory.Build.props#L6 Same with tests: https://github.com/getsentry/sentry-dotnet/blob/b3f81f1cf18c877029076e184ddef4b04acdef7e/test/Directory.Build.props#L8

Is the ‘speed up’ worth having to maintain this additional filter file?

1. Too many slfn files? SentryNoSamples.slnf, SentryAzureFunctions.slnf, etc. Could this be just Unload project instead or are these used often enough?

The biggest problem I see is that everytime we add a new project, we need to deal with 3 solutions and all subsequent slnf because there’s no way to use glob patterns, or negate (like everything except /samples, or for the CodeQL filter, just add everything under src, to name a couple).

1. Sentry.Samples.OpenTelemetry.AspNet classic msbuild project in the repo. Because dotnet build doesn’t work here, there was an effort to keep these out, since the creation of this repo. It doesn’t seem like this is built in CI (and that’s probably good because it’d be slow, and require a separate build script/flow). There was another repo (https://github.com/getsentry/sentry-dotnet-samples and later https://github.com/getsentry/examples/tree/master/dotnet) to keep such samples that are rarely used and don’t need to be built in CI on each PR.

2. The .root situation. I find these Solution Files thing a bit annoying. We have to manually curate a list of files/scripts etc to get into the solution. And when in the editor we only see what’s there. So if something new gets added to the repo, we need to ‘remember’ (my weakest point) to add. These days IDEs are smarter, Rider for example:

Already shows you all the files in the repo overlaying with the soltion: Now I can see everything in the file system, as god intended:

So I propose getting rid of all of those solution items copied over in 3 different sln files

1. How about we stuff all of these filters in some folder?

2. It’s hard to see the side effect of some changes. It builds on your filter. But you’re actually breaking some sample or other part of the solution.

Or perhaps I’m overthinking, first time trying to contribute here in a year or so. That’s possible. Thoughts?

[bitsandfoxes]

I’ve been operating on the assumption there’s a good reason for most stuff so haven’t challenged any of this. I’m in the same boat.

I think there should be as few filters as possible. Mobile vs. No Mobile comes to mind. I have not yet used a single .slnf for local development.

Regarding CI: I’m of the strong opinion that whatever happens in CI should be as close to what we have in our local environment. Ideally, those should be identical. I’m really not buying into speeding up CI at the cost of complexity.

[jamescrosswell]

1. potentially we could rename Sentry.sln -> SentryNoMobile.sln and then rename Sentry.Full -> Sentry.sln
2. Sounds reasonable. I’ve been operating on the assumption there’s a good reason for most stuff so haven’t challenged any of this. The IsPackable build property sounds good instead if that’s the only reason we have a separate solution for CI though.
3. I don’t use those personally… happy to delete
4. Is there an issue having them in the repo? If they’re not part of any of the solutions that get built by CI or that we use when developing, I don’t think they get in the way… and it sounds like a pain maintaining a separate repo for these. If we ever need to debug anything or look into issues with Classic ASP.NET, the sample project is a good way of quickly bootstrapping things for investigation, so it’s nice to have these next to the source…
5. Maybe worth thinking about the experience for folks who are new to the repo… as long as the key files they’d need (ready, contrib etc.) are obvious and easy to find, I’m happy with another approach. If they need to “know” that you have to show all files in the IDE to see relevant stuff, it starts to become a bit of a gotcha that will trip people up (repeatedly). So maybe there’s an argument to keep those things referenced in the solution files.
6. I don’t mind having the filters in the root directory. They’re only really convenient if you’re using Visual Studio anyway… in Rider you don’t have a solution filter drop down to easily apply different filters in the same way.