Add a task to generate a manifest with the file system structure of the original files #308

javiercn · 2017-12-14T16:34:50Z

No description provided.

natemcmaster

A good start, but needs some refinement.

I'm assuming the runtime consumer will come in a separate PR?

natemcmaster · 2017-12-14T16:40:15Z

src/FS.Embedded.Manifest.Task/FS.Embedded.Manifest.Task.csproj

+    <AssemblyName>Microsoft.Extensions.FileProviders.Embedded.Manifest.Task</AssemblyName>
+    <Description>MSBuild task to generate a manifest that can be used by Microsoft.Extensions.FileProviders.Embedded to preserve
+    metadata of the files embedded in the assembly at compilation time.</Description>
+    <TargetFramework>netstandard2.0</TargetFramework>


Have you tested this when building with MSBuild.exe from a VS developer command prompt, or when building inside VS? In the past, we found it better to cross-target task assemblies to .NET Framework because MSBuild for VS didn't include ns2.0 binding redirects until 15.4

Building on VS worked just fine and I don't think the dependency on 15.4 will be an issue.

If we expect users to have 15.4 or newer, we should find a way to encode that expectation, such as setting the minimum nuget client version that corresponds to VS 15.4

we'll discuss this offline

The new packages layout will take care of this dependency

We still need to target .NET Framework. The package that uses this task would install in a project that could be as old as MSBuild 15.3. If you don't, VS users not on latest will hit TypeLoadException errors when they try to compile their app.

See dotnet/msbuild#2738

Example

<PropertyGroup> <TaskAssembly Condition=" '$(MSBuildRuntimeType)' == 'Core'">.\bin\Debug\netstandard1.6\GreetingTasks.dll</TaskAssembly> <TaskAssembly Condition=" '$(MSBuildRuntimeType)' != 'Core'">.\bin\Debug\net46\GreetingTasks.dll</TaskAssembly> </PropertyGroup> <UsingTask TaskName="MSBuildTasks.SayHello" AssemblyFile="$(TaskAssembly)" />

See also http://www.natemcmaster.com/blog/2017/07/05/msbuild-task-in-nuget/#the-solution

natemcmaster · 2017-12-14T16:41:05Z

src/FS.Embedded.Manifest.Task/FS.Embedded.Manifest.Task.csproj

+<Project Sdk="Microsoft.NET.Sdk">
+
+  <PropertyGroup>
+    <RootNamespace>Microsoft.Extensions.FileProviders.Embedded.Manifest.Task</RootNamespace>


Have you considered putting this inside the Microsoft.Extensions.FileProviders.Embedded nuget package, instead of making a new package?

You mean the MSBuild part of it? (The targets file). I would definitely keep the assembly separate

The assembly definitely needs to be separate. One way to layout this package is like this:

- Microsoft.Extensions.FileProviders.Embedded.nupkg - lib/ - netstandard2.0/ + Microsoft.Extensions.FileProviders.Embedded.dll - build/ - netstandard2.0/ + Microsoft.Extensions.FileProviders.Embedded.targets + Microsoft.Extensions.FileProviders.Embedded.Manifest.Task.dll

natemcmaster · 2017-12-14T16:42:33Z

test/Directory.Build.props

@@ -1,4 +1,4 @@
-<Project>
+<Project sdk="Microsoft.NET.Sdk">


Don't put this here. This belongs in the csproj file, not .props files. This can change the order of a target imports.

natemcmaster · 2017-12-14T16:44:51Z

src/FS.Embedded.Manifest.Task/Entry.cs

