BTW, this is a different way of asking for #45

Ping... our workaround depends on an external-to-DNX solution that leverages WindowsBase.dll. This means you can't build a valid Microsoft.Data.Sqlite package without Desktop .NET/Mono.

@davidfowl I don't think you're looking into this. Could you move to another milestone (or in 1.0.0 backlog?)

I prefer putting the destination on the left, and I'd like to see if we can get globbing in there. We'll be talking about this in the design meeting today.

W00t! We have workarounds in EntityFramework and in Microsoft.Data.Sqlite for this...

Initial design notes. We're going to iterate on it tomorrow. /cc @davidfowl

{
    "packageFiles": {
        "dest": "src"
    }
}

I think that the "source" file specifier needs to be able to be an array. Basically, if the thing on the right ends up evaluating to multiple file names, the thing on the left is a folder. Otherwise, the thing on the left is a file and must have the full name of the file. Because the body of this property is a JSON dictionary, we are restricted to only having one entry per destination.

{
    "packageFiles": {
        "test": ["a.txt", "b.txt"],
        "README.md": "docs/README.md"
    }
}

This is just about how to add files to the generated nupkg, but not about how they will be consumed, right?

@MiguelAlho That's correct.

Additional design notes:

• We want the project to be able to fully behave like a package, so any files specified in this section should be available when referencing the project. For example, if a native binary is specified using this property, that binary should be placed in the correct lock-file section.