search

files-community / Files

Building the best file manager for Windows
https://files.community
MIT License
32.92k stars 2.1k forks source link

Fix: Fixed System.TypeInitializationException in FileTagsDatabase #15647

Closed hishitetsu closed 1 week ago

hishitetsu commented 1 week ago

This prevents crashes due to the exception, but the tags feature doesn't work properly in that case. It may be better to define the registry key statically instead of using Package.Current, though migration is required.

Resolved / Related Issues

To prevent extra work, all changes to the Files codebase must link to an approved issue marked as Ready to build. Please insert the issue number following the hashtag with the issue number that this Pull Request resolves.

Steps used to test these changes

Stability is a top priority for Files and all changes are required to go through testing before being merged into the repo. Please include a list of steps that you used to test this PR.

  1. Opened Files ...
  2. ...
hez2010 commented 1 week ago

I'm wondering under what circumstances can this throw an exception? Is someone trying to run Files as an unpackage app? If that is the case then it's by designed as we don't support unpackaged deployment.

hishitetsu commented 1 week ago

You may be right, or it may be a bug of Windows. But as long as the exception is occurring, I think we should take care of it.

hez2010 commented 1 week ago

I think the issue is not caused by end users but instead by developers. Someone tried to build and launch Files from VS without selecting Files.Package and encountered this exception. I don't think it's worth adding complexity to Files to address this subtle issue. Even if we fix this issue, they will immediately encounter another exception (which is hidden by this one) because unpackaged deployment is not supported at all.

0x5bfa commented 1 week ago

If we can detect if unpackaged, we could close main window and show only classic message dialog saying Unpackaged launching is unsupported, build from Files.App (Package) project at least.

hishitetsu commented 1 week ago

I think the issue is not caused by end users but instead by developers. Someone tried to build and launch Files from VS without selecting Files.Package and encountered this exception. I don't think it's worth adding complexity to Files to address this subtle issue. Even if we fix this issue, they will immediately encounter another exception (which is hidden by this one) because unpackaged deployment is not supported at all.

In that case, would an exception report be sent to Sentry?

0x5bfa commented 1 week ago

Same if you click exe directly in installed path

yaira2 commented 1 week ago

I think the issue is not caused by end users but instead by developers. Someone tried to build and launch Files from VS without selecting Files.Package and encountered this exception. I don't think it's worth adding complexity to Files to address this subtle issue. Even if we fix this issue, they will immediately encounter another exception (which is hidden by this one) because unpackaged deployment is not supported at all.

@hez2010 we only include Sentry on the release version of Files so this can't be from launching unpackaged.

yaira2 commented 1 week ago

I'd like to merge this for the v3.5 release, but if it helps, we can try logging additional info about that state of the app to try figuring out how this occurs.