+namespace Microsoft.Extensions.FileProviders.Embedded.Manifest.Task
+{
+    [DebuggerDisplay("{Name,nq}")]
+    public class Entry : IEquatable<Entry>


Nit: can be internal since this isn't API we want anyone using directly.

I can put it on the internal namespace, but I use this all over in testing and don't want to do internalsvisibleto dance.

natemcmaster · 2017-12-14T16:53:57Z

...est.Task/build/netstandard2.0/Microsoft.Extensions.FileSystem.Embedded.Manifest.Task.targets

+      <__ManifestFiles Include="@(EmbeddedResource->WithMetadataValue('IsManifest', 'true'))" />
+    </ItemGroup>
+
+    <Error Condition="@(__ManifestFiles->Count()) > 1" Text="Multiple manifest files found. Only one manifest file per assembly is allowed: %(__ManifestFiles.TargetPath)" />


Who sets TargetPath and how? Normally, any target that generates intermediate files should put them into $(IntermediateOutputPath) (which defaults to obj/$Configuration/$TargetFramework)

Target path is set by the default manifest above to be $(IntermediateOutputPath)$(EmbeddedFilesManifestName), someone can use their own EmbeddedResource item if they want to generate the manifest somewhere else for any reason.

You want to use @(__ManifestFiles). The current approach would stop after printing the first item.

natemcmaster · 2017-12-14T16:54:32Z

test/FS.Embedded.Manifest.Task.Test/FS.Embedded.Manifest.Task.Test.csproj

+  <PropertyGroup>
+    <TargetFramework>netcoreapp2.1</TargetFramework>
+    <RuntimeFrameworkVersion>2.1.0-preview2-25624-02</RuntimeFrameworkVersion>
+    <NETStandardImplicitPackageVersion>2.1.0-preview2-25624-02</NETStandardImplicitPackageVersion>


Likewise: can be removed

natemcmaster · 2017-12-14T16:56:27Z

test/FS.Embedded.Manifest.Task.Test/GenerateEmbeddedResourcesManifestTest.cs

+                ["LogicalName"] = logicalName ?? targetPath.Replace("/", ".").Replace("\\", "."),
+            };
+
+        private class TestTaskItem : ITaskItem


You could also use Microsoft.Build.Utilities.TaskItem, which implements ITaskItem

natemcmaster · 2017-12-14T16:58:25Z

...est.Task/build/netstandard2.0/Microsoft.Extensions.FileSystem.Embedded.Manifest.Task.targets

+      LogicalName="$(EmbeddedFilesManifestFileName)" />
+  </ItemGroup>
+
+  <Target Name="GenerateEmbeddedFilesManifest" AfterTargets="PrepareResourceNames" Condition="$(EmbeddedFilesManifest) == 'true'">


This will break incremental compilation. You need to ensure you never re-write the manifest file unless the list of EmbeddedResource's changed. Typically this is done by specifying Inputs and Outputs on a target.

As the supreme MSBuild incantator, can you tell me how to do this? The manifest is already order resilient

The convention is to have targets that are implementation details (private) to start with an underscore. Consider splitting this off in to two targets

<Target Name="_GenerateEmbeddedFilesManifest" AfterTargets="PrepareResourceNames" DependsOnTargets="GenerateEmbeddedFilesManifest" Condition="$(EmbeddedFilesManifest) == 'true'" /> <Target Name="GenerateEmbeddedFilesManifest"> ... </Target>

so a user could wire up the second one.

natemcmaster · 2017-12-14T17:02:21Z

src/FS.Embedded.Manifest.Task/GenerateEmbeddedResourcesManifest.cs

+        public ITaskItem[] EmbeddedFiles { get; set; }
+
+        [Required]
+        public ITaskItem ManifestFile { get; set; }


Seems like the only usage of this is to acquire the TargetPath metadata item, right? Any reason this couldn't just be public string ManifestFilePath { get; set; } ?

natemcmaster · 2017-12-14T17:05:00Z

test/FS.Embedded.Manifest.Task.Test/GenerateEmbeddedResourcesManifestTest.cs

