NetStandard library with package.config errors on multiple files in same folder

[adrianm64]

Details about Problem I need to use a nuget package with editable content in a netstandard library. (in this case T4 templates but that is not the issue)

I added the line <RestoreProjectStyle>Packages.config</RestoreProjectStyle> to the csprojfile.

Adding the package works fine as long as there is only one file in each folder. With more than one file I get an error "folder already exists".

NuGet product used (NuGet.exe | VS UI | Package Manager Console | dotnet.exe): VS UI

VS version (if appropriate): 15.6.2

OS version (i.e. win10 v1607 (14393.321)): Win10 Pro 1709 (16299.371)

Worked before? If so, with which NuGet version: Works with non-standard projects

Detailed repro steps so we can see the same problem

1. Open the attached project StdLibrary.zip in VS2017

2. Add the attached nuget package stdcontentbug.1.0.0.zip

   Error message is: <project path>\Folder already exists

(a strange workaround is to just install the same package several times and answer no in the replace file dialog. It seems like each install adds one file but failes on the second)

[nkolev92]

That's an unsupported scenario.

https://github.com/dotnet/announcements/issues/31

The correct approach is to build your package with contentFiles and not content.

[adrianm64]

ok, I understand. Thanks.

ContentFiles, as its name implies, only support content. Code generating tools, installation scripts, target environment configuration files and any kind of templating is not supported.

Luckily we are not really in a hurry to support core/standard but we are currently looking into moving our assets to npm instead. It would be really sad since nuget has worked so well for us.

Hypotheticly, would you accept a PR fixing the "folder already exists" problem?

Ultimate solution for us would be contentFiles supporting a buildAction of "Template" which would place the files in the project folder like packages.config works today.

[nkolev92]

@adrianm64

You can use the build targets for code generating tools, config files, templating etc. xdt transforms are supported, pp transforms are supported.

The only thing that's not supported is plain installation scripts.

But you can already achieve all your scenarios with contentFiles.

Dumping files in the project folder's root directory is a bad approach. It pollutes the user's directory, ties package upgrades/downloads/additions/deletion to Visual Studio. Not to mention it introduced a lot of performance problems that NuGet could not control because it was running user written scripts.

With contentFiles, it just works. Those extra files are brought in for you during build as the author requests them to.

Those files are already readable from the IDE in the case of core projects as well. They can also be copied to output, structure preserved, or flattened.

[adrianm64]

Thank you for your reply.

I would also like to work in an enviroment where code generation does not require project specific configuration. Our nuget packages consists of a code generating tool (T4, powershell, batchfile etc) and a various mutable configuration/data files for the tool. What you call "dumping files in the project folder" I call "having tool configuration in source control". (The tools themselves can use contentFiles but referring to them in pre-build etc is fragile)

Don't understand the performance issue. I'm not asking nuget to run the code generation. They are either run as pre-build commands or on user action "run custom tool". (if anything it should be faster since nuget does not need to copy the files already in the source tree). Also don't understand how copying a file to the project folder can be tied to Visual Studio.

In the dark ages before nuget we manually copied the files between projects which of course became a versioning mess. With NuGet everything just works but I understand you can't support every environment and everything must come to an end.

As I said we are not in a hurry to support core/standard. For the few projects we had so far we are back to copying the files manually but it is of course not a long term solution. Hopefully we can find another distribution model for our tools.

Once again, thank you for your answers.

[nkolev92]

I would also like to work in an enviroment where code generation does not require project specific configuration.

Please refer to aka.ms/globaltools for information on having tools that do prebuild actions and are not tied to a project.

Don't understand the performance issue. I'm not asking nuget to run the code generation. They are either run as pre-build commands or on user action "run custom tool". (if anything it should be faster since nuget does not need to copy the files already in the source tree). Also don't understand how copying a file to the project folder can be tied to Visual Studio.

The performance issue is due to the fact that we can't control how efficient the queries that people write in those scripts are. They run sequentially and potentially try to access VS. Doing anything in a install.ps1 scripts ties to Visual Studio because those scripts are only ever going to executed in Visual Studio.

In the dark ages before nuget we manually copied the files between projects which of course became a versioning mess. With NuGet everything just works but I understand you can't support every environment and everything must come to an end.

A NuGet package copying things inside the project folder (to be versioned by SC), is a versioning mess, as well though.
Uninstalling the package requires NuGet to remove those files. And that can only be properly done in VS. And even then, it's error prone, as any user action on those files will complicate things. Having install that do something, means having uninstall scripts that do the opposite. Allowing that control to the user leads to a lot of bugs where certain packages don't clean up after themselves properly. Additionally, it's duplication, since those files are in packages already, there's no point in having them in both the packages and the project folder.

Happy to address any further concerns.