PostSharp vs. LinFu

[Drakulix]

Okay, this project seems abandoned, but it is not really. I am just lacking of time and motivation. Motivation got a lot better in the last days, as I seem to have some more free time in foreseeable future, so I took a look at my older projects and this definitely deserves some attention.

I took a look at the our old Interface-Wiki-Page (https://github.com/Drakulix/ScrollsModLoader/wiki/Modding-Interface) finding some fresh and good ideas.

Most important one being PostSharp.

Lets brainstorm a bit until I start developing on this project again. Why use PostSharp over LinFu (and the other way around).

1. LinFu is outdated. PostSharp seems to be under active development. (huge + for PostSharp)
2. LinFu forces us to link against an outdated version of Mono.cecil (not to important, but again + for PostSharp).
3. Both frameworks require assembly modification and are not able to hook methods at runtime (Any Framework that does that, would be perfect).
4. LinFu was extensively tested in the ScrollsModLoader and is a well known API for me. PostSharp is not, although I guess it is much more elaborated and tested then LinFu in general.

Looks like we are going to adapt to PostSharp, anything I did miss? Feel free to discuss.

[MaPePeR]

I think we should stick with LinFu, because PostSharp feels like its not suited for us. PostSharp is a sports car, but we actually need a tractor to sort things out. PostSharp is for weird awesome Software Design Patterns and stuff and not really for messing with external assemblys. (From the look of it)

Linking against an outdated Mono Cecil is not a problem, i think, because Scrolls is based on an outdated Mono as well.

The Bigger question i see is: Rewrite vs Trying to Fix stuff.

Things i think should be avoided when doing a rewrite:

• Handling File Paths or URIs as Strings
• Using Objects that where parsed from Json (The Difference between a local mod and one that was installed from a repo is causing problems for me - for example you can not really reorder local mods?)
• Mixing ingame Mod-UI with patching Code with parsing Mod Assemblys
• Auto Updating without asking
• Saving Mods in Folders with hash-value names. (ModNames should be unique - if not we can just append a number to make it unique)
• ... and all the stuff i can't remember right now

[Drakulix]

Rewrite. And nothing else. I spend the some time trying to do some hooks at runtime. Sadly mono seems to work a lot different to .net and you cannot just replace the function pointer of the method handle (would have been so easy!). The only thing regarding method injection during runtime is this: http://www.codeproject.com/Articles/463508/NET-CLR-Injection-Modify-IL-Code-during-Run-time and it is .net Runtime only as well. Any ideas, how we can achieve similar in Mono?

[MaPePeR]

https://github.com/vc3/Afterthought or https://easyhook.codeplex.com/ might also be options (did not look into them, yet)

[Drakulix]

both don't seem to be mono-compatible

[MaPePeR]

Thats sad. Afterthought looks like an awesome interface. But looking at the Issue list it looks like it is not compatible with a lot of stuff.

[Drakulix]

I tried to implement Runtime Method Injection (as described here: http://www.codeproject.com/Articles/37549/CLR-Injection-Runtime-Method-Replacer) in the last days, but the Mono Runtime does not seem to use the function pointer address at all. The value is appears to be totally random and may be even identically for totally different functions. I guess we need to stick with LinFu in that case. PostSharp is a total overkill for our needs.

[Drakulix]

We could however just weave the whole assembly to support runtime hooks. I tested the performance once with LinFu and it was awful, but according to this article, we could try Castle.DynamicProxy : http://kozmic.net/2009/03/18/comparing-execution-speed-of-net-dynamic-proxy-frameworks/

[Drakulix]

Castle.DynamicProxy does not allow static assembly-weaving, it just wraps virtual-functions at runtime, but PostSharp does and seems to be quite fast as well. I will try to weave the whole assembly and check the performance of several unity games with it sometime in the next days.

[Drakulix]

And PostSharp itself works with mono, but the assembly-weaver does not. Hooray, another great library that we cannot use... "-.- So LinFu is the only real option.

[Drakulix]

I would like to discuss this: "Saving Mods in Folders with hash-value names. (ModNames should be unique - if not we can just append a number to make it unique)"

I still feel like I wanna have a unique identifier, thats not the name of the Mod. The ModLoader should be able to handle different versions of the same mod for example. But I would like to use a Guid instead.

[MaPePeR]

the hash folder name scares people.

Because one can not have 2 folders with the same name in a directory you have a unique identifier for each mod folder: the folder name. Alternately one could just put all mod dlls into a single folder and then the unique identifier is the filename. And because the filesystem is accessible by humans it should be more human friendly. Also some mods actually require you to go to into folder to change some configuration/read data.

[Drakulix]

But the folder name also needs to have it's origins. And if that is the mod name, then two mods with the same name cannot coexist. Appending numbers or similar stuff is an ugly work around for me, because it just shows, what we really need. A real unique identifier.

Also it is not unintentional, that the hash value is scaring. Unless you are a developer or at least read the documentation you are not supposed to mess with those folders, not matter if they are accessible. You don't start going into your system32 folder, just because microsoft decided not to hide that folder for most users.

And for mods it should be good practice to have configuration menus instead of files. However we could discuss adding a public configuration folder for that reason.

[MaPePeR]

I think that problem of unique identifier shouldn't be a problem of the modloader but the mod makers. if they create mods with the same name we can still load them, but its up to the authors to make the names unique.