+
+namespace Microsoft.Extensions.FileProviders.Embedded.Manifest.Task
+{
+    public class GenerateEmbeddedResourcesManifestTest


👍 seems like good test coverage.

mkArtakMSFT · 2017-12-14T17:24:18Z

src/FS.Embedded.Manifest.Task/Entry.cs

+                throw new InvalidOperationException("Tried to add two different items with the same name");
+            }
+
+            Children.Add(child);


You don't have a check for a situation, where the child has already been added, I would throw in that case also, instead of silently ignoring the request

mkArtakMSFT · 2017-12-14T17:26:52Z

src/FS.Embedded.Manifest.Task/Entry.cs

+
+        private class NameComparer : IComparer<Entry>
+        {
+            public static NameComparer Instance { get; set; } = new NameComparer();


Should the "set" be "private" to avoid reassignments?

mkArtakMSFT · 2017-12-14T17:29:53Z

src/FS.Embedded.Manifest.Task/GenerateEmbeddedResourcesManifest.cs

+                ManifestFilePath = ManifestFile.GetMetadata(TargetPath)
+            };
+
+            var document = manifest.ToXmlDocument();


Please move this inside the using scope

mkArtakMSFT · 2017-12-14T17:31:13Z

src/FS.Embedded.Manifest.Task/GenerateEmbeddedResourcesManifest.cs

+                AssemblyResourceName = GetAssemblyResourceName(er)
+            }).ToArray();
+
+        string GetManifestPath(ITaskItem er) => string.Equals(er.GetMetadata(LogicalName), er.GetMetadata(ManifestResourceName)) ?


Please provide explicit visibility keywords for those methods

mkArtakMSFT · 2017-12-14T17:31:42Z

src/FS.Embedded.Manifest.Task/GenerateEmbeddedResourcesManifest.cs

+        string NormalizePath(string path) => Path.DirectorySeparatorChar == '\\' ?
+            path.Replace("/", "\\") : path.Replace("\\", "/");
+
+        public Manifest BuildManifest(EmbeddedItem[] processedItems)


validate the "processedItems" to be not null before usage

mkArtakMSFT · 2017-12-14T17:32:12Z

src/FS.Embedded.Manifest.Task/Manifest.cs

+
+        public Entry Root { get; set; } = Entry.Directory("");
+
+        public void AddElement(string originalPath, string assemblyResourceName)


Please validate arguments for all public methods

mkArtakMSFT

Please resolve.

javiercn · 2017-12-14T18:44:17Z

Addressed all feedback /cc: @natemcmaster @mkArtakMSFT

mkArtakMSFT · 2017-12-14T18:48:02Z

src/FS.Embedded.Manifest.Task/GenerateEmbeddedResourcesManifest.cs

+        private string NormalizePath(string path) => Path.DirectorySeparatorChar == '\\' ?
+            path.Replace("/", "\\") : path.Replace("\\", "/");
+
+        public Manifest BuildManifest(EmbeddedItem[] processedItems)


Minor: would be nice to have all the public methods before private ones (or private methods in the bottom)

mkArtakMSFT · 2017-12-14T18:48:53Z

src/FS.Embedded.Manifest.Task/Manifest.cs

