We Keep Coding

Nuget PackageReference found in one solution, but not in my own solution

Previous title:
The "GenerateFileFromTemplate" task was not found
.NET project template - GeneratedContent
.csproj.in file transformations
The troubled package is Microsoft.DotNet.Build.Tasks.Templating.
I've created a git-repository containing multiple .NET project templates. When opened in Visual Studio, VS had a horrible performance when adding more files to the template project. This turned out to be caused by my template's project files having .csproj extension. Therefor I've changed the extensions of all my template csproj files to csproj.in.
Because of this, I need to add a msbuild task that transforms this .csproj.in to .csproj. There are several examples out on the internet:
ASP.NET Core project templates
spa-templates (Seems to use the Arcade SDK)
dotnet-template-samples (very basic)
microsoft/SEAL
In the above samples, there is no nuget.config in the project.
Your root csproj file contains a <GeneratedContentProperties> and <GeneratedContent> section:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<GeneratedContentProperties>
DefaultNetCoreTargetFramework=$(DefaultNetCoreTargetFramework);
</GeneratedContentProperties>
</PropertyGroup>
<ItemGroup>
<GeneratedContent Include="Angular-CSharp.csproj.in" OutputPath="content/Angular-CSharp/Company.WebApplication1.csproj" />
<GeneratedContent Include="React-CSharp.csproj.in" OutputPath="content/React-CSharp/Company.WebApplication1.csproj" />
</ItemGroup>
</Project>
The .csproj.in files reference the GeneratedContentProperties:
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>${DefaultNetCoreTargetFramework}</TargetFramework>
...
</PropertyGroup>
...
</Project>
I've tried applying the same files to my project in this commit, but I'm still getting the following error when building the project:
dotnet build --configuration Release
MSBuild version 17.3.0+92e077650 for .NET
Determining projects to restore...
C:\Program Files\dotnet\sdk\6.0.400\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.DefaultItems.Shared.targets(152,5): warning NETSDK1023: A PackageReference for 'Microsoft.DotNet.Build.Tasks.Templating' was included in your project. This package is implicitly referenced by the .NET SDK and you do not typically need to reference it from your project. For more information, see https://aka.ms/sdkimplicitrefs [C:\repos\MintPlayer.AspNetCore.Templates\MintPlayer.AspNetCore.
IdentityServer.Templates\MintPlayer.AspNetCore.IdentityServer.Templates.csproj]
...
All projects are up-to-date for restore.
...
C:\repos\MintPlayer.AspNetCore.Templates\eng\GenerateContent.targets(27,3): error MSB4036: The "GenerateFileFromTemplate" task was not found. Check the following:
1.) The name of the task in the project file is the same as the name of the task class.
2.) The task class is "public" and implements the Microsoft.Build.Framework.ITask interface.
3.) The task is correctly declared with <UsingTask> in the project file, or in the *.tasks files located in the "C:\Program Files\dotnet\sdk\6.0.400" directory
[C:\repos\MintPlayer.AspNetCore.Templates\MintPlayer.AspNetCore.IdentityServer.Templates\MintPlayer.AspNetCore.IdentityServer.Templates.csproj]
Build FAILED.
It seems that dotnet cannot find the GenerateFileFromTemplate Task...
I also see that the spa-templates project is using the Arcade SDK, but I don't think I'd actually need that...
How can I fix this? What am I still missing here?
EDIT
When I open both projects in Visual Studio, this is what I see:
Nuget packages for my template project:
C:\repos\MintPlayer.AspNetCore.Templates\MintPlayer.AspNetCore.IdentityServer.Templates> dotnet restore
Determining projects to restore...C:\repos\MintPlayer.AspNetCore.Templates\MintPlayer.AspNetCore.IdentityServer.Templates\MintPlayer.AspNetCore.IdentityServer.Templates.csproj : warning NU1604: Project dependency Microsoft.DotNet.Build.Tasks.Templating does not contain an inclusive lower bound.
Include a lower bound in the dependency version to ensure consistent restore results.
C:\repos\MintPlayer.AspNetCore.Templates\MintPlayer.AspNetCore.IdentityServer.Templates\MintPlayer.AspNetCore.IdentityServer.Templates.csproj : error NU1101: Unable to find package Microsoft.DotNet.Build.Tasks.Templating. No packages exist with this id in source(s): C:\Program Files\dotnet\library-packs, Local, Microsoft Visual Studio Offline Packages, nuget.org
Failed to restore C:\repos\MintPlayer.AspNetCore.Templates\MintPlayer.AspNetCore.IdentityServer.Templates\MintPlayer.AspNetCore.IdentityServer.Templates.csproj (in 516 ms).
Nuget packages for spa-templates:
C:\repos\spa-templates\src> dotnet restore
Determining projects to restore...
C:\repos\spa-templates\src\Microsoft.DotNet.Web.Spa.ProjectTemplates.csproj : warning NU1603: Microsoft.DotNet.Web.Spa.ProjectTemplates.7.0 depends on Microsoft.DotNet.Build.Tasks.Templating (>= 6.0.0-beta.21373.11) but Microsoft.DotNet.Build.Tasks.Templating 6.0.0-beta.21373.11 was not found. An approximate best match of Microsoft.DotNet.Build.Tasks.Templating 6.0.0-beta.22212.5 was resolved.
All projects are up-to-date for restore.
So it seems that dotnet restore is unable to restore this package. However, the nuget sources are the same for both projects:
IdentityServer.Templates>dotnet nuget list source
Registered Sources:
1. nuget.org [Enabled]
https://api.nuget.org/v3/index.json
2. Local [Enabled]
C:\packages
3. Microsoft Visual Studio Offline Packages [Enabled]
C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\
C:\repos\spa-templates>dotnet nuget list source
Registered Sources:
1. nuget.org [Enabled]
https://api.nuget.org/v3/index.json
2. Local [Enabled]
C:\packages
3. Microsoft Visual Studio Offline Packages [Enabled]
C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\
EDIT 2
Hmm, it seems that GenerateFileFromTemplate is part of the Arcade SDK... (Howto)

