Ewan

PostSharp?

oh yeah I remember aspect orientated programming, I think there was some precomplier thing for c# if you wanted to avoid reflection

if someone says "well.. you see it depends..." I just roll my eyes, pick a side buddy! these flames aint fanning themselves!

someone else can write "reflection is good because it saves on typing, all true programmers know that typing is the worst!" and you let the votes decide

then you just put your fingers in your ears and sing "lalallalalalala" while running away

ie reflection is bad, because its slow. Sure it make make serialising classes easy, but all true programmers know the fastest solution is always the best

But you can avoid it by specifying why the thing is bad

but I would agree the "it depends" answer is baked into the "is this good/bad (for all circumstances)" question

urg I hate that "load all the classes of type BaseClass/interface" stuff. Would prefer config over convention any day.

How many projects and how many independant programs are there?

im not up on java really, it looks like more folders than code to me

would you describ this as a mono repo?

or how and if they are helpful

you are stating these things but its not clear how they are achieved

ok so thats my answer to "why would a count of build steps have any effect on the repo count?"

is that a mono repo?

via CI in their own branches

then I make a CI in the root branch which pulls all the branchs and builds them one by one

and a branch for project B.. etc

then I make a branch ProjectA and upload all the projecvt A files

if I make a new repo with no files

let me give you an example

i dont know what you mean by that

because you have to have a working solution to whatever problem you think monorepo solves

you effectivly have two repos and two cis, you just have a master part that runs them both

at this point you might as well just have two repos

part 2 compiles the .net9 subset#

part 1 compiles the .net8 subset

"each CI run compiles everything"

ie "Project A cant use net9"

some projects will only compile in one framework, not both

..but you just said ....

obvs if you always have the same sub set of projects that get compiled together, with no overlap, you might as well split those into their own repo and just build them

when you only compile part of the sourcecode in the repo

that kind of the point behind the question

for me, it seems like conditional compilation strays into "might as well be a multirepo"

Well its up to you to define what you mean by monorepo

i guess we can allow caching

otherwise you could have your CI, pull branch bV1 and build with A

surely for monorepo to be meaningful the build has to include all sources, not binary references

I could write a CI run that pulls from multipel repos

the framework specific build of B produces a different binary depending on the framework

where compile time checks are run

yeah

there is no need to resolve conflicts

sure, but you will never work on D in main, it will always be in its own branch

C and A will not be in the same build

but you will have two builds first net8 with A and B and then 9 with C and B

it seems irellevant to be wheter you merge the branch or not if you make the merge a no-op and deploy D from the branch