Build problems

[InteXX]

The VSIX project won't build:

1. Error: No template files found.
2. Warning: Targets version (16.2.3074.61093) and build task version (16.6.2057.29868) do not match.

I attempted a dotnet pack, but that failed as well:

Each package is licensed to you by its owner. NuGet is not responsible for, nor does it grant any licenses to, third-party packages. Some packages may include dependencies which are governed by additional licenses. Follow the package source (feed) URL to determine any dependencies.

Package Manager Console Host Version 5.6.0.6591

Type 'get-help NuGet' to see all available NuGet commands.

PM> dotnet pack
Microsoft (R) Build Engine version 16.6.0+5ff7b0c9e for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Determining projects to restore...
  Restored D:\Dev\Projects\Testing\TemplateSamples\vsix\TemplateVsix.csproj (in 700 ms).
  1 of 2 projects are up-to-date for restore.
D:\Dev\Projects\Testing\TemplateSamples\vstemplates\MyConsoleTemplate\MyConsoleTemplate.csproj(63,3): error MSB4019: The imported project "C:\Program Files\dotnet\sdk\3.1.301\Microsoft\VisualStudio\v16.0\VSSDK\Microsoft.VsSDK.targets" was not found. Confirm that the expression in the Import declaration "C:\Program Files\dotnet\sdk\3.1.301\Microsoft\VisualStudio\v16.0\VSSDK\Microsoft.VsSDK.targets" is correct, and that the file exists on disk.
D:\Dev\Projects\Testing\TemplateSamples\vsix\TemplateVsix.csproj : error MSB4057: The target "pack" does not exist in the project.
CSC : warning CS2008: No source files specified. [D:\Dev\Projects\Testing\TemplateSamples\templatepackages\TemplatePackage\TemplatePackage.csproj]
  TemplatePackage -> D:\Dev\Projects\Testing\TemplateSamples\templatepackages\TemplatePackage\bin\Debug\netstandard1.0\TemplatePackage.dll
D:\Dev\Projects\Testing\TemplateSamples\templatepackages\TemplatePackage\TemplatePackage.csproj(25,5): error MSB4006: There is a circular dependency in the target dependency graph involving target "Pack".  D:\Dev\Projects\Testing\TemplateSamples\templatepackages\TemplatePackage\TemplatePackage.csproj
PM> 

Can you assist?

[phenning]

@InteXX The VSIX project requires the template package project to be build first. The warning should be OK, but you can update the SDK reference in the VSIX csproj to match what you have installed locally. I haven't updated the project for newer versions of Visual Studio since I created the repo. The warning shouldn't impact generation of the VSIX though.

Are you able to successfully build if you run the following?

msbuild.exe TemplateSample.sln /t:Restore;Build

[phenning]

@InteXX and apologies for not seeing this comment earlier, I must have missed the notification, as I didn't expect this repository to have much traffic.

[InteXX]

I got it to build with that, thanks. With no warning yet, and I didn't have to use the command line.

There seems to be some sort of strange caching going on, though, as I replaced MyConsoleTemplate.ico with my own icon to get one that's more easily recognizable during testing. Even after the replacement, the old version kept getting packaged into the .vsix. I had to rename the file and its reference before it would update.

Tell me... what's the significance of the TemplatePackage project? I see the generated .nupkg is making it into the .vsix, but it's not being installed anywhere—either at runtime or during an experimental instance.

[InteXX]

I didn't expect this repository to have much traffic

Well, you've been found ;-)

Ed Dore is helping me on a ticket where we're trying to build a .vsix to install a .NET Core project template in VS (I'm using 2019 Pro). This repo came to my attention through that ticket. Your sample makes some promising headway, so thank you. (I must concede that my expertise in this area is not significant.)

I was hoping that your TemplatePackage project would turn out to provide functionality similar to what we see when we add a new Azure Functions project, where we encounter a secondary dialog asking us what sort of trigger we want to use. But this doesn't seem to be the case. Maybe you could elaborate a little bit.

My end goal with all of this is to build a community contribution that mimics the behavior of the stock Azure Functions template but creates projects in VB.NET instead. You can find my first attempts here and here. As you can see I haven't included a .vsix yet, pending resolution on all of this.

Any ideas you might have toward this end will be very welcome :-)

[phenning]

I got it to build with that, thanks. With no warning yet, and I didn't have to use the command line.

There seems to be some sort of strange caching going on, though, as I replaced MyConsoleTemplate.ico with my own icon to get one that's more easily recognizable during testing. Even after the replacement, the old version kept getting packaged into the .vsix. I had to rename the file and its reference before it would update.

Tell me... what's the significance of the TemplatePackage project? I see the generated .nupkg is making it into the .vsix, but it's not being installed anywhere—either at runtime or during an experimental instance.

The template package project is the actual dotnet template engine based template. This package in addition to be being able to be included in VSIX and referenced in the vstemplate stub file, can also be installed on the command line for use in 'dotnet new' by running dotnet new --install

The nupkg should be being installed it in to the install folder for the extension, which should be in the user profile folder for the Visual Studio instance in which the vsix was installed.

[phenning]

I didn't expect this repository to have much traffic

Well, you've been found ;-)

Ed Dore is helping me on a ticket where we're trying to build a .vsix to install a .NET Core project template in VS (I'm using 2019 Pro). This repo came to my attention through that ticket. Your sample makes some promising headway, so thank you. (I must concede that my expertise in this area is not significant.)

I was hoping that your TemplatePackage project would turn out to provide functionality similar to what we see when we add a new Azure Functions project, where we encounter a secondary dialog asking us what sort of trigger we want to use. But this doesn't seem to be the case. Maybe you could elaborate a little bit.

My end goal with all of this is to build a community contribution that mimics the behavior of the stock Azure Functions template but creates projects in VB.NET instead. You can find my first attempts here and here. As you can see I haven't included a .vsix yet, pending resolution on all of this.

Any ideas you might have toward this end will be very welcome :-)

Azure Functions dialog uses an entirely different mechanism for those templates. While they are based of the same template engine as the other .NET Core templates, the method of acquisition is a bit different. For Azure Functions, the template nupkgs are discovered and installed via an SDK feed which is curated by the Azure Functions team.

What is happening when you create an Azure Function project is that a vstemplate is invoked which causes the custom UI to be displayed. This custom UI is implemented as an IWizard extension which is referenced in the vstemplate file. This flow actual creates a project template and applies the selected item template on that created projected.

Unfortunately, I don't think the right extensibility points currently exist to enable the what you are trying to achieve.

However, we are currently working to improve the Visual Studio experience in this space, and the extensibility issues are being considered. We have been primarily focused on the broader extensibility around .NET Core templates in general, and are just in the early stages of applying some of this work to Azure Functions templates. As explained though, the Azure Functions templates extensibility does need to consider the curated feed.

[InteXX]

The template package project is the actual dotnet template engine based template

OK, I'll have a look at that, thanks.

[InteXX]

Unfortunately, I don't think the right extensibility points currently exist to enable the what you are trying to achieve.

Hm, that's disappointing news.

But couldn't we build our own IWizard with a similar look-and-feel that would enable the user to select which trigger he wants?