How to install Microsoft.DotNet.Arcade.Sdk into the dotnet sdk folder?
It seems that the package is only available through the following NuGet feed:
https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-eng/nuget/v3/index.json
So I added a nuget.config in the root of the project/repository:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="dotnet-eng" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-eng/nuget/v3/index.json" />
</packageSources>
</configuration>
And since there's only preview versions of the package, you need for example the following version (eng/Versions.props):
<Project>
...
<PropertyGroup Label="Package versions">
<MicrosoftDotNetBuildTasksTemplatingVersion>6.0.0-beta.21373.11</MicrosoftDotNetBuildTasksTemplatingVersion>
...
</PropertyGroup>
</Project>

error CS8773: "Feature 'global using directive' is not available in C# 9.0" after downgrade from net6.0 to net5.0

I have a project that was initially created for .NET 6 but then I needed to downgrade it to .NET 5.
I changed Target framework in Project Properties and tried to compile. As a result I received a bunch of the errors:
GlobalUsings.g.cs(2,1,2,29): error CS8773: Feature 'global using directive' is not available in C# 9.0. Please use language version 10.0 or greater.
File GlobalUsings.g.cs is created automatically and it reappears every time after compilation.

Finally I found that the reason is an extra property ImplicitUsings in the project file that is not supported by .net 5.0.
<PropertyGroup>
<TargetFramework>net5.0</TargetFramework>
<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>
</PropertyGroup>
I needed to remove ImplicitUsings from the file.

remove <ImplicitUsings>enable</ImplicitUsings> in the csproj project file, then can build success
find this solution from here

Remove the tag indeed work.
But just change the value of it did the trick as well!
<ImplicitUsings>disable</ImplicitUsings>

