Build Target/Task simplification #83

amis92 · 2018-08-20T14:24:18Z

I've been browsing Microsoft's XML Serializer Generator tool: https://github.com/dotnet/corefx/tree/master/src/Microsoft.XmlSerializer.Generator

I've discovered it uses a similar approach of calling a dotnet CLI tool through MSBuild Target, although it does that using simple MSBuild tasks, instead of C# code DLLs, which seems to simplify greatly making it "cross-platform" (it's automatic).

So I've taken to modify this project to work in a similar manner.

One thing which requires explanation for sure:

Sanitize method in CLI tool Program.cs is needed because of multiple empty lines written into response file by MSBuild task.

How it works now

Instead of delivering multiple props and targets, only one, universal, is included in NuGet. .targets contains a Target that has "inlined" the work that the old DLL ToolTask did. It produces a response file and calls dotnet-codegen with appropriate arguments.

Due to that, whole C# task could be deleted, as well as all target-specific props and targets files.

Also, because there was no need to find DLL's path, plumbing for overriding the path was no longer needed (e.g. in Unit Tests).

I'm interested in your thoughts about that.

Disclaimer: I think it's not yet complete, I haven't tested yet the newly produced package.

AArnott · 2018-08-20T14:29:02Z

Looks interesting. I didn't used to have a CLI tool at all, but as you say, going cross platform (or even just working with multiple versions of MSBuild and roslyn) necessitated it. So going "all the way" may be worthwhile. I look forward to reviewing this--hopefully soon.
In the meantime, it looks like one of the two PRs I completed this morning created a conflict with your change.

AArnott

I'm a bit on the fence about this change. I find C# easier to read than MSBuild syntax when we're doing a lot of variable manipulation.
Is the real win here that we can repeatedly build this repo without locked file errors causing the build to fail?

AArnott · 2018-08-20T17:24:49Z

src/CodeGeneration.Roslyn.Tasks/build/net20/CodeGeneration.Roslyn.BuildTime.props

@@ -1,4 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<Project ToolsVersion="14.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
-  <Import Project="..\$(MSBuildThisFileName)$(MSBuildThisFileExtension)" />


Have you confirmed that with the removal of all these files that the resulting package still correctly installs into projects with all these target frameworks?
I added them because (at least at the time) nuget would consider a top-level build file as a net40 targeted file, so it wouldn't add the import to net20 or other target framework projects.

I've confirmed that (after my incoming fixes) it works for net20, net40, net45, netstandard1.0 and netstandard 2.0. Portable targets aren't supported, but it can be probably done, if necessary.

It'll probably require using MsBuildSdkExtras package for multi-targeting portables

AArnott · 2018-08-20T17:25:26Z

