Dash - in sourceName gets changed to underscore _ inside files but not in file names

[livarcocc]

From @petrroll on July 28, 2017 9:41

Steps to reproduce

1. dotnet new -i "Peachpie.Templates::*" (template's config on GitHub)
2. dotnet new peachpie-web -n tst-tst // specifies a sourceName that gets replaced
3. dotnet restore

It should be reproducible with any template, didn't have time to find any other that uses sourceName both in files and filenames, though.

Expected behavior

The original sourceName gets replaced either with tst-tst or tst_tst everywhere, i.e. both in the source files (including the .sln) and in file names (e.g. names of the .msbuildproj or folders).

Actual behavior

The original sourceName gets replaced with tst_tst inside source files (e.g. in the .sln file or the server's Program.cs) but with tst-tst in file and folder names.

The mismatch between paths expected by the .sln file (it expects the projects in tst_tst.Server and tst_tst folders while they actually are in tst-tst.Server and tst-tst folders) breaks the .sln file and thus the template's build.

Environment data

dotnet --info output:

Tested on both .NET SDK 1.0.4 on Windows and on .NET SDK 2.0 preview-2 on Ubuntu via WSL.

.NET Command Line Tools (2.0.0-preview2-006497)

Product Information:
 Version:            2.0.0-preview2-006497
 Commit SHA-1 hash:  06a2093335

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  16.04
 OS Platform: Linux
 RID:         ubuntu.16.04-x64
 Base Path:   /usr/share/dotnet/sdk/2.0.0-preview2-006497/

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.0-preview2-25407-01
  Build    : 40c565230930ead58a50719c0ec799df77bddee9

.NET Command Line Tools (1.0.4)

Product Information:
 Version:            1.0.4
 Commit SHA-1 hash:  af1e6684fd

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.15063
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\1.0.4

Copied from original issue: dotnet/cli#7307

[petrroll]

BTW: In addition to acknowledging it and fixing it in future releases I wouldn't mind an advice on how to deal with this issue on already shipped versions :).

[seancpeters]

Hi @petrroll,
There is a way to slightly modify the template source to prevent this problem:

• In template.json, change the value of sourceName from "MyWebsite1" to "MyWebsite.1".
• In Program.cs, change the namespace from "MyWebsite1.Server" to "MyWebsite._1.Server".
• Change all other occurrences of "MyWebsite1" to "MyWebsite.1", both in the file names and the file contents. (I believe the only file content changes are in MyWebste1.sln and MyWebsite1.Server.csproj)

With those changes, your template should work as expected - and should also work for other versions of dotnet new.

USing the -n tst-tst input, all occurrences of "MyWebsite.1" will be replaced with "tst-tst", and the namespace in Program.cs will be replaced with "tst_tst".

Please let me know if this solution works for you - if not, let me know the problem, and we'll figure it out :)

Partial explanation of what's happening behind the scenes:

The reason this is necessary is because when the template engine creates an instance of a template, it makes variants on the input name that are meant to be safe to use in particular circumstances. For example it makes a variant that is a valid namespace, and another variant which is a valid class name. But the template engine doesn't try to determine the semantic meaning of various symbols, so it doesn't explicitly know when to use the namespace version. This is why we had to make the slightly different change in Program.cs.

The transformations used to make the variants are applied to both the sourceName value, and the user provided input value, and maps the results of the transformed sourceName to the transformed input name. The original values are also included in the mapping. In this case, with original values:

• sourceName = MyWebsite.1
• (input) name: tst-tst

The transformation for namespace results in:

• sourceName (variant) = MyWebsite._1
• name (variant) = tst_tst

And the transformation that could be used for class name (if you wanted that type of replacement) is:

• sourceName (variant) = MyWebsite__1
• name (variant) = tst_tst

These variants (and the original) are used to setup replacements from the template source to the output of:

• MyWebsite.1 -> tst-tst
• MyWebsite._1 -> tst_tst
• MyWebsite__1 -> tst_tst
  So anywhere in the template file contents where the value on the left appears, it gets replaced with the corresponding value on the right.

For the file names, we only replace the original sourceName value with the original user provided name value. We're in the early stages of planning for more control of filename replacements, but don't have anything concrete yet.

[petrroll]

Ah, I see. Thanks! BTW: Did I miss anything (which is actually quite probable) or is not documented anywhere?

[petrroll]

I've tried that but it does not seem to fix the problem. What happens with CLI 1.0.4 is following:

• MyWebsite.1 -> tst_tst
• MyWebsite._1 does not change at all...

Repro:

1. Clone following branch https://github.com/peachpiecompiler/peachpie-templates/tree/template-name-test
2. Run myget.ps1 to initiate tests
3. Tests will crash, observe tmp/tst-tst/.../tst-tst.sln (contains tst_tst references) and \tst-tst\tst-tst.Server\Program.cs (contains MyWebsite._1).

PS: Yes, the tests script creates a nested hierarchy of tst-tst folders. I know about that, but I didn't have the time to fix just for repro repo (it's not a problem on the main branch).

[seancpeters]

My apologies, this functionality is not available in 1.0.4, but will be available in the 1.1.0 release - but we don't yet have a release date for 1.1.0. There is unfortunately no analogous functionality in 1.0.4 to deal with this type of situation.

From your comments, I wasn't 100% if this worked for you with a 2.0.0 CLI - if it doesn't please let me know - from what I could tell, it was working on my local copy.

Regarding you having missed anything in our documentation, I'd say no. This functionality is relatively new, and needs better documentation. The functionality is also getting enhanced, PR #867 allows for more author control over the transformations on the input values, and the corresponding values needed in the template source. This is not yet available in any production release, I mention it in case you want to play with it in advance.

[petrroll]

Frankly, I didn't try the updated version in 2.0.0 as supporting only 2.0.0 isn't really relevant for us ATM. Regarding version 1.1.0 will that be an (semi) automatic update for those who will stay on 1.x.x or how does it fit in the .NET Core versioning scheme?

The reason I'm asking is to know what templating-feature-level is reasonable for us to support in our templates. We definitely do not want to exclude users on 1.x.x and maintaining two versions of templates isn't really a good option for us ATM either. On the other hand I would not like to be stuck on 1.0.4 feature-set if it's not necessary.

For now we just removed sourceName from referenced filenames and it works fine. The end result is just not as nice which is a bit of a shame...

// A bit of an unrelated rant follows //

PS: I know you're doing the best you can but I had a really rough time preparing a 1.x.x template and hit multiple bugs / lacking or downright wrong documentation in the process (for most of which I filed issues here on github).

I'd greatly appreciate if the next time you publish a product that might not yet be ready for a prime time (which I honestly believe is the case for 1.x.x templating) the fact was clearly stated trough, for example, marking it beta.

I'm really looking forward to templating 2.x.x and I believe it will be an awesome product but I can't help myself but be a bit put off by the experience I had. An experience I would tolerate much better had I had a chance to anticipate it by knowing the product isn't yet out of, e.g, beta.

PPS: I know development is hard so please do not take an offense. I definitely don't mean to criticize for the sake of criticizing or hurting.

[mlorbetske]

Hi @petrroll,

1.1.0 will be the version of the dotnet CLI that is carried by Visual Studio 2017.3 and will be available for download as usual on the dot.net site. Unfortunately, apart from the Visual Studio update path, this isn't an automatic acquisition. 2.0 will also become generally available at that time, but will remain a separate download for the time being.

Also, thanks for working through this with us. The experience with the templating bits in the 1.0.x CLI fell short of where we wanted to be and we're working to address the issues as best and as fast as we can. Unfortunately, though, the 2.x CLI is likely to be the vehicle for most of the updates/fixes as it ships the most often. We've also tried to expand our documentation efforts (though it doesn't show much on the wiki itself at the moment) - @sayedihashimi has written a nice blog post and created the samples repo to try to make some of the information more comprehensible. There's also a writeup in progress from our docs team for how to author templates which I believe should help as well.

[petrroll]

I see. Thank you for your effort here and good luck with shipping the version you can all be proud of :).

Regarding this issue, it can be closed now from my pow.

[cwensley]

For others looking at this issue, I've had success using the following symbol to support both the new and old sdk with a single template:

		"namespace-for-old-sdk": {
			"type": "generated",
			"generator": "coalesce",
			"parameters": {
				"sourceVariableName": "safe_namespace",
				"fallbackVariableName": "safe_name"
			},
			"replaces": "MyName._1"
		}

This doesn't mean you can use '.' or '-' in the name with the old sdk, but they will work with the new sdk.

Hope this helps someone!