+
+        public void AddElement(string originalPath, string assemblyResourceName)
+        {
+            var paths = originalPath.Split(Path.DirectorySeparatorChar);


You're missing argument validation here. originalPath can be null and that'll result in NullReferenceException

mkArtakMSFT

Few more pending comments

pranavkm · 2017-12-14T18:46:27Z

src/FS.Embedded.Manifest.Task/GenerateEmbeddedResourcesManifest.cs

+        }
+
+        public EmbeddedItem[] CreateEmbeddedItems(params ITaskItem[] items) =>
+            items.Select(er => new EmbeddedItem


Null check. Why is this method public? Why a params array?

pranavkm · 2017-12-14T18:52:23Z

src/FS.Embedded.Manifest.Task/GenerateEmbeddedResourcesManifest.cs

+            er.GetMetadata(TargetPath) :
+            NormalizePath(er.GetMetadata(LogicalName));
+
+        private string GetAssemblyResourceName(ITaskItem er) => string.Equals(er.GetMetadata(LogicalName), er.GetMetadata(ManifestResourceName)) ?


ITaskItem taskItem

pranavkm · 2017-12-14T18:57:03Z

...est.Task/build/netstandard2.0/Microsoft.Extensions.FileSystem.Embedded.Manifest.Task.targets

+    TaskName="Microsoft.Extensions.FileProviders.Embedded.Manifest.Task.GenerateEmbeddedResourcesManifest" />
+
+  <PropertyGroup>
+    <EmbeddedFilesManifest Condition="$(EmbeddedFilesManifest) == ''">false</EmbeddedFilesManifest>


Condition="'$(EmbeddedFilesManifest)' == ''". Use single quotes to wrap your variables in conditions

Should this start with a verb - e.g. GenerateEmbeddedFilesManifest?

pranavkm · 2017-12-14T19:07:41Z

...est.Task/build/netstandard2.0/Microsoft.Extensions.FileSystem.Embedded.Manifest.Task.targets

+      LogicalName="$(EmbeddedFilesManifestFileName)" />
+  </ItemGroup>
+
+  <Target Name="GenerateEmbeddedFilesManifest" AfterTargets="PrepareResourceNames" Condition="$(EmbeddedFilesManifest) == 'true'">


The convention is to have targets that are implementation details (private) to start with an underscore. Consider splitting this off in to two targets

<Target Name="_GenerateEmbeddedFilesManifest" AfterTargets="PrepareResourceNames" DependsOnTargets="GenerateEmbeddedFilesManifest" Condition="$(EmbeddedFilesManifest) == 'true'" /> <Target Name="GenerateEmbeddedFilesManifest"> ... </Target>

so a user could wire up the second one.

pranavkm · 2017-12-14T19:13:08Z

test/FS.Embedded.Manifest.Task.Test/FS.Embedded.Manifest.Task.Test.csproj

+<Project Sdk="Microsoft.NET.Sdk">
+
+  <PropertyGroup>
+    <TargetFramework>netcoreapp2.1</TargetFramework>    


pranavkm · 2017-12-14T19:16:45Z

...est.Task/build/netstandard2.0/Microsoft.Extensions.FileSystem.Embedded.Manifest.Task.targets

+      <__ManifestFiles Include="@(EmbeddedResource->WithMetadataValue('IsManifest', 'true'))" />
+    </ItemGroup>
+
+    <Error Condition="@(__ManifestFiles->Count()) > 1" Text="Multiple manifest files found. Only one manifest file per assembly is allowed: %(__ManifestFiles.TargetPath)" />


You want to use @(__ManifestFiles). The current approach would stop after printing the first item.

pranavkm · 2017-12-14T19:21:33Z

...est.Task/build/netstandard2.0/Microsoft.Extensions.FileSystem.Embedded.Manifest.Task.targets

+    Name="GenerateEmbeddedFilesManifest"
+    AfterTargets="PrepareResourceNames"
+    Condition="$(EmbeddedFilesManifest) == 'true'"
+    Inputs="@(EmbeddedResource)"


Unfortunately this is going to run in to dotnet/msbuild#2470. csc works around this by manually tracking file hashes - https://github.com/Microsoft/msbuild/pull/1328/files

pranavkm · 2017-12-14T19:23:57Z

src/FS.Embedded.Manifest.Task/Entry.cs

+            return string.Equals(Name, currentSegment, StringComparison.Ordinal);
+        }
+
+        public bool Equals(Entry other)


GetHashCode \ Equals(object) overrides?

pranavkm · 2017-12-14T19:24:41Z

src/FS.Embedded.Manifest.Task/Entry.cs

