BSAs with zero-length folder names (I'm presuming where there are consecutive backslashes in a path) caused a negative-length read from a file. Now they don't.
Otherwise things like trying to load OMODFramework DLLs with a zone identifier (e.g. because I've asked someone to try something with a modified version to debug an issue) will generate a .NET exception and crash MO2, producing an undebuggable crash dump. Mixed mode and native see only external code, and managed insists the crash is in native code without preserving the exception that native code threw.
At least one OMOD needs to extract files from existing BSAs. Thankfully,
basically everything needed for that was already in OMODFramework, and
it just needed telling which BSAs were active at the time of mod
installtion. Annoyingly, it took them as a HashSet, so I needed to
change to an ordered collection, hence the version bump. Also, MO2 won't
tell plugins which BSAs are actually active, so this has to reconstruct
the list. It assumes archive invalidation is active in some form or
other, but MO2 has that built-in, and presumably no one's ever turned it
off.
This doesn't actually fix the problematic mod as it then packs a new BSA
which OMODFramework can't handle yet.
As well as checking for the non-Steam-friendly obse_loader.exe, this now
checks the force loaded libraries for any OBSE files, too.
It also converts from FileVersionInfo to Version via ints rather than a
string as it turns out the string format isn't compatible. Version wants
a.b.c.d but FileVersionInfo gives a, b, c, d. I think this changed at
some point as I think I copied the previous code from OBMM.