You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently AssemblyDependencyResolver does all the work in its constructor and caches the results for later use. Consider doing this lazily by storing the path to the assembly and only process its .deps.json when there's a first query on its contents.
To keep decent usability we should probably check the assembly path for existence in the .ctor and throw if it doesn't exist. But all the other failure modes would move from the constructor to the first usage.
The text was updated successfully, but these errors were encountered:
Currently AssemblyDependencyResolver does all the work in its constructor and caches the results for later use. Consider doing this lazily by storing the path to the assembly and only process its .deps.json when there's a first query on its contents.
To keep decent usability we should probably check the assembly path for existence in the .ctor and throw if it doesn't exist. But all the other failure modes would move from the constructor to the first usage.
Currently
AssemblyDependencyResolver
does all the work in its constructor and caches the results for later use. Consider doing this lazily by storing the path to the assembly and only process its.deps.json
when there's a first query on its contents.To keep decent usability we should probably check the assembly path for existence in the
.ctor
and throw if it doesn't exist. But all the other failure modes would move from the constructor to the first usage.The text was updated successfully, but these errors were encountered: