❔ ✅ Why does this not work???
Stellution.Common add Easel.Headless but i want to remove it, now i tried ProjectRefernce Remove... and it is still in need i to reload something or has anyone a idea?
79 Replies
Full Code:
its like a duplicate
thats why i need to remove it
but it does not work
yes
Client does reference Common
But Client has the Grpahic Version of Easel so not the Server Version yk and now is it like a duplicate
i need to remove headless
but just for the client
but idk why it not work
any idea?
ouf
can i add a condition that handle that
like just on Common and Server but not on Client?
so
i can not do that?
i mean it is the same project
just different csproj files
mhh
would it possible to change between them?
like
if Client
Easel
else
Easel.Headless
it is basiclly the same project
just without graphic things...
No. A dependency means, "I need this in order to work" not "I need this in order to work..unless".
You're going to have to do some redesign work.
:/
eg. Create an
Easel.Common project with an IEaselGame. Then implement that in both Easel.Headless and Easel (I'd probably rename this to reflect it has rendering).
Then create Stellution.Client and Stellution.Server as new projects. You can take the dependency on the correct headless-or-not library. Everything can work with IEaselGame because that part is common.well but Easel is not disigned like this
Oh, Easel is not yours?
nope
https://github.com/piegfx/Easel/tree/master/Easel 
weird for the library author to create the Headless library by putting the csproj into the same library and using preprocessor directives everywhere.
I would still recommend similar. Skip the Easel stuff since you can't control that.
Actually, hmm 🤔
If you can keep
weird for the library author to create the Headless library by putting the csproj into the same library and using preprocessor directives everywhere.
I would still recommend similar. Skip the Easel stuff since you can't control that.
Actually, hmm 🤔
If you can keep EaselGame itself isolated to a top-level game object, there might be a good option. But it probably ends up leaking everywhere.yea
how would you do it?
like it is the same project
but set a constant
if a server the rest the removed
but by the client everything is there
but it is still the same project
and problems like this can not haüüem
I would use a different library. That's a significant design defect, IMO, that the library author needs to address.
If you can limit where After that, you might be able to global alias
The types don't change so this doesn't matter, which makes it easier. You only need to do separate builds and the conditional package reference...
EaselGame is used, you might be able to keep most of the code in Stellution.Common and create small Stellution.Client and Stellution.Server projects that simply handle referencing the right library and then handing off the rest. But EaselGame probably gets used too much for that to be viable.
There are probably some build options that are better considering how jank this is.
You should be able to conditionally include Easel or Easel.Headless in the csproj depending on some build switch.
EaselGame as either Easel.EaselGame or Easel.Headless.EaselGame in GlobalUsings. But I'm looking into that.library author here
i'm aware this is not the best solution but I don't have the time or incentive to use a
Common project at this point of time as it would require a fair amount of rewrite work (sure I could add a ton of branching but I don't want to do that), the headless is not my focus as I do not personally use it myselfAt this point, after learning that the types overlap, I would do this in the
csproj assuming you're only doing one project for the client and server.
In this approach, you'll do two builds. You can create build configurations for "Client Release" and "Server Release". At that point, you should be able to use Conditional in the csproj like https://learn.microsoft.com/en-us/visualstudio/msbuild/msbuild-conditional-constructs?view=vs-2022
There might be a better approach if you split the projects into client/server and put more effort into the build system (template / source generation) to eliminate the redundancies, but this is about the best I can do given the circumstances.well but that would also not make it include able or remove able
so just 1 project is on the client
or does it?
You only want to include one of the libraries per build, not both.
yea
to fix this ^^
If you need the same executable to run both rendered and headless, then this won't work.
no i just want 1
can you give me a example
Right, so you do the conditional package reference based on the build condition. Then you'll only include one.
i do not really understand is that not the same that i tried before
can you give me a small example what is different?
It's not what you were doing at all.
but the condition part is the same
^^ sry i not posted that in before
that would not work too
Ah, yeah that wasn't in here. That's not complete enough though.
If you want to do it via build configuration. (You'll need to add the debug builds too)
you sure that works
let me try
You need to add the build configurations with those names, but it should work...because the type names overlap.
would that possible with that names to?
Not sure.
Oh, that's the configuration name I guess? I don't use Rider. If so, then probably.
does it need the Configuration name
the Debug / Release thing?
or
Not sure with how Rider supplies the configuration string.
Worst case is that you build with Nuke or some other build system.
nahh this solution is not that well
I guess I overlooked that you're going to have to build the common library twice here.
?
Once for the Headless and once for the other. They're different types (even if the names overlap).
mhhh
I'm not sure if you can do that via GUI. 🤔
i think not but the solution is not that well too
I don't know how to solve this without a build system. Maybe you can create two csproj in the same source directory for the common library like Easel does. Create
Stellution.Common and Stellution.Common.Headless and then reference those from your client/server projects.
You won't need the conditional configurations that way. They can't go upstream without a build system to trigger a rebuild of the conditional library, AFAIK. You'd need somebody better at msbuild than I am if that's possible.and what about appsettings,json?
i made for server and client a settings.json
with
and get it like that
would that work
It can't work AFAIK, because you can't push that config upstream to the library to force a rebuild. (You could do this with a build system like Nuke, but I wouldn't put this as part of a JSON file. Just use a CLI parameter for your build)
what is a CLI Paramter?
Command line interface parameter.
you mean like that?
Yes, but that is not sufficient because the Common library won't rebuild. Which is why I suggested a build system in the worst-case scenario.
build system?
As you're basically writing a program and can force a Common library rebuild and push that setting upstream into its build.
https://github.com/nuke-build/nuke is what I use for my apps that have a build system.
Would Easel need that too
or just im?
https://github.com/stevemonaco/ImageMagitek/blob/main/ImageMagitek.Build/Build.cs as an example script that builds/tests/packages a couple apps
No, just yours should be fine.
and that would able to handle that?
and there is no c# way?
because adding a full lib just because 1 variable is a big thing...
Well, it's a separate project. Which really saves time when you're at the release point so you can automatically build/test/package and even deploy if you want to.
The big concern I have is if debugging will be more difficult.
Hmm...
I wonder if there's any MSBuild command you can put into a csproj that could force a conditional rebuild of the library.
mhh
So you can run
dotnet via MSBuild in csproj: https://github.com/MapsterMapper/Mapster/blob/master/src/Sample.CodeGen/Sample.CodeGen.csproj
So you would have the conditions in the Common library. Then the Exec Commands to build the library as a pre-process step for each the Client and Server (remember to pass the right flag).
Seems complicated, so I would probably just try stacking the two csproj in the same folder for the Common library.....
Btw
what about this
why does this not work
Why would that work?
ChatGPT tell me that should work
but it dont
😦
and now idk
It's a really unusual scenario for a dependent to request a conditional build of a library.
and is there any check like is the project name ... then this....
ChatGPT was banned from stackoverflow within a week of it being made public, for excellent reasons. It's eloquent, confident, convincing... and often extremely wrong.
That's not how it's supposed to work.
lol
mhhhh
You're either doing: 1. a conditional build of two "versions" under the same name or 2. two separate library names (which requires two csproj) that you can reference separately.
The first is probably going to have debugging issues as you maintain the project even if it's technically possible.
...
would .NET 8 add it
if i make a feature request
... 😅
Doubt it. This is a nightmare.
.D
yea
mhh
That's why you see libraries split up with dependencies. eg.
Something.Wpf, Something.Uwp, Something.Avalonia, Something.Uno, etc on NuGet.yea very messy
It's not messy.
are we speak now about the solution 2 or what easel should do better
2 is going to be more straightforward here, I think.
Was this issue resolved? If so, run
/close - otherwise I will mark this as stale and this post will be archived until there is new activity.
Was this issue resolved? If so, run /close - otherwise I will mark this as stale and this post will be archived until there is new activity.