Consider EmbeddedFileSystem becoming its own NuGet package #100
Conversation
ghost
added
the
| { | ||
| "version": "1.0.0-*", | ||
| "description": "Implementation of ASP.NET 5 physical file provider abstractions.", | ||
| "dependencies": { |
There was a problem hiding this comment.
Don't you need a dependency on Interfaces here? Common gets you one transitively, but it's only a build-time dependency. Same for Embedded.
There was a problem hiding this comment.
Right I see that. Otherwise ones consuming these packages will have to include the file system interfaces in their projects.
|
The code looks fine, though I'm not sure what is accomplished by fragmenting to this degree. |
|
This was out of the API review. My understanding is when user wants PhysicalFileSystem then we don't need to pull in Embedded one. Just a matter of organizing. |
| "description": "Implementation of ASP.NET 5 file provider abstractions.", | ||
| "dependencies": { | ||
| "Microsoft.AspNet.FileProviders.Interfaces": "1.0.0-*" | ||
| }, |
There was a problem hiding this comment.
Don't shared source projects need "shared": "*.cs", ? Or is this not shared source? The bug didn't say anything about having a package named "Microsoft.AspNet.FileProviders.Common" did it?
|
Updated @Eilon |
|
|
||
| using System.Reflection; | ||
|
|
||
| [assembly: AssemblyMetadata("Serviceable", "True")] |
There was a problem hiding this comment.
This package doesn't really produce an assembly right? If no assembly, don't need this attribute.
|
Updated. |
|
|
Fixes: #48
@Tratcher @muratg