Hard to set Version in a task imported from a NuGet package

[clairernovotny]

Not sure where this belongs, but when updating GitVersionTask to support the SDK builds (inner and outer loop), it was very hard to inject a target into the pipeline early enough where we can get variables usable in a PropertyGroup at the top of the project file.

The simple example is that I want to set Version at the top, but it's not clear that there's any extension points where I can run my task before that's processed. Instead, I rely on an AfterTargets to set the property value, but that's nasty.

You can see what I did here:
https://github.com/onovotny/Zeroconf/blob/6eaba492da42ca6e3c4b13a856ff42f560083cc1/Zeroconf/Zeroconf.csproj#L82-L86

There didn't seem to be a way to set those properties earlier -- the trick is that we need some place to inject the GetVersion target before the main csproj is processed.

Ideally we need a place we can inject the task where the variables will be available to all property groups in the project file in the inner and outer loops so we can set Version related info for the AssemblyInfo and NuGet tasks.

[AArnott]

@onovotny: I haven't had a hard time getting Nerdbank.GitVersioning to integrate with the new system for assembly attributes. But the NuGet package version seems to be trickier. Is that specifically what this is about?

[AArnott]

OK, so I've found it's pretty easy to set assembly version attributes with the new SDK targets.
But it seems to be impossible to set the NuGet package version because the msbuild imports from the referenced package are not imported at all for the project instance that executes the Pack target. I filed #530 to track this.

[clairernovotny]

@AArnott the issue is that I don't want to set the Version attribute in my target. For GitVersion, what its target does is generate a dozen variables/properties. I want to use them in a Version attribute at the top of my project's csproj file. 

The issue is that based on the top-down parsing of projects/variables, my task has to run before msbuild reads the main csproj -- so the question is what is the correct task to "latch on to" to ensure my task runs early enough so that the variables are available then.

[AArnott]

It sounds like you're asking for an MSBuild Task to execute before project evaluation has even completed. That's not supported by MSBuild itself. Evaluation happens first, then (maybe) targets execute. It is certainly possible for you to set the Version property in your nuget package's .props file such that it impacts the rest of the user's project, but not if its value depends on execution of an MSBuild task. If it did, you'd need to set the property in a Target and that won't execute until the entire project has been evaluated.

Am I understanding your goal correctly?

[clairernovotny]

I think so.... so sounds like what we need is something like this:

a separate property like GitVersionSetVersionString (or some such) that has a value of $(GitVersion_Foo).bar. Then, in the GetVersion task itself, if that property is not blank, we'd override the main Version with the values the user asked for.

The goal is to enable the user to choose which variable(s) they want to pick from what GitVersion produces to use as their version.

So then I suppose what's needed then is to know the "correct" task to inject our task before to ensure it works for both AssemblyInfoGeneration (that's new for the SDK) and for the NuGet pack target (that presumably works on the outer loop if there's multi-targeting. Would that work?

[AArnott]

I'm not sure what you mean by the "outer loop". I'm pretty new to these SDK targets myself but from what I can tell, when you build one of these projects, the project itself invokes itself to build each target framework, then the original project can pack itself. So while one might say there's an "inner loop" (I'm guessing it's actually implement via MSBuild batching rather than a new loop construct), I don't know what an "outer loop" would be.

If you're hoping that your task can set a property that the project file itself can consume and then set more properties based on (so "the user [can] choose which variable(s) they want to pick from what GitVersion produces to use as their version"), the user would have to write an actual MSBuild <Target> in their project file in order to consume your produced value. That's a pretty tall order IMO to ask users to do that.

Nerdbank.GitVersioning takes a different approach: set the properties. Don't leave the work to the user. Now the user could pass data to your Target some way or another that would configure your Target to set specific properties specific ways. That's roughly what NB.GV does.

[clairernovotny]

Now the user could pass data to your Target some way or another that would configure your Target to set specific properties specific ways. That's roughly what NB.GV does.

That's what I was suggesting earlier by that GitVersionVersionString property above. I think I can pass in a string containing variables that get evaluated in the task to generate the Version property. I'll need to play some more here. Guess what I'd need for this is a "lazy eval" of the property, is that possible? I.e., If I have:

<GitVersionVersionString>$(GitVersion_SemVer)</GitVersionVersionString> somewhere, I don't want that evaluated until sometime later in my task that will read GitVersionVersionString and use the value then. Is that possible?

[AArnott]

You can escape the value of the property so that MSBuild evaluates it by unescaping it but otherwise leaves the macro intact. But I don't think there's a way to get MSBuild to evaluate it later, even in a Target, since to reference that property you'd use $(GitVersionVersionString) which would evaluate to the macro, and not double-evaluate it as you'd need. And no MSBuild Task could evaluate it for you because Tasks don't have access to the MSBuild ProjectInstance that would be necessary.

[dsplaisted]

@onovotny I think the best solution is to use a target to set the version properties. Evaluation within a target can depend on properties set by targets that ran previously.

I think you should be able to structure the package so that by default it sets the Version to a reasonable value (eg GitVersion_SemVer). If you want to override that, you can add a target to your project file. You put the default target in a .props file in your NuGet package, so that if the same target name is defined in the project, it will override the one from the package.

You can probably set the target dependencies in the props/targets in the NuGet package so that you don't need to explicitly declare any of them on the target that goes in the project file.

I'm closing this issue since I don't know what we could do in the SDK to make this easier.