The build above shows that this is indeed working. Assemblies have specified which assembly a specific type is supposed to be from, so it can be resolved correctly and there can be multiple assemblies with the same types in the appdomain. Names can be conflicting (they already are with v2 and v3), since each type is always associated with a specific assembly.
#Scripthookvdotnet v2.7 free#
I hope this was useful! In case I'm misunderstanding something, feel free to correct me. GTA3) and add support for depending on both in the solver. Or we do, but then we probably want to bump the namespace (e.g. We don't want to be able to end up in situations where two major versions of SHVDN can be pulled in ever due to conflicts in their namespaces. The domain solver probably needs to look through the assembly dependencies recursively, and log conflicts (e.g. I don't have an example of this, but it wouldn't be completely out there. And the authors are the ones who need a stable way to target an API version.
What we need to consider here is that the users of the scripts seldomly are the ones who write them. You can have a dummy pragma at the top of the script that if absent loads it against V2 (e.g. So there's two cases we probably want to to make sure we cover before moving forward:ĭrop-in scripts targets V2, unless they specify (somehow) that they target V3Įasiest would still IMO be to have a separate directory. This happens if we change default behaviors. I'd like to propose that we make sure that upgrading SHVDN won't break existing solutions in place. īut I will likely merge this into master soon and get rid of the two seperate version branches ( dev_v2 and dev_v3) in favor of having it all in one again.
It also continues to work to simply put all scripts in the "scripts" subdirectory to the GTA folder, no matter which version they were written against.Ĭode is currently in a separate branch.
#Scripthookvdotnet v2.7 plus#
Really nice plus to this solution: The console that was implemented for v3 is now independent from the version, so it can control both v2 and v3 scripts. On loading a script the core logic will check which API version it was built against and bind the correct version to it. Then there are two API DLLs ScriptHookVDotNet2.dll and ScriptHookVDotNet3.dll, which contain only the API that developers can use (one can choose which version to reference in a script project). So the core logic resides in ScriptHookVDotNet.asi and is responsible for managing the. This way everything stays as it is, but just works™. I separated the core SHVDN logic from the scripting API and modified the script domain implementation to be able to load and apply multiple API versions to different scripts. I took another shot at this and believe I finally managed to come up with a good solution. So in theory, they could both exist in the same project if someone wants them to assuming you haven't bumped the. The signatures of the entry points would be different across major versions since they come from different namespaces ( GTA.Script vs GTA3.Script). Downstream projects can mix and match between targeting two different major ABIs at the same time if they want to without having to have two separate workspaces. They actually have to be rewritten to target a new ABI, even if that's just a string replace. NET framework version if you want to.Ĭhanging namespace makes sure there's a clean break between the two major ABIs. It would allow major versions of ScriptHookV.NET to bump the.
Make v3 load scripts from a different folder (e.g./scripts3).
0 kommentar(er)
