Closed Sewer56 closed 2 months ago
In addition, there are extensions which introduce support for IOutputDataProvider and IFileDataProvider from the Nx archive.
What are those doing here? They should be in the NX or App repo.
They should be in the NX or App repo.
No matter what I do here, someone will not be happy.
It ideally should be tied in its own repo, because our workflows are not suited for situations where you only want to release some packages that exist in a repository. That is what I personally would prefer to do.
Putting it in any other repository would just lead to either having to upload the package manually (which I don't mind, changes would be rare), or having millions of different versions of the package with literally no changes.
Alternatively, we need a system that doesn't tie the package version to tag version for all projects.
I put it in a separate project here, as I figured it would be the location that would receive the least complaints. I don't want you complaining that I'm putting too much effort again. And also, because it needs an updated NexusMods.Paths
, so you could release both at once.
Anyway, brb, I gotta reboot to (and reinstall, because it's broken) Windows and fix a case of seemingly open handles.
RE. Nx repo.
That's stuck waiting in limbo until this is merged.
xxHash
lib as a dependency and not use my own modified copy.Paths
as a dependency because NuGet.Build.props
sets the versions for all projects at the moment.I just don't want to be a nuisance; so I haven't bugged anyone about it as it's not urgent.
It's not super awesome that the details of other libraries are leaking into .Paths, it's somewhat due to OSes not providing common abstractions over memory mapped files, and so if we want to provide abstractions this is probably the most logical place for it, especially if we want testable interfaces. So I'm 👍 on this one.
Ping me when the tests pass and I'll review it quickly
Reinstalling windows (since mine was borked) and setting stuff up took a bit longer than expected. 😅
In any case, just a small commit, I just needed to dispose handles earlier since I run the tests on both Real and InMemory FS. So cleanup (file delete) couldn't happen while it was technically 'in use'.
Good to review.
I think tomorrow morning I'll add extension methods for NxRepackerBuilder
and NxUnpackerBuilder
for convenience into the Nx Extensions
package in separate PR. Then it'll be a-ok for release.
This PR adds the ability to write to Memory Mapped Files.
In addition, there are extensions which introduce support for IOutputDataProvider and IFileDataProvider from the Nx archive library. These are in an 'Extensions' package.
This will allow us to run Garbage Collection tests in memory.