fix: BuildTasks assembly reference resolution and add DsComExportTypeLibraryDependsOn hook

[carstencodes]

• Adds a new MSBuild property: DsComExportTypeLibraryDependsOn
  • Allows configuring targets that must run before dscom execution
  • Default value is DsComAddAssemblyReferencesAutomatically
• Introduces DsComAddAssemblyReferencesAutomatically
  • Runs after ResolveReferences
  • Collects reference assembly paths from ReferencePath
  • Supports both references with HintPath and references without hint path
• Fixes --asmpath argument generation in BuildTasks.Tools.targets
  • Uses normalized assembly directories instead of raw file paths
  • Removes trailing slashes from resolved assembly paths
• Updates DsComExportTypeLibraryAfterBuild to depend on $(DsComExportTypeLibraryDependsOn)
  • Changes the export command behavior
    • Exec now ignores the raw exit code
    • Emits DSCOM005 warning when dscom fails while the TLB file exists
    • Keeps existing DSCOM001 warning when the TLB file is missing
• Documents the new property in [README.md]

Fixes bug #440 by improving build task dependency handling, reference discovery, and export result reporting.

[marklechtermann]

Thanks, Carsten. The reported problem appears to be fixed: the NuGet dependency is resolved correctly and the affected type is included in the generated type library.

However, could changing IgnoreExitCode from false to true be an unintended side effect? A failing dscom invocation can now result in a successful MSBuild exit code. This change does not seem necessary for fixing #440.

I suggest keeping IgnoreExitCode="false" and limiting this PR to collecting the resolved NuGet references after ResolveReferences. If special exit-code handling is required, it should be addressed separately with the intended failure semantics clearly defined.

@matthiasnissen, could you please confirm this assessment?

[matthiasnissen]

Agree with @marklechtermann's assessment. The reference-resolution fix (ResolveReferences/ReferencePath, --asmpath normalization) is clean and correctly scoped to #440.

However, IgnoreExitCode=true is an unrelated, potentially breaking behavior change: a failing dscom invocation would no longer fail the build (only emits a DSCOM005 warning). CI pipelines relying on the exit code wouldn't catch that anymore.

Suggestion: split this out into a separate PR/discussion (maybe as an opt-in property) so the actual bugfix can be merged independently.

[carstencodes]

@marklechtermann @matthiasnissen I agree with your opinion on the ExitCode. But dscom always created the TLB file, even error state.
Nevertheless, I reverted the commit.