// LockFileUtilties.GetLockFile has odd error handling:
//
// 1. Exceptions creating TextReader from path (after up to 3 tries) will
// bubble out.
//
// 2. There's an up-front File.Exists that returns null without logging
// anything.
//
// 3. Any other exception whatsoever is logged by its Message property
// alone, and an empty, non-null lock file is returned.
public LockFile Read(TextReader reader, ILogger log, string path)
{
try
{
var json = JsonUtility.LoadJson(reader);
var lockFile = ReadLockFile(json);
lockFile.Path = path;
return lockFile;
}
catch (Exception ex)
{
log.LogError(string.Format(CultureInfo.CurrentCulture,
Strings.Log_ErrorReadingLockFile,
path, ex.Message));
// Ran into parsing errors, mark it as unlocked and out-of-date
return new LockFile
{
Version = int.MinValue,
Path = path
};
}
}
In the recent assembly binding conflict episode, exception there was FileLoadException and the message was something about an assembly manifest mismatch!
See this comment going in to SDK:
I had to read the source code to figure this out:
LockFileUtilities.cs
The comment "A corrupt lock file will log errors and return null" is wrong.
LockFileFormat.cs:
In the recent assembly binding conflict episode, exception there was FileLoadException and the message was something about an assembly manifest mismatch!
When I read code like above, I see: