Make assembly version logic more robust Fixes #44042 #45518
Conversation
dotnet-issue-labeler
bot
added
Area-NetSDK
untriaged
| var runtimeFile = !string.IsNullOrWhiteSpace(assemblyPath) && File.Exists(assemblyPath) ? CreateRuntimeFile(referenceProjectInfo.OutputName, assemblyPath) : | ||
| !string.IsNullOrWhiteSpace(library.Path) && File.Exists(library.Path) ? CreateRuntimeFile(referenceProjectInfo.OutputName, library.Path) : | ||
| new RuntimeFile(referenceProjectInfo.OutputName, string.Empty, string.Empty); |
There was a problem hiding this comment.
Do you know if there are cases where each of these clauses are true? (IE will it ever be the case that assemblyPath doesn't exist but libraryPath does, or that neither of them exist?
There was a problem hiding this comment.
In theory, at least, yes. This gets run as part of a (publicly available/tweakable) Task, so the user can set, for instance, what userRuntimeAssemblies are available --> whether anything gets found for assemblyPath as well as whether a library really exists on disk. This should only be for things that get copied to the output directory, but given that users can customize the inputs, I wouldn't depend on that. Good question.
There was a problem hiding this comment.
I think in a case like this it would be OK to change task logic. The task isn't meant for public consumption, so it's probably OK to make a minor change that probably won't break people even if they are using it.
There was a problem hiding this comment.
I think in a case like this it would be OK to change task logic. The task isn't meant for public consumption, so it's probably OK to make a minor change that probably won't break people even if they are using it.
There was a problem hiding this comment.
Totally agree with Daniel here.
Fixes #44042
Replaces the way we look for assembly version.
Without change:
With change:
