Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Discussion about Solution files, filters and CI

See original GitHub issue

I found it hard to get my head around this: image

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:

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: Same with tests:

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 ( and later 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: image

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

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?

Issue Analytics

  • State:open
  • Created a month ago
  • Comments:5 (3 by maintainers)

github_iconTop GitHub Comments

bitsandfoxescommented, Aug 21, 2023

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.

jamescrosswellcommented, Aug 20, 2023
  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.
Read more comments on GitHub >

github_iconTop Results From Across the Web

Is it advisable to use solution filters to separate out builds?
For greenfield software development, I would advise against using filters to create separate builds in the same pipeline.
Read more >
Filtered solutions in Visual Studio
Solution filter files are visually differentiated from regular solution files by the additional funnel glyph in the icon next to the solution in ......
Read more >
Discussions - Enterprise Service Management
The Discussions tab in a record enables you to open discussions or post comments about the records you are ... Filter the discussions...
Read more >
The Design of Computer Supported Cooperative Work and ...
Other answers, which do not advance the state of the conversation, are acknowledged, free-form, commit-tocommit and interim-report.
Read more >
Best practice: Using the CI's XSS filter | General Discussion
Chat with fellow EECMS users in the 'Best practice: Using the CI's XSS filter' ExpressionEngine community discussion forum thread.
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found