Fix winget after a call to winget settings export #2767
Conversation
| } | ||
| catch (...) | ||
| { | ||
| AICLI_LOG(Core, Error, << "Failed to read settings.json file.. Reason unknown."); |
There was a problem hiding this comment.
| AICLI_LOG(Core, Error, << "Failed to read settings.json file.. Reason unknown."); | |
| AICLI_LOG(Core, Error, << "Failed to read settings.json file. Reason unknown."); |
| return ParseSettingsContent(settingsContentStr, setting.Name, warnings); | ||
| } | ||
| } | ||
| catch (const std::exception& e) |
There was a problem hiding this comment.
This exposes the scenario where both the normal and backup settings fail, which can result in no output to the user about settings load failure? I think it just means an else for when the backup settings fails to load (~line 520 now) where we put in a different warning about not being able to load any settings file.
| @@ -518,6 +518,10 @@ namespace AppInstaller::Settings | |||
| m_type = UserSettingsType::Backup; | |||
| settingsRoot = settingsBackupJson.value(); | |||
| } | |||
| else | |||
| { | |||
| AICLI_LOG(Core, Warning, << "Failed loading settings files."); | |||
There was a problem hiding this comment.
I was thinking more along the lines of the user visible portion (without opening the log file). So a new:
m_warnings.emplace_back(StringResource::String::SettingsWarningWhoopsSettingsDidntLoad);
That would then at least warn the user "Hey, we couldn't load any settings, so you are getting the default behavior".
| @@ -933,7 +934,8 @@ namespace AppInstaller::CLI | |||
| { | |||
| try | |||
| { | |||
| if (!Settings::User().GetWarnings().empty()) | |||
| if (!Settings::User().GetWarnings().empty() && | |||
| !WI_IsFlagSet(command->GetOutputFlags(), CommandOutputFlags::IgnoreSettingsWarnings)) | |||
There was a problem hiding this comment.
As discussed, I would think this would be better done using the output channels mechanism, but this is acceptable.
The nice thing about that mechanism being built out is that any error/exception could be output in a JSON format as well. But we have only so much time.
Fix bug introduced by #2719
Using
Runtime::GetPathTousesPathDetailswhich creates a directory when PathDetails.Create is true (which is the default). Whenwinget settings exportis called, that makes the code create a directory named the same as the settings file. Now, next winget run will try to open the file but it will find out it is a path and give up on life.Since
Runtime::GetPathTois more related to path, getting the user settings json file path is not the best option. Move logic to UserSettings.cpp. Also catch the exception when trying to parse the fail to not make winget fail but use the default settings is something happens.Microsoft Reviewers: Open in CodeFlow