+
+        private bool SameChildren(ISet<Entry> left, ISet<Entry> right)
+        {
+            if (left.Count != right.Count)


Isn't there a SetEquals on set?

Equality for these sets is not based solely on the name. We check that we aren't adding two files with the same name but different metadata

Yup. But you should be able to use ``SortedSet.CreateSetComparer(EqualityComparer.Default).Equals(left, right);`

pranavkm · 2017-12-14T19:25:15Z

src/FS.Embedded.Manifest.Task/GenerateEmbeddedResourcesManifest.cs

+                AssemblyResourceName = GetAssemblyResourceName(er)
+            }).ToArray();
+
+        private string GetManifestPath(ITaskItem er) => string.Equals(er.GetMetadata(LogicalName), er.GetMetadata(ManifestResourceName)) ?


natemcmaster · 2017-12-14T19:27:52Z

...est.Task/build/netstandard2.0/Microsoft.Extensions.FileSystem.Embedded.Manifest.Task.targets

+    Name="GenerateEmbeddedFilesManifest"
+    AfterTargets="PrepareResourceNames"
+    Condition="$(EmbeddedFilesManifest) == 'true'"
+    Inputs="@(EmbeddedResource)"


This is a good start. You need a few additional things to make this work correctly. Inputs/Outputs only compares the timestamps of each file and asserts that Inputs.Max(f => f.LastModifiedTime) < Outputs.Min(f =>f .LastModifiedTime). What it doesn't do is compare if the list of Inputs and Outputs changes between runs. So if I remove an embedded resource, the assertion still checks out, and the manifest isn't re-built, but the list of embedded files is wrong.

The way we've worked around this in dotnet/sdk is to add an additional input, which generates a hash of all items and relevant metadata.

For a good example of this, checkout the assembly attribute generation targets: https://github.com/dotnet/sdk/blob/2995c8495082d1dd4bcad35c37007375edf45c6f/src/Tasks/Microsoft.NET.Build.Tasks/build/Microsoft.NET.GenerateAssemblyInfo.targets#L114

 <Target Name="CreateGeneratedAssemblyInfoInputsCacheFile" DependsOnTargets="GetAssemblyAttributes"> <PropertyGroup> <GeneratedAssemblyInfoInputsCacheFile>$(IntermediateOutputPath)$(MSBuildProjectName).AssemblyInfoInputs.cache</GeneratedAssemblyInfoInputsCacheFile> </PropertyGroup>  <Hash ItemsToHash="@(AssemblyAttribute->'%(Identity)%(_Parameter1)%(_Parameter2)%(_Parameter3)%(_Parameter4)%(_Parameter5)%(_Parameter6)%(_Parameter7)%(_Parameter8)')"> <Output TaskParameter="HashResult" PropertyName="_AssemblyAttributesHash" /> </Hash> <WriteLinesToFile Lines="$(_AssemblyAttributesHash)" File="$(GeneratedAssemblyInfoInputsCacheFile)" Overwrite="True" WriteOnlyWhenDifferent="True" /> <ItemGroup> <FileWrites Include="$(GeneratedAssemblyInfoInputsCacheFile)" /> </ItemGroup> </Target> <Target Name="CoreGenerateAssemblyInfo" Condition="'$(Language)'=='VB' or '$(Language)'=='C#'" DependsOnTargets="CreateGeneratedAssemblyInfoInputsCacheFile" Inputs="$(GeneratedAssemblyInfoInputsCacheFile)" Outputs="$(GeneratedAssemblyInfoFile)"> <ItemGroup>  <Compile Remove="$(GeneratedAssemblyInfoFile)" /> </ItemGroup> <WriteCodeFragment AssemblyAttributes="@(AssemblyAttribute)" Language="$(Language)" OutputFile="$(GeneratedAssemblyInfoFile)"> <Output TaskParameter="OutputFile" ItemName="Compile" /> <Output TaskParameter="OutputFile" ItemName="FileWrites" /> </WriteCodeFragment> </Target>

pranavkm

When @natemcmaster is happy

pranavkm · 2017-12-15T21:33:15Z

src/FS.Embedded.Manifest.Task/Entry.cs

+
+        private bool SameChildren(ISet<Entry> left, ISet<Entry> right)
+        {
+            if (left.Count != right.Count)


Yup. But you should be able to use ``SortedSet.CreateSetComparer(EqualityComparer.Default).Equals(left, right);`

pranavkm · 2017-12-15T21:34:26Z

src/FS.Embedded/build/netstandard2.0/Microsoft.Extensions.FileSystem.Embedded.targets

+  <Target Name="CreateGeneratedManifestInfoInputsCacheFile">
+    <PropertyGroup>
+      <GeneratedManifestInfoInputsCacheFile>$(IntermediateOutputPath)$(MSBuildProjectName).EmbeddedFilesManifest.cache</GeneratedManifestInfoInputsCacheFile>    
+  </PropertyGroup>    


pranavkm · 2017-12-15T21:34:34Z

src/FS.Embedded/build/netstandard2.0/Microsoft.Extensions.FileSystem.Embedded.targets

+      Condition="@(__FilesForManifest->Count()) != 0" />
+
+  </Target>
+</Project>


new line at eof

natemcmaster

We still need to cross-target the task assembly for .NET Framework.

Incremental compilation code looks good, but we should add tests to assert this works. This is a critical scenario that we shouldn't break.

natemcmaster · 2017-12-15T22:04:54Z

NuGetPackageVerifier.json

-        ]
+        ],
+        "packages": {
+            "Microsoft.Extensions.FileProviders.Embedded.Manifest.Task": {


You can remove this now.

natemcmaster · 2017-12-15T22:05:35Z

src/FS.Embedded.Manifest.Task/FS.Embedded.Manifest.Task.csproj

+<Project Sdk="Microsoft.NET.Sdk">
+
+  <PropertyGroup>
+    <RootNamespace>Microsoft.Extensions.FileProviders.Embedded.Manifest.Task</RootNamespace>


natemcmaster · 2017-12-15T22:08:58Z

src/FS.Embedded.Manifest.Task/FS.Embedded.Manifest.Task.csproj

+    <AssemblyName>Microsoft.Extensions.FileProviders.Embedded.Manifest.Task</AssemblyName>
+    <Description>MSBuild task to generate a manifest that can be used by Microsoft.Extensions.FileProviders.Embedded to preserve
+    metadata of the files embedded in the assembly at compilation time.</Description>
+    <TargetFramework>netstandard2.0</TargetFramework>


We still need to target .NET Framework. The package that uses this task would install in a project that could be as old as MSBuild 15.3. If you don't, VS users not on latest will hit TypeLoadException errors when they try to compile their app.

See dotnet/msbuild#2738

natemcmaster · 2017-12-15T22:11:57Z

src/FS.Embedded/build/netstandard2.0/Microsoft.Extensions.FileSystem.Embedded.targets

+<Project>
+
+  <UsingTask
+    AssemblyFile="Microsoft.Extensions.FileSystem.Embedded.Manifest.Task"


Needs to be a file path

natemcmaster · 2017-12-15T22:13:26Z

src/FS.Embedded/build/netstandard2.0/Microsoft.Extensions.FileSystem.Embedded.targets

+      <__ManifestFiles Include="@(EmbeddedResource->WithMetadataValue('IsManifest', 'true'))" />
+    </ItemGroup>
+
+    <Error Condition="'@(__ManifestFiles->Count())' > 1" Text="Multiple manifest files found. Only one manifest file per assembly is allowed: @(__ManifestFiles->TargetPath)" />


@(__ManifestFiles->TargetPath) is this valid MSBuild syntax? I don't recognized it.

natemcmaster · 2017-12-15T22:16:42Z

src/FS.Embedded/build/netstandard2.0/Microsoft.Extensions.FileSystem.Embedded.targets

+    <EmbeddedResource
+      Include="$(IntermediateOutputPath)$(EmbeddedFilesManifestFileName)"
+      IsManifest="true"
+      Condition="@(EmbeddedResource->WithMetadataValue('IsManifest','true')->Count()) == 0"


I'm not sure a users would ever need to write their own manifest. Seems better to always let our targets perform the manifest generation.

But if this is an important scenario, you should add a functional test that ensures this scenario works. From what I can tell, the GenerateEmbeddedResourcesManifest task would end up overwriting their file with generated code.

natemcmaster · 2017-12-15T22:33:56Z

Example automated test for asserting incremental compliation: https://github.com/dotnet/sdk/blob/73fb22a07091585380ead0bcbcdc38839a0266e8/test/Microsoft.NET.Build.Tests/GivenThatWeWantToControlGeneratedAssemblyInfo.cs#L122-L194

javiercn · 2017-12-15T23:47:53Z

I've fix a bug for adding tests for incremental compilation and I will be setting up a meeting to discuss what approach we want to take here. #309

natemcmaster · 2017-12-15T23:52:46Z

this feature's gonna be dope.

* Generates an XML manifest respecting the original structure of the file system at the time the files were embedded in the assembly. * `<GenerateEmbeddedFilesManifest>true</GenerateEmbeddedFilesManifest>` enables the feature. * Supports changing the manifest name with the EmbeddedFilesManifestFileName property. * Supports excluding specific files from the manifest using the attribute ExcludeFromManifest=true on the EmbeddedResource item. * Supports changing the path to the file using the LogicalName property on the embedded resource.

javiercn requested review from pranavkm and mkArtakMSFT December 14, 2017 16:34

javiercn force-pushed the javiercn/manifest-embeddedfileprovider branch from f3c8e22 to cd4eeba Compare December 14, 2017 16:38

natemcmaster suggested changes Dec 14, 2017

View reviewed changes

mkArtakMSFT reviewed Dec 14, 2017

View reviewed changes

mkArtakMSFT suggested changes Dec 14, 2017

View reviewed changes

mkArtakMSFT reviewed Dec 14, 2017

View reviewed changes

mkArtakMSFT suggested changes Dec 14, 2017

View reviewed changes

pranavkm reviewed Dec 14, 2017

View reviewed changes

natemcmaster reviewed Dec 14, 2017

View reviewed changes

javiercn force-pushed the javiercn/manifest-embeddedfileprovider branch 2 times, most recently from a17e058 to 192b00b Compare December 15, 2017 02:24

pranavkm approved these changes Dec 15, 2017

View reviewed changes

natemcmaster suggested changes Dec 15, 2017

View reviewed changes

natemcmaster approved these changes Dec 15, 2017

View reviewed changes

javiercn force-pushed the javiercn/manifest-embeddedfileprovider branch 2 times, most recently from 5a6cabe to a2becdf Compare December 16, 2017 03:42

mkArtakMSFT approved these changes Dec 19, 2017

View reviewed changes

javiercn force-pushed the javiercn/manifest-embeddedfileprovider branch from a2becdf to d5998f1 Compare December 19, 2017 01:17

javiercn merged commit d5998f1 into dev Dec 19, 2017


		public Entry Root { get; set; } = Entry.Directory("");

		public void AddElement(string originalPath, string assemblyResourceName)

Add a task to generate a manifest with the file system structure of the original files #308

Add a task to generate a manifest with the file system structure of the original files #308

Conversation

javiercn commented Dec 14, 2017

natemcmaster 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

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

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

mkArtakMSFT Dec 14, 2017 • edited Loading

Choose a reason for hiding this comment

mkArtakMSFT left a comment

Choose a reason for hiding this comment

javiercn commented Dec 14, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mkArtakMSFT 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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pranavkm 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

natemcmaster 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

natemcmaster commented Dec 15, 2017

javiercn commented Dec 15, 2017

natemcmaster commented Dec 15, 2017

mkArtakMSFT Dec 14, 2017 •

edited

Loading