Issue with package folder nesting

[seangwright]

First off, thanks for all the work on .NET templates. I now have a solution template for my company's internal projects and it appears to be working great. It's a real timesaver when scaffolding new projects, but the best part is that the original template code is buildable/runnable which means we can easily keep it up to date.

Issue - Package folder nesting

I was running into issues with the structure of my solution template project and found a way to solve them. I thought I'd share that here.

My solution template repo is structured like this

|-Template.csproj
|-\src
|  |-Directory.Build.props
|  |-Directory.Build.targets
|  |-PROJECT_IDENTIFIER.sln 
|  |-\.template.config
|  | ...

I can't put my Template.csproj in \src because when I would dotnet pack the template, the Directory.Build.props and Directory.Build.targets would be used. However, they are meant for the generated solution, not for building the template and fail to build correctly.

Here is my Template.csproj

<Project Sdk="Microsoft.NET.Sdk">

    <PropertyGroup>
        <PackageType>Template</PackageType>
        <VersionPrefix>1.0.0</VersionPrefix>
        <PackageId>MyTemplate</PackageId>
        <Title>$(PackageId)</Title>
        <Description>...</Description>
        <Authors>Me</Authors>
        <PackageTags>dotnet-new;templates</PackageTags>
        <TargetFramework>netstandard2.0</TargetFramework>

        <IncludeContentInPack>true</IncludeContentInPack>
        <IncludeBuildOutput>false</IncludeBuildOutput>
        <ContentTargetFolders>content</ContentTargetFolders>
        <NoDefaultExcludes>true</NoDefaultExcludes>
        <NoWarn>$(NoWarn);NU5128;NU5123;NU5110;NU5111;NU5100</NoWarn>
    </PropertyGroup>

    <ItemGroup>
        <Content Include="src\**\*.*" PackagePath="content" />
        <Content Remove="src\**\bin\**" />
        <Content Remove="src\**\obj\**" />
        <Content Remove="src\**\*.Local.config" />
        <Content Remove="src\**\node_modules\**" />
        <Content Remove="src\**\.vs\**" />
        <Compile Remove="**\*" />
    </ItemGroup>

</Project>

Without the PackagePath="content" attribute on the <Content> element, I was getting a .nupkg structure like this:

|-\content
|  |-\Content
|     |-Directory.Build.targets
|     |-PROJECT_IDENTIFIER.sln 
|     |-\.template.config
|     | ...

That extra nested \Content directory caused the template, after installation, to generate nothing when I used it at the command line.

Adding PackagePath="content" unnested the .nupkg contents and produced a solution template package that looked like the ones I've downloaded off NuGet.

|-\content
|  |-Directory.Build.targets
|  |-PROJECT_IDENTIFIER.sln 
|  |-\.template.config
|  | ...

It makes sense that the location of the .csproj used to create the template .nupkg affects the structure of the package, but I hadn't seen anyone report running into this.

Issue - Failed Local Package Updates

Also, when using a template that was installed locally from a .nupkg file, the .NET CLI wants to check for updates every time the template is used.

> dotnet new my-template --name TEST
Warning: MyTemplate is not found in NuGet feeds https://api.nuget.org/v3/index.json, C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\.

<template output>

Failed to check update for MyTemplate::1.0.0: the package is not available in configured NuGet feeds.

A locally installed template that is being tested before being published will always produce an error here, which could be confusing to a developer that is trying to resolve issues with the template. They might think these are errors caused by template misconfiguration.

Adding the --no-update-check option when invoking the template will prevent this error from appearing.

---

Are either of these worth describing in the README?

[sayedihashimi]

Hi @seangwright I'm happy that you are finding value in this new experience.

the best part is that the original template code is buildable/runnable which means we can easily keep it up to date.

This is one of the foundational ideas that the dotnet new experience was built around. I believe it's the first widely used 'template engine' to have this approach.

I think the folder structure issues that you ran into would be a great addition to the doc. If you have time to submit a PR that would be great!

Regarding the issue about 'failed local packages', that is an issue with the Template Engine that is used by dotnet. If you could open an issue for that at https://github.com/dotnet/templating that would be ideal.

Thanks!