Dev > Main #3
Merged
Dev > Main #3
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Old name no more.
Since we don't use SDK Pack at all and we want to target NS2.
Previously, we were only partially supporting multi-targeting via GetPackageContents mostly and not much more. This refactors the common targets that should apply in both multi and single targeting pack into NuGetizer.Common.targets so it can be shared by both. A test now ensures that things works as expected, as well as avoiding duplicate metadata content item. As part of this improved metadata support, we also introduce the GetPackageMetadata target so we separate and centralize the package metadata from the package target path as well as the pacakge file item created from it (all slightly different but sharing most metadata values).
The traditional way of extending package metadata was to simply hardcode an ever-growing number of properties. In order to have a more flexible and extensible mechanism, we now use those properties to feed into a single @(PackageMetadata) item per packagable project, which contains those properites much like before. Having a separate item type for the metadata (rather than just creating a PackageTargetPath and a _PackageFile with Metadata kind, allows extending the metadata for that item also via an ItemDefinitionGroup. In addition, if the project itself already includes an item PackageMetadata, we simply use that instead and avoid creating a second one or overriding the explicitly created values.
Showcase adding metadata, since built-in values will still pick up the supported properties, which should be the mechanism to extend them.
Makes more sense since we don't have any "secondary" outputs. This renames both PrimaryOutputKind > BuildOutputKind and PrimaryOutputFrameworkSpecific > BuildOutputFrameworkSpecific. We also remove old workarounds for PRs that have since shipped for a while in MSBuild.
And add new icon too :)
This makes it more intuitive and aligns with SDK Pack. Also, since de-duplication is performed in the CreatePackage task, the targets were being overzealous with that and preventing the valid scenario (like we have ourselves!) of using the same source file and place it in different package paths (we do so for various multi-targeting ones.
The tests dealt with a lot of legacy cases where projects were not SDK-style and other weird setups for faking frameworks and the like. By unifying all test scenario projects on SDK-style and leveraging the SDK built-in support for turning off standard framework resolution via DisableStandardFrameworkResolution (see dotnet/sdk@bba2f8087), we could significantly simply the targets that simulate a full package reference to NuGetizer scenario.
It's quite common for BuiltProjectOutputGroupOutput and BuiltProjectOutputGroupKeyOutput to include the same output, so we deduplicate.
This allows collecting diagnostic logs from CI in DevOps when things fail unexpectedly.
When running Pack from the IDE, the output tasks assembly will be locked, so it requires killing MSBuild.exe afterwards, but it can be a convenient way to peek at the output. Alternatively, you can set MSBUILDDISABLENODEREUSE=1 via envvar (i.e. before launching VS) and that would allow a more iterative approach.
It contains all the original manifest metadata in addition to the actual target path created in the CreatePackageTask. It seems more appropriate, in case we add more info in the task, for example, that might be missing in the `PackageTargetPath` item.
This allows the 42.42.42 in the .props to be replaceable via a -p:versionprefix= MSBuild argument, which could still preserve the branch+height suffix.
The previous approach was relying on the item definition group alone to set the repository properties. This was insufficient to catch the values updated by a source control provider. So we now support a mix of both properties and item metadata, as follows: * Basic tweaking: expected to be done like in SDK Pack, using properties. These can also be modified via targets and things will just work i.e. updating a Description from a target running before GetPackageMetadata, for example. * Advanced tweaking: for advanced metadata manipulation, we'll support preserving an already created PackageMetadata item for the project's PackageId, and will just update the repository and version info in the GetPackageMetadata target. The user can still run before/after this target and modify the resulting PackageMetadata item as needed, of course. This combination offers the maximum flexibility and future proofing in terms of package metadata.
Since the GH packages feeds are authenticated, they aren't of much use for an oss project, so stick to sleet+Azure for now. Adding .NETCore 2.1 install since sleet requires that.
This allows invoking Pack to get either (i.e. for testing or exploring what the output package would look like). Also took the chance to avoid emitting nuspec properties when the relevant item metadata is missing entirely (instead of emitting empty nuspec properties).
The tool renders in the output window the structure that a project would generate if it were to produce a nuget package. It's key that it doesn't actually require the files referenced in the project to even exist. In fact, the project doesn't even have to build, since it's built as if it were a design-time build and the compiler invocation is skipped. This allows a very nice exploration of nugetizer capabilities without actually having to produce a bunch of empty files to explore what metadata causes which items to end up in which folders.
Both the test and dotnet tool had a build dependency (but not a project reference) to the tasks project, but were getting an implicit project reference that caused a build during pack too. See https://www.cazzulino.com/project-dependencies-as-project-references.html for more information.
This delays the inclusion some more.
So we can have predictable builds and outputs always.
This adds consistency with the other item types.
Instead of doing so many brittle hacks, just assume the project will already be packable and have the right metadata in place. So it's mostly a tool for quickly inspecting changes to a project. Simplify also the way the multitargeting targets are copied and used, so that there's minimal stuff in the buildMultitargeting folder. Rename NuGetizer.Common.targets to NuGetizer.Shared.targets instead, which also makes it clearer that they are shared targets across single and multi-targeting.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.