To get rid of this error which is caused by downgrading below net6.0.
Remove the following items from the .csproj file:
<ImplicitUsings>
<Using Include="..." />

If you don't want to remove the ImplicitUsings or made changes to the project file. You can tell the build cli to disable it during build process by
dotnet build --configuration "Release" --framework "net5.0" /p:ImplicitUsings=false /p:PublishReadyToRun=false

C#/.NET - How to generate and increase package version automatically especially via CI?

I have a Visual Studio project which is built as a NuGet lib package. But every time I publish the package, I have to change the version number manually. That's a prone-to-error work.
I'd like to generate and increase the package version number automatically.
I found GitVersion tool to solve this problem. And I also found some semantic versioning blogs to explain the package version of continuous delivery.
GitTools/GitVersion: Easy Semantic Versioning (http://semver.org) for projects using Git
GitVersion Documentation
Versioning NuGet packages in a continuous delivery world: part 1 – Microsoft DevOps Blog
Versioning NuGet packages in a continuous delivery world: part 2 – Microsoft DevOps Blog
Versioning NuGet packages in a continuous delivery world: part 3 – Microsoft DevOps Blog
But unfortunately, The GitVersion package does not work correctly for me.
It gives me an error that AssemblyVersionAttribute is duplicated.
If I add <GenerateAssemblyInfo>false</GenerateAssemblyInfo> into the csproj file, It will do nothing and the package version will be 0.0.0.0.
Maybe the reason is that I'm using the new csproj format. See here to view the csproj file and the file looks like this:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFrameworks>net45;net47;netstandard2.0</TargetFrameworks>
</PropertyGroup>
</Project>
Any reply is appreciated.
UPDATE:
I find that there is an issue to mention my problem: Gitversion Task for VS2017-style csproj · Issue #1349 · GitTools/GitVersion. I'm trying the new solution.

Not sure about Jenkins, but it should be able to generate an incremental number or timestamp by itself that can be accessed via an environment variable on your build pipeline.
I think the most flexible way is to add a PackageVersion tag with a placeholder to your csproj that your build pipeline can then change:
<PropertyGroup>
<GeneratePackageOnBuild>True</GeneratePackageOnBuild>
<PackageVersion>$(PackageVersion)</PackageVersion>
</PropertyGroup>
So, on your build pipeline, you just pass the version, for example:
dotnet build -p:PackageVersion=$(BUILD_TIMESTAMP)

We can trigger the GitHub Action by Git tag pushed and we can read the Git tag name as the version. And then we can generate the NuGet package with this version.
There is a dotnet tool that can read Git tags as a version and write it to the version file.
Before using it, we should create the version file and import the version file.
We should use dotnet to install the dotnetCampus.TagToVersion tool and use the tool to write the Git tag to version file.
The step 1:
Adding the Directory.Build.props file to repo folder.
Writing the code to the Directory.Build.props file.
<Project>
<Import Project="build\Version.props" />
</Project>
The step 2:
Making a folder named build and adding the Version.props file to this folder.
Writing the code to the build\Version.props file.
<Project>
<PropertyGroup>
<Version>1.0.5</Version>
</PropertyGroup>
</Project>
The step 3:
Writing a GitHub Action configuration file in .github\workflows folder, for example create the .github\workflows\push tag and pack nuget.yml file
Making the Action trigger by tag push.
on:
push:
tags:
- '*'
Writing the tag as version by dotnet tool.
- name: Install dotnet tool
run: dotnet tool install -g dotnetCampus.TagToVersion
- name: Set tag to version
run: dotnet TagToVersion -t ${{ github.ref }}
Building the package
# Build and publish
- name: Build with dotnet
run: dotnet build --configuration Release
- name: Install Nuget
uses: nuget/setup-nuget#v1
with:
nuget-version: '5.x'
- name: Add private GitHub registry to NuGet
run: |
nuget sources add -name github -Source https://nuget.pkg.github.com/ORGANIZATION_NAME/index.json -Username ORGANIZATION_NAME -Password ${{ secrets.GITHUB_TOKEN }}
- name: Push generated package to GitHub registry
run: |
nuget push .\bin\release\*.nupkg -Source github -SkipDuplicate
nuget push .\bin\release\*.nupkg -Source https://api.nuget.org/v3/index.json -SkipDuplicate -ApiKey ${{ secrets.NugetKey }} -NoSymbols
See https://github.com/dotnet-campus/dotnetCampus.TagToVersion

Actually GitVersionTask is not hard to use. All that you should do is these things below:
Install GitVersionTask from NuGet.
Add a configuration file named GitVersion.yml with some key-values.
Add a tag to your branch.
Build.
After doing that, you can find your output dll file contains a semantic version.
I'm answering my own question because I just wrote the wrong config file name. So it did not work correctly.
This is my configuration file:
mode: ContinuousDelivery
increment: Inherit
tag-prefix: '[vV]'
source-branches: ['master', 'develop', 'hotfix']
branches:
master:
regex: master$
mode: ContinuousDelivery
tag: ''
increment: Patch
prevent-increment-of-merged-branch-version: true
track-merge-target: false
tracks-release-branches: false
is-release-branch: true
release:
regex: r(elease$|(eleases)?[-/])
mode: ContinuousDelivery
tag: beta
increment: Patch
prevent-increment-of-merged-branch-version: true
track-merge-target: false
tracks-release-branches: false
is-release-branch: true
feature:
regex: f(eatures)?[-/]
mode: ContinuousDeployment
tag: alpha
increment: Minor
prevent-increment-of-merged-branch-version: false
track-merge-target: false
tracks-release-branches: false
is-release-branch: false
I've posted this configuration file content here: Automatically increase the semantic version using GitVersion - walterlv

How to publish for all target frameworks

I am building a set of build template in TeamCity for .Net Core projects. Everything is working great, except for console projects. The problem is that when I go to publish the solution, I need to specify the framework version. At no other point in the build do I need to know the framework. At least this is true when publishing .sln files, with a console project that only has a single framework targeted.
So now I am in a situation where I need to figure out what framework the console project should target. I could read various XML files, but I'm hoping I don't need to. Is there some builtin way that I can query for the frameworks in use for a given solution?
For example, something like (PowerShell)
$frameworks = & dotnet.exe --<what I want> .\MySolution.sln
for ($framework in $frameworks) {
& dotnet.exe publish -f $framework .\MySolution.sln
}
That way I don't need to modify the build system every time a new framework is in use. I've poked around in the CLI repo, but I can't find a command that does what I need. Is opening .csproj files my only hope?

If you want to publish projects that target multiple frameworks, the default Publish target fails, but you can create a custom target that performs the multi-targeting itself. To do this, create a file named Directory.Build.props in the solution folder (with MSBuild > 15.1 this can and should be named Directory.Build.targets because there was a bug with multi-targeting projects):
<Project>
<Target Name="PublishProjectIfFrameworkSet"
DependsOnTargets="Publish"
Condition=" '$(TargetFramework)' != '' " />
<Target Name="PublishProjectForAllFrameworksIfFrameworkUnset" Condition=" '$(TargetFramework)' == '' ">
<ItemGroup>
<_PublishFramework Include="$(TargetFrameworks)" />
</ItemGroup>
<MSBuild Projects="$(MSBuildProjectFile)" Targets="Publish" Properties="TargetFramework=%(_PublishFramework.Identity)" />
</Target>
<Target Name="PublishAll"
DependsOnTargets="PublishProjectIfFrameworkSet;PublishProjectForAllFrameworksIfFrameworkUnset" />
</Project>
Then you can publish the projects for all defined frameworks by executing this in the solution directory:
$ dotnet msbuild /t:PublishAll /p:Configuration=Release
Microsoft (R) Build Engine version 15.1.1012.6693
Copyright (C) Microsoft Corporation. All rights reserved.
app2 -> /Users/martin/testproj/app2/bin/Release/netcoreapp1.1/app2.dll
app1 -> /Users/martin/testproj/app1/bin/Release/netcoreapp1.1/app1.dll
app1 -> /Users/martin/testproj/app1/bin/Release/netcoreapp1.0/app1.dll

ItemGroup Item scope, alternatively "Why does MSBuild hate me?"

I have a solution I'm trying to get to build on TFS. I want to update the versions of all appropriate files, and I've been stuck trying to get this done. There are plenty of links on how to do it, but none of them work for me, due to one little issue... Scope.
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="DesktopBuild" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5">
<Target Name="DesktopBuild">
<CallTarget Targets="GetFiles" />
<Message Text="CSFiles: '#(CSFiles)'" />
</Target>
<Target Name="GetFiles">
<ItemGroup>
<CSFiles Include="**\AssemblyInfo.cs" />
</ItemGroup>
<Message Text="CSFiles: '#(CSFiles)'" />
</Target>
</Project>
My tree looks like this:
test.proj
application.sln
application (Folder)
main.cs
Properties (Folder)
AssemblyInfo.cs
When I run "c:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe test.proj" from the solution folder... I get the following output:
Microsoft (R) Build Engine Version 3.5.30729.1
[Microsoft .NET Framework, Version 2.0.50727.3074]
Copyright (C) Microsoft Corporation 2007. All rights reserved.
Build started 7/6/2009 3:54:10 PM.
Project "D:\src\test.proj" on node 0 (default targets).
CSFiles: 'application\Properties\AssemblyInfo.cs'
DesktopBuild:
CSFiles: ''
Done Building Project "D:\src\test.proj" (default targets).
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:00.04
So, how can I make my ItemGroup have global scope? All the Targets files used by the compiler and TeamBuild do this same thing, and theirs all seem to be global... I don't understand why this isn't working for me.
Any help?

Have you tried using DependsOnTarget rather than CallTarget? It could be that CallTarget is causing the scope issue.

The previous commenter was correct, you should change this to use DependsOnTargets instead of using the CallTarget task. What you are seeing is a bug not a scoping inssue. The way to avoid this bug is to use DependsOnTargets (which is a much better approach anywayz).
Sayed Ibrahim Hashimi
My Book: Inside the Microsoft Build Engine : Using MSBuild and Team Foundation Build

As said, you should use DependsOnTargets. I've done some research on MSBuild scope, you can find my results on my blog : http://blog.qetza.net/2009/10/23/scope-of-properties-and-item-in-an-msbuild-script/
The thing is there seems to be a global scope for the project and a local scope for the target . When entering the target, the global scope is copied and when exiting the target, the local scope is merged back. So a CallTarget will not get the modified local scope values but the DependsOnTargets will since the first target is exited before the entering the second target.

We do something similar in our build. We pass the version as a command line parameter.
In our TFSBuild.proj we set the version to 0.0.0.0 if no version was supplied:
<!--Our assembly version. Pass it in from the command prompt like this: /property:Version=1.0.0.0-->
<PropertyGroup>
<Version>0.0.0.0</Version>
</PropertyGroup>
<PropertyGroup>
<!--Used to ensure there is a newline before our text to not break the .cs files if there is no newline at the end of the file.-->
<newLine>%0D%0A</newLine>
Then we do this:
<Target Name="BeforeCompile">
<!--Update our assembly version. Pass it in from the command prompt like this: /property:Version=1.0.0.0-->
<!--attrib needs to be run first to remove the read only attribute since files from tfs are read only by default.-->
<Exec Command='attrib -R $(SolutionRoot)\Source\Project\GlobalAssemblyInfo.cs' />
<WriteLinesToFile File="$(SolutionRoot)\Source\Project\GlobalAssemblyInfo.cs"
Lines='$(newLine)[assembly: AssemblyVersion("$(Version)")]'/>
</Target>