src/CodeGeneration.Roslyn.Tool/Program.cs

            ArgumentSyntax.Parse(args, syntax =>
            {
+                syntax.DefineOption("version", ref version, "Show version of this tool.");


"...of this tool (and exits)."

That way it's clear it's not really an option, but a command that ignores anything else on the command line.

Good point.

AArnott · 2018-08-20T17:26:56Z

src/CodeGeneration.Roslyn.Tasks/CodeGeneration.Roslyn.Tasks.csproj

+        <PackagePath>build\</PackagePath>
+      </None>
+    </ItemGroup>
+    <Message Text="None now includes: @(None->'%(Identity) Pack:%(Pack) PackagePath:%(PackagePath)')" Importance="high"/>


I'm guessing this <Message> was for your own diagnostic purposes and shouldn't be retained in the PR.

Indeed. Will be removed.

AArnott · 2018-08-20T17:27:14Z

src/CodeGeneration.Roslyn.Tasks/CodeGeneration.Roslyn.Tasks.csproj

+    <XmlPoke XmlInputPath="$(PropsFilePath)" Value="$(PackageVersion)" Query="/dn:Project/dn:ItemGroup/dn:DotNetCliToolReference/@Version" Namespaces="$(_ProjectNamespaces)" />
+    <ItemGroup>
+      <None Remove="build\$(PropsFileName)" />
+      <None Include="build\$(PropsFileName)">


Why remove and include when you can Update?

Updating doesn't work for me. When I do just Update, all items in group have Pack set to false, instead of only the one.

Also it's very restricted as per docs: https://docs.microsoft.com/pl-pl/visualstudio/msbuild/item-element-msbuild#attributes

Hmmm.... it seems like it ought to have worked here. All the "restrictions" are satisfied in this case as far as I can tell. Oh well, thanks for trying.

AArnott · 2018-08-20T17:28:07Z

src/CodeGeneration.Roslyn.Tasks/build/CodeGeneration.Roslyn.BuildTime.props

-    </Compile>
-  </ItemDefinitionGroup>
+  <ItemGroup>
+    <!--This item's Version metadata is updated to match the package's one in .csproj-->


Can you elaborate on this comment to specify that the substitution is done at build-time by the SetPackageVersionInProps target?

AArnott · 2018-08-25T00:55:58Z

Thanks for responding to my review. Can you resolve the conflicts that remain?

* drop build output (empty dll) from package * add net20 target * clear up build contents handling * mark as development dependency * set MinClientVersion to 2.5 as it's the first handling build/ contents * add printing tool version at normal importance

amis92 · 2018-08-25T01:10:19Z

I'm a bit on the fence about this change. I find C# easier to read than MSBuild syntax when we're doing a lot of variable manipulation.
Is the real win here that we can repeatedly build this repo without locked file errors causing the build to fail?

I think it's the biggest practical win. I think it might be a little less readable, but since it follows a pattern found in MS XmlSerializer Generator, and drops the size of the package considerably (2MB->4kB), it's worth it.

amis92 · 2018-08-25T01:17:15Z

There's also an issue that I'm not sure how to resolve, namely the files that the build additionally produces (response file and txt file with generated files list) aren't deleted nor overwritten by future builds.

Probably it'd be best to make these file names static, but also avoiding any conflicts... How would one do such thing? Taking inspiration from existing C# pipeline, probably suffixing project name would suffice?

* Normalized .targets property names * Static .rsp and FileList.txt file names * normal importance of Exec console outputs * MSBuild-recognized format of logs from Logger * add actually empty files to CompilationGenerator.EmptyGeneratedFiles

amis92 · 2018-08-25T19:02:31Z

More fixes:

Fix logging levels after c# task removal

Normalized .targets property names
Static .rsp and FileList.txt file names
normal importance of Exec console outputs
MSBuild-recognized format of logs from Logger
add actually empty files to CompilationGenerator.EmptyGeneratedFiles

amis92 · 2018-08-25T19:34:06Z

And portable targets for BuildTime package are in. Also, upgraded MSBuildSdkExtras usage in Attributes.

I think that'd be all. :)

amis92 · 2018-08-28T13:06:20Z

@AArnott so what's your final decision? Does it go in, or do we stay with the C# task?

amis92 · 2018-09-04T08:45:27Z

@AArnott pinging again :)

AArnott

Thanks!

amis92 · 2018-10-03T14:47:51Z

For reference: #102 (comment)

amis92 added 3 commits August 14, 2018 07:50

Redone the BuildTime package, removed Task dll

2165cd2

Make BuildTime targets purely XML based

53f5c4c

Add Version switch to CLI tool

81398f8

AArnott suggested changes Aug 20, 2018

View reviewed changes

amis92 added 2 commits August 25, 2018 03:02

Pull Request review corrections

2fee6ce

* drop build output (empty dll) from package * add net20 target * clear up build contents handling * mark as development dependency * set MinClientVersion to 2.5 as it's the first handling build/ contents * add printing tool version at normal importance

Merge branch 'master' into feature/task-simplification

3138260

Fix logging levels after c# task removal

394eb89

* Normalized .targets property names * Static .rsp and FileList.txt file names * normal importance of Exec console outputs * MSBuild-recognized format of logs from Logger * add actually empty files to CompilationGenerator.EmptyGeneratedFiles

Update MSBuildSdkExtras, portable targets for BuildTime package

d7f89df

amis92 added 2 commits August 26, 2018 12:47

Retract some unnecessary changes for PR #83

356a0a1

Merge branch 'master' into feature/task-simplification

8f0c1f3

AArnott approved these changes Sep 4, 2018

View reviewed changes

AArnott merged commit e454034 into AArnott:master Sep 4, 2018

amis92 mentioned this pull request Sep 11, 2018

Unable to build sample project in Visual Studio #26

Closed

amis92 deleted the feature/task-simplification branch November 23, 2018 23:16

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Build Target/Task simplification #83

Build Target/Task simplification #83

amis92 commented Aug 20, 2018

AArnott commented Aug 20, 2018

AArnott left a comment

AArnott Aug 20, 2018

amis92 Aug 25, 2018

amis92 Aug 25, 2018

AArnott Aug 20, 2018

amis92 Aug 24, 2018

AArnott Aug 20, 2018

amis92 Aug 24, 2018

AArnott Aug 20, 2018

amis92 Aug 24, 2018

AArnott Aug 24, 2018

AArnott Aug 20, 2018

amis92 Aug 24, 2018

AArnott commented Aug 25, 2018

amis92 commented Aug 25, 2018

amis92 commented Aug 25, 2018

amis92 commented Aug 25, 2018

amis92 commented Aug 25, 2018 •

edited

Loading

amis92 commented Aug 28, 2018

amis92 commented Sep 4, 2018

AArnott left a comment

amis92 commented Oct 3, 2018

Build Target/Task simplification #83

Build Target/Task simplification #83

Conversation

amis92 commented Aug 20, 2018

How it works now

AArnott commented Aug 20, 2018

AArnott left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AArnott commented Aug 25, 2018

amis92 commented Aug 25, 2018

amis92 commented Aug 25, 2018

amis92 commented Aug 25, 2018

amis92 commented Aug 25, 2018 • edited Loading

amis92 commented Aug 28, 2018

amis92 commented Sep 4, 2018

AArnott left a comment

Choose a reason for hiding this comment

amis92 commented Oct 3, 2018

amis92 commented Aug 25, 2018 •

edited

Loading