Getting the unescaped source name inside files.

[normj]

I have an issue I'm tracking down with our AWS templates when a user is using a template from a directory with a '-' in it. aws/aws-lambda-dotnet#87

What looks like is happening is all the file and directory names that reference the sourceName get the value with '-' but the sourceName references inside file are getting an escaped value which replaces the '-' with an '_'. I assume this is done because in C# '-' is an invalid character for identifiers like namespaces and class names.

I also need access to the unescaped value for setting up things like project references. In my templates I have a source project and a test project. I reference the sourceName in the csproj for the test project to add the project reference to the source project. The path to the source project is incorrect when there is a dash because on disk the directory contains a '-' but what gets put in the test projects csproj is a '_'.

Is there any way to access the unescaped 'sourceName' when referencing the 'sourceName' in a file?

[seancpeters]

Hi @normj - I believe the resolution of issue #1168 (comment) should work for your situation too - depending on the version of the dotnet cli (or VS) you're using... there's some discussion in that issue about which versions it'll work in. If that's not sufficient, let me know.

[normj]

If I understand correctly I would have to maintain 2 different versions of the templates. One for the current 1.0.4 version as they are now and another for the next version of the CLI with different sourceNames. If I just switched to this new approach that would break everybody who is still using the current CLI.

Also is there a way in the NuGet package for the template to say which version of the CLI the templates are compatible for?

[ebekker]

Any update to this?

[mlorbetske]

Unfortunately there's not an update we can give that will get things working across the board if you still need to support the 1.0.x CLI as we haven't been able to get on any of the servicing trains with an update to the engine that would make the experience uniform.

If the 1.0.x CLI is no longer a requirement, the 1.1.x and 2.x CLIs the example here should get things working.

In the config, you'll see that the sourceName is set to Template.1 and in ReferencesRenamedFile.txt, the different ways of referring to content are listed. The top one listed is the literal value the user provided. The name Template.1 (or something similar to it) is important as all of the transformations on it are unique & can therefore have the appropriate variant determined from what's specified in the content

Transform	Input	Output
Identity	Template.1	Template.1
Namespace	Template.1	Template._1
Class Name	Template.1	Template__1
Lowercase Namespace	Template.1	template._1
Lowercase Class Name	Template.1	template__1

An aside - in Template1.csproj, I've also included the logic for conditionally including RootNamespace in the project file if it's needed in a way that's compatible with all 2.x CLIs, there's nicer syntax available in 2.1.x CLIs, but if the desire is to be compatible with as many versions as possible, this syntax works the most broadly.

As far as referring to a particular minimum version of the engine goes, here's an example of that. Unfortunately, it seems that that version number is always 1.0.0.0 at the moment. @seancpeters we'll either need to convert this over in a compatible way to be able to use GitInfo.PackageVersion (and do semantic version comparison here) or take the assembly version information from the assembly. I vote for the former as long as it doesn't impact anything depending on the 4 octet versions (like all of our existing templates do).

[donJoseLuis]

1. Adding item to specific project corresponding to a targeted delivery area
2. Once this has been done for the entire backlog, the next steps will be to prioritize within each project & output a delivery roadmap.
3. At that point, the issues will be assigned to a corresponding milestone
4. The team will then begin to deliver against the road map, contributions always welcome

[vlada-shubina]

If I understood correctly, the issue is now fixed for CLI versions starting 1.1.x.
Please feel free to reopen if there is anything yet to do for this issue.