search

AArnott / CodeGeneration.Roslyn

Assists in performing Roslyn-based code generation during a build.
Microsoft Public License
408 stars 60 forks source link

Where does the CGR packaging actually happen? #143

Closed mwpowellhtx closed 5 years ago

mwpowellhtx commented 5 years ago

I'm not seeing any packages land subsequent to building any of the project artifacts in the solution. Would it be sufficient to add the requisite project level flags driving the packaging process?

Corollary to that is, what's the purpose of CodeGeneration.Roslyn.Tests.RunBuild? I read the comments, but it is not a console application, nor does it depend on any projects that would substantiate the claim.

Thanks!

mwpowellhtx commented 5 years ago

I think I see, build is pipelined end-to-end via Azure, although I'm curious why intermediate projects being build would not benefit from packaging along the way. Excepting perhaps it is a multi-targeting bug? At least from other projects, I seem to recall there are bugs multi-targeting more than one netstandard version, for instance.

AArnott commented 5 years ago

I'm not seeing any packages land subsequent to building any of the project artifacts in the solution. Would it be sufficient to add the requisite project level flags driving the packaging process?

These are just standard .NET SDK projects. Although the official build happens in Azure Pipelines, we've been careful to keep it simple so that the full effect of the official build can be trivially reproduced locally. I think what you're missing is running the Pack target. By default, .NET SDK projects just build when you build them. If you want them to take the extra step and time to create nuget packages you must run the pack target. There's a command in VS to do this, or you can use dotnet pack or msbuild /t:pack. In the Azure Pipeline, we use /t:build,pack to pack and build projects even if they don't pack (e.g. test projects).

although I'm curious why intermediate projects being build would not benefit from packaging along the way.

Which intermediate project are you talking about? All the projects that can or should pack do.

what's the purpose of CodeGeneration.Roslyn.Tests.RunBuild

From its program.cs file:

https://github.com/AArnott/CodeGeneration.Roslyn/blob/d04fe73dadefd9e81491bb4b5684f76f8c4699e5/src/CodeGeneration.Roslyn.Tests.RunBuild/Program.cs#L10-L11

Excepting perhaps it is a multi-targeting bug? At least from other projects, I seem to recall there are bugs multi-targeting more than one netstandard version, for instance.

I'm not aware of any multitargeting bug when targeting multiple netstandard versions (which I do frequently).

mwpowellhtx commented 5 years ago

Outside of the Pipelines, they do not, that is, pack, that's why I was curious. I think packaging from a project perspective requires GeneratePackageOnBuild be set to true. Otherwise, if they are packing, I think it is a side effect of the Pipeline instructions, the Pack target.

I did not see any project references, etc, in the RunBuild project that would lead me to believe any such build dependency should be expected. Perhaps I am missing something, i.e. perhaps it is a Pipeline thing?

Re: multi-targeting, well, I could be wrong, but I frequently receive errors concerning NuGet restore when I try to multi-target multiple netstandard versions.

AArnott commented 5 years ago

I think we have some confusion to clear up. .NET SDK projects have 3 states when it comes to packing:

  1. never produce packages, set by this msbuild property IsPackable=false
  2. produce packages when asked. This is the default.
  3. always produce packages when built. This is done with GeneratePackageOnBuild=true

I use the first two kinds in all my repos. I never use the 3rd, since that just slows down every build by adding a pack step even when I have no use for the package when debugging.

Azure Pipelines doesn't influence any of the above. But because my packable projects fall into category no. 2, my Pipeline YML file builds the build and pack targets so that all projects build, and the packable projects also pack.

RunBuild is really just an empty console project. It should probably have a launchSettings.json file checked in or something to help make it "work by default", but the idea is that a developer can set up debug launch settings so that it invokes a build on another project but with the debugger attached to that msbuild.exe process so that we can debug the CG.R msbuild task or dotnet codegen tool that is invoked. As such, there are no project references because no build of CG.R is required -- it is a prereq that you've already installed a packaged version of CG.R into another project in order to debug it.

mwpowellhtx commented 5 years ago

Ah, I see. I did see some comprehension of launchSettings. I appreciate the clarification, thanks. I don't mind the artifacts generated during GeneratePackageOnBuild; with a little extra effort that can be cleaned up just prior to the build in the directory build properties, or even conditional based on a Release build, for that matter. Anyway, thanks again.