Closed richardszalay closed 5 years ago
The above means that HPP can't actually support mapping of the most common unicorn convention.
This proposal is to allow convention based "splitting" of module names into additional metadata fields using a regular expression with named groups.
Example:
<ItemGroup> <HelixModuleMetadataPattern Include="^(?<Namespace>.+)\.(?<Layer>.+)\.(?<Module>.+)$" /> </ItemGroup>
Patterns would be applied to the module Filename (without extension) and, if successful, the named groups would be added as metadata into the item.
Applying the above example to the module "TestProject.Foundation.Serialization", the following content mapping would now be possible:
<AdditionalFilesForPackagingFromHelixModules Include="Serialization"> <SourcePath>..\serialization\**\*.yml</SourcePath> <TargetPath>App_Data\unicorn\^(HelixModule.Namespace)\^(HelixModule.Layer)\^(HelixModule.Module)\^(RecursiveDir)^(Filename)^(Extension)</TargetPath> </AdditionalFilesForPackagingFromHelixModules>
These variables could be used in conjunction with any metadata defined on the ProjectReference
ProjectReference
The above means that HPP can't actually support mapping of the most common unicorn convention.
This proposal is to allow convention based "splitting" of module names into additional metadata fields using a regular expression with named groups.
Example:
Patterns would be applied to the module Filename (without extension) and, if successful, the named groups would be added as metadata into the item.
Applying the above example to the module "TestProject.Foundation.Serialization", the following content mapping would now be possible:
These variables could be used in conjunction with any metadata defined on the
ProjectReference