We Keep Coding

How to create resource sattelite assemblies for localization from resx and restext files in .NET Core desktop app using MSBuild

I am using a Linux development system and the Rider IDE to develop a cross-platform desktop application with AvaloniaUI. I am trying to follow the following Microsoft Documentation regarding the creation of resource-files for localization: https://learn.microsoft.com/en-us/dotnet/core/extensions/resources
Given the resources I want to capture and localize are all strings, I have opted to extract constant string definitions from my view models into dedicated .restext files.
Then, I updated the .csproj project file as follows:
<Project Sdk="Microsoft.NET.Sdk" InitialTargets="GenerateAsembliesFromResourceBinaries">
...
<ItemGroup>
<StringResource Include="**/*.restext" />
</ItemGroup>
<Target Name="GenerateResourceBinaries">
<!-- resgen.exe resources.fr.txt -->
<GenerateResource Sources="#(StringResource)" OutputResources="#(StringResource->'$(IntermediateOutputPath)%(Filename).resources')">
<Output TaskParameter="OutputResources" ItemName="ResourceBinary" />
</GenerateResource>
</Target>
<Target Name="GenerateAsembliesFromResourceBinaries" DependsOnTargets="GenerateResourceBinaries">
<!-- al /t:lib /embed:resources.fr.resources /culture:fr /out:fr\Example1.resources.dll -->
<AL TargetType="library"
EmbedResources="#(ResourceBinary)"
Culture="%(ResourceBinary.Culture)"
OutputAssembly="%(ResourceBinary.Culture)\$(TargetName).resources.dll">
<Output TaskParameter="OutputAssembly"
ItemName="SatelliteAssemblies"/>
</AL>
</Target>
For reference:
GenerateResource Task corresponds to ResGen.exe: https://learn.microsoft.com/en-us/visualstudio/msbuild/generateresource-task?view=vs-2022
AL Task corresponds to AL.exe: https://learn.microsoft.com/en-us/visualstudio/msbuild/al-assembly-linker-task?view=vs-2022
However, building the project now results in the following error:
MyApp.csproj(135, 9): ResGen.exe not supported on .NET Core MSBuild
I cannot find anything in the linked .NET resources documentation which suggests the process does not work for .NET Core, nor any alternative approach for creating resource sattelite-assemblies using .NET Core MSBuild.
What is the proper way to accomplish this without using ResGen.exe and AL.exe?
Edit: this may be a duplicate of How to generate resources files on linux using dotnet

dotnet core 3.1 standalone app fails with "No such file or directory", Am I missing a dependency?

I'm just trying to get dotnet core running on an NVidia Jetson Nano.
I've created a simple "hello world" app in dotnet core and packaged it as a stand-alone app targeting linux-arm.
When I put it on my Synology NAS, I can navigate to the publish directly and type ./HelloDotNetCore and the app runs, albeit with a few errors.
/HelloDotNetCore/HelloDotNetCore/bin/Release/netcoreapp3.1/linux-arm$ ./HelloDotNetCore
./HelloDotNetCore: /lib/libstdc++.so.6: no version information available (required by ./HelloDotNetCore)
./HelloDotNetCore: /lib/libstdc++.so.6: no version information available (required by ./HelloDotNetCore)
./HelloDotNetCore: /lib/libstdc++.so.6: no version information available (required by ./HelloDotNetCore)
./HelloDotNetCore: /lib/libstdc++.so.6: no version information available (required by ./HelloDotNetCore)
./HelloDotNetCore: /lib/libstdc++.so.6: no version information available (required by ./HelloDotNetCore)
Hello World!
I can run it on my Raspberry Pi, as sudo
/HelloDotNetCore/HelloDotNetCore/bin/Release/netcoreapp3.1/linux-arm $ sudo ./HelloDotNetCore
Hello World!
I've "installed" dotnet core by following the tutorial here:
https://blog.headforcloud.com/2019/04/03/jetson-nano-a-quick-start-with-.net-core-3/
(it's not actually an install, just exposing the binary to bash)
/code/HelloDotNetCore/HelloDotNetCore$ dotnet run
Hello World!
However, attempting to run this as a stand-alone app on my NVidia Jetson results in "No such file or directory". I've tried the old obvious chmod +x and chmod 777 tricks along with running as sudo, but there's no other clue as to what it's looking for that isn't there.
/code/HelloDotNetCore/HelloDotNetCore/bin/Release/netcoreapp3.1/linux-arm$ ./HelloDotNetCore
-bash: ./HelloDotNetCore: No such file or directory
So it seems that something that should be packaged with this stand-alone app isn't there, but I'm lost as for how to figure out what it needs. Any ideas?

I found the culprit. The runtime for the NVidia Jetson needs to be explicitly set to linux-arm64, and not linux-arm. If you run the application from a Jetson using the dotnet command
dotnet run
it will compile the application into the associated debug or release folder and then you can run it from that folder using
./HelloDotNetCore
However, in order to "publish" the app from visual studio, I had to update my Microsoft.NETCore.Platforms package via NuGet from here
https://www.nuget.org/packages/Microsoft.NETCore.Platforms/
This automatically updated my .csproj file to
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp3.1</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.NETCore.Platforms" Version="3.1.3" />
</ItemGroup>
</Project>
Then manually alter the RuntimeIdentifier element of the .pubxml file to reflect the linux-arm64 architecture.
<?xml version="1.0" encoding="utf-8"?>
<!--
https://go.microsoft.com/fwlink/?LinkID=208121.
-->
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<Configuration>Release</Configuration>
<Platform>Any CPU</Platform>
<PublishDir>bin\Release\netcoreapp3.1\publish\</PublishDir>
<PublishProtocol>FileSystem</PublishProtocol>
<TargetFramework>netcoreapp3.1</TargetFramework>
<RuntimeIdentifier>linux-arm64</RuntimeIdentifier>
<SelfContained>true</SelfContained>
<PublishSingleFile>True</PublishSingleFile>
<PublishTrimmed>False</PublishTrimmed>
</PropertyGroup>
</Project>
I was then able to publish the app using the publish command in Visual Studio, which built a stand-alone application inside a folder called 'publish'
Now, I get the expected result.
Jetson:/code/publish$ ./HelloDotNetCore
Hello World!

dotnet publish with /p:PublishProfile=?

I'm trying to call "dotnet publish" with a specific publish profile pubxml file as documented here :
https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/visual-studio-publish-profiles?view=aspnetcore-2.1&tabs=aspnetcore2x
However, everything I try seems to result in the default behaviour, and the /p:PublishProfile part is ignored.
dotnet publish /p:PublishProfile="MyFolderProfile"
Doesn't work, and logs no error, building to the default location under "/obj".
I do note that an intentionally incorrect command has the same result though, eg:
dotnet publish /p:PublishProfile="MyFolderProfile-XXXXX"
What am I doing wrong? - Any pointers would be greatly appreciated!

My response is late. My solution has a simple .NET Core console application ConsoleAppCore.csproj. I used Visual Studio IDE to generate a publish profile with the name FolderProfile.pubxml and then the following commands worked for me:
Relative path - From the solution root
dotnet publish ConsoleAppCore\ConsoleAppCore.csproj /p:PublishProfile=ConsoleAppCore\Properties\PublishProfiles\FolderProfile.pubxml
Absolute path - From any location
dotnet publish "C:\work\ConsoleAppCore\ConsoleAppCore.csproj" "/p:PublishProfile=C:\work\ConsoleAppCore\Properties\PublishProfiles\FolderProfile.pubxml"
On Azure dev ops
Task name=.NET Core
Task version=2
Command=publish
Path to projects=I left this empty
Arguments=
$(System.DefaultWorkingDirectory)\ConsoleAppCore\ConsoleAppCore.csproj /p:PublishProfile=$(System.DefaultWorkingDirectory)\ConsoleAppCore\Properties\PublishProfiles\FolderProfile.pubxml --configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)\ConsoleAppCore-Publish\
In the Azure Dev Ops build pipeline scenario, I have redirected the output to a folder under $(Build.ArtifactStagingDirectory) . I also have a Publish Artifact task which is configured to use the staging directory variable.
I have made use of the publish profile XML file because I wanted a single file to govern the complete behavior while on Azure Devops. Relying on a single file for all parameters simplifies management on Azure.
Azure Dev ops - Artifacts Explorer
The Publish Artifact task created a drop for me and this is how it looks. Please notice that the file name in the explorer tallies with the name specified along with the --output option in the dotnet publish task

I ran into the same issue a while ago. I managed to fix it by instead calling:
dotnet build [projectname] /p:PublishProfile=[PublishProfile]

There is an open (as of Oct 2021) issue for Folder Publish with the similar symptoms https://github.com/dotnet/sdk/issues/12490
Workaround I use for now is to manually edit *.pubxml file produced by VS.Net to have both PublishUrl and PublishDir keys with the same values.
With this dotnet publish -p:PublishProfile=... works as expected.

You might need the full path, e.g.
dotnet publish -c Release /p:PublishProfile=Properties\PublishProfiles\FolderProfile.pubxml

Try this based on: https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/visual-studio-publish-profiles?view=aspnetcore-3.1#publish-profiles
dotnet build ..\project\project.csproj /p:DeployOnBuild=true -c Release /p:PublishProfile="Folder Staging"
I included a relative csproj path and a publish profile name with a space in it to clarify how to deal with those cases. The -c flag is optionally used to specify the configuration to use.

See https://github.com/dotnet/docs/issues/19677. The PublishProfile is only the name, any directory before it is disregarded.
PublishProfile property is treated as a file name and the directory is
constructed separately.
The PublishProfileFullPath property should be used if specifying a custom path.

I used this on VS build events
dotnet publish $(SolutionDir)DIRECTORI_1/PROJECT_1.csproj -c Release -o C:\Deployments\FOLDER_1

To solve the problem you must add a < PublishDir > property to your .pubxml file. Then the
dotnet publish /p:Configuration=Release /p:PublishProfile=FolderProfile
command works fine.
Example below.
<?xml version="1.0" encoding="utf-8"?>
<!--
https://go.microsoft.com/fwlink/?LinkID=208121.
-->
<Project>
<PropertyGroup>
<DeleteExistingFiles>false</DeleteExistingFiles>
<ExcludeApp_Data>false</ExcludeApp_Data>
<LaunchSiteAfterPublish>true</LaunchSiteAfterPublish>
<LastUsedBuildConfiguration>Release</LastUsedBuildConfiguration>
<LastUsedPlatform>Any CPU</LastUsedPlatform>
<PublishProvider>FileSystem</PublishProvider>
<PublishUrl>C:\MyApp\PUBLISH</PublishUrl>
<PublishDir>C:\MyApp\PUBLISH</PublishDir>
<WebPublishMethod>FileSystem</WebPublishMethod>
<_TargetId>Folder</_TargetId>
</PropertyGroup>
</Project>
you can also use a relative path like
<PublishUrl>PUBLISH</PublishUrl>
<PublishDir>PUBLISH</PublishDir>

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>