Conflicting System dlls
I have project that has
DisableImplicitFrameworkReferences and NoStandardLib enabled and references custom mscorlib and System.* dlls.
However, when I add a package like this:
I get a compile error because the compiler could not choose between the default System.dll and the custom one.
How might I fix this issue?
Using <ExcludeAssets>runtime</ExcludeAssets> works, but I need the MonoMod.exe created by the MonoMod package...
Thanks in advance for any help.21 Replies
I have project that haswhy :fear:DisableImplicitFrameworkReferencesandNoStandardLibenabled and references custommscorlibandSystem.*dlls.
why not?
if it can be done, it shouldn't be surprising that there are people who'd want to use it
I mean, nothing is really designed around it being done (including MonoMod), but sure
you'd probably have to get a binlog to see how and why it's pulling in the framework reference again
or alternatively, just don't use PackageReferences (or use it and manually add References to the DLLs with GeneratePathProperty)
(and "I felt like it" isn't a very good use case to invest time into, it's not like it's a normal thing to do)
Also, I did already solve this, so I should probably edit the post, though I am curious if there are better ways to do it
how did you solve it in the first place
create a different project that does not rely on a custom core and then in a
PostBuildEvent simply copy over the files that I need from that project
in the current project where I want to use the library I can simply use <ExcludeAssets>runtime</ExcludeAssets>just use GeneratePathProperty
and exclude everything + None items that copy to output
if you just need the files in the output
oh you do need the library
yeah
then yeah I'd just do this
use a PackageReference with GeneratePathProperty and add normal References to the dlls
MonoMod is a weird project that creates an executable I want to run, but is also something I can reference and use as a library
not entirely sure how it works
it's not really something you're supposed to use as a library, it just happens to expose public APIs
¯\_(ツ)_/¯
generally you'd only use monomod for things you aren't really supposed to do, so I'd say it fits
or well, you are
but only in DLLs that you use as inputs to the patcher, so kinda odd
I hate the design of the MonoMod patcher
it's very cursed, I have to use a very specific version or it simply crashes
I mean my recommendation would be to simply not use it wherever possible :kekw:
I don't even mean to not patch, I mean to just do it with AsmResolver ahead of time or purely runtimedetour instead
lmao
as crazy as it sounds RuntimeDetour is better tested
:j_phew:
RuntimeDetour is a bit difficult on its own, since I'd need to somehow get an entry point, which is trivial with monomod patching
that's what modloaders are for
only problem is that that is the thing I am writing 😅
manually writing IL isn't really my forte, though 😅
you're writing a modloader, make it one :trolley: