Skip to content

Issue with package folder nesting #55

Closed
@seangwright

Description

@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?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions