[PR #563] Remove IMAPI2 as a dependency #1043

New Issue

claunia · 2026-01-29T16:25:03Z

claunia commented

2026-01-29 16:25:03 +00:00

Original Pull Request: https://github.com/SabreTools/MPF/pull/563

State: closed
Merged: Yes

Problem

IMAPI2 is a Windows library that allows for media type detection and media burning in Windows applications. It is lightly maintained but is entirely locked to the Windows platform. IMAPI2 is a major blocker to making the entirety of MPF cross-platform, with the other major blocker being the UI framework. Removing this library would mean the end of very accurate media type detection.

Solution

Remove IMAPI2 from the application even if it means less accurate media type detection until another solution is found. This solution allows .NET Framework 4.8 builds to be built and packaged near-identically to the newer .NET 6 and .NET 7 builds and places those more modern .NET builds on equal footing.

Commentary

This is deliberately being made into a separate branch because this is a very divisive change. This removes the ability (on .NET Framework 4.8) to accurately determine the type of the media being detected, instead falling back on the same method that .NET 6 and .NET 7 use. This fallback method makes a best guess based on the media size and the filesystem.

The only dumping program supported by MPF right now that cares about the media type on dump is DiscImageCreator. It is still the default program and is the only one that benefits from this arrangement. If this is removed, there's more of a burden on the user to determine what type the media is before dumping.

This does put all 3 build versions (.NET Framework 4.8, .NET 6.0, and .NET 7.0) on equal footing for the first time, however. The build instructions become the same and no differences in functionality will be observed. For .NET Framework 4.8, this may also bring slightly more stability, given that IMAPI2 does not play well with all hardware.

Alternatives

Keeping IMAPI2 means that it can only be used on Windows ever in the future. It also is not actively maintained
Using Aaru code is possible, but a very large chunk of code would need to be imported and potentially modified to work with .NET Framework 4.8 (a separate issue unto itself)
Porting code from Redumper or another cross-platform tool is a possibility, but is not in the immediate cards for prioritized work
Using the size/filesystem method is quick and semi-reasonably accurate but can be turned off exactly like the existing solutions

**Original Pull Request:** https://github.com/SabreTools/MPF/pull/563 **State:** closed **Merged:** Yes --- ## Problem IMAPI2 is a Windows library that allows for media type detection and media burning in Windows applications. It is lightly maintained but is entirely locked to the Windows platform. IMAPI2 is a major blocker to making the entirety of MPF cross-platform, with the other major blocker being the UI framework. Removing this library would mean the end of very accurate media type detection. ## Solution Remove IMAPI2 from the application even if it means less accurate media type detection until another solution is found. This solution allows .NET Framework 4.8 builds to be built and packaged near-identically to the newer .NET 6 and .NET 7 builds and places those more modern .NET builds on equal footing. ## Commentary This is deliberately being made into a separate branch because this is a very divisive change. This removes the ability (on .NET Framework 4.8) to accurately determine the type of the media being detected, instead falling back on the same method that .NET 6 and .NET 7 use. This fallback method makes a best guess based on the media size and the filesystem. The only dumping program supported by MPF right now that cares about the media type on dump is DiscImageCreator. It is still the default program and is the only one that benefits from this arrangement. If this is removed, there's more of a burden on the user to determine what type the media is before dumping. This does put all 3 build versions (.NET Framework 4.8, .NET 6.0, and .NET 7.0) on equal footing for the first time, however. The build instructions become the same and no differences in functionality will be observed. For .NET Framework 4.8, this may also bring slightly more stability, given that IMAPI2 does not play well with all hardware. ## Alternatives - Keeping IMAPI2 means that it can only be used on Windows ever in the future. It also is not actively maintained - Using Aaru code is possible, but a very large chunk of code would need to be imported and potentially modified to work with .NET Framework 4.8 (a separate issue unto itself) - Porting code from Redumper or another cross-platform tool is a possibility, but is not in the immediate cards for prioritized work - Using the size/filesystem method is quick and semi-reasonably accurate but can be turned off exactly like the existing solutions

claunia added the pull-request label 2026-01-29 16:25:03 +00:00

claunia closed this issue

2026-01-29 16:25:03 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: SabreTools/MPF#1043