Add MSBuild step to auto-generate the .NET worker's AssemblyInfo based on the webjobs extension's version.

[davidmrdavid]

Another step in the effort to minimize our release burden. This adds a "before build" step to the webjobs extension that re-generates the AssemblyInfo file of the Worker.Extensions.DurableTask project, so that it is kept up to date with the "Version" tag of the WebJobs extension.

[cgillum]

I think there's a simpler way to do this, which I added to the MSSQL project just the other day. Take a look and see if it applies: microsoft/durabletask-mssql#213

[davidmrdavid]

Yep, Jacob just linked it to me - funny timing

[jviau]

Before we commit to auto-generating this, I think this may cause build issues. If we always point to the latest WebJobs version, what happens when that version is not yet published? We may encounter the following problems:

1. Accidentally release Worker extension pointing to an unreleased WebJobs extension.
2. Unable to build dotnet isolated smoke tests project as it will try to nuget-restore an unpublished WebJobs extension.

[davidmrdavid]

@jviau yeah those are fair concerns. Let me provide my 2 cents on them:

Accidentally release Worker extension pointing to an unreleased WebJobs extension.

In my mind, this is a solvable problem - there should be quality gates in ADO preventing us from doing this. I'm happy to park this particular investment if you think that having those checks in place should be a pre-requisite here. In theory, this should be "as easy as" creating smoke tests with a limited nuget.config file that points only to NuGet (no ADO).

Unable to build dotnet isolated smoke tests project as it will try to nuget-restore an unpublished WebJobs extension.

You got me with this one :-) .

My take is that - when running smoke tests for PR validation, we should run against with the version of the WebJobs extension currently in the branch (because we usually release the WebJobs extension and the .NET isolated extension + SDK at the same time). But that would require some hackery in the build (maybe we can pack the extension and load it locally, not from any remote package index?).

I can think of various solutions here but first I'd like to check the premise - do you agree that it would be better to have the .NET isolated smoke test use the WebJobs extension built from the repo (so it can test unreleased code), or do you think it should always testing against the latest NuGet payload? I guess an easy answer is - it should do both.

[jviau]

I can think of various solutions here but first I'd like to check the premise - do you agree that it would be better to have the .NET isolated smoke test use the WebJobs extension built from the repo (so it can test unreleased code), or do you think it should always testing against the latest NuGet payload? I guess an easy answer is - it should do both.

I think smoke tests should use the WebJobs extension built from the repo. But then have a separate step in release which will verify we have released the correct version to the appropriate feed already (so check ADO when publishing to ADO, check nuget when publishing to nuget).