Hello,
I am in the process of converting my Azure Pipelines to run inside of linux containers. I was wondering how to make this work with the license scheme for the WPF application that uses the editor component. Currently in my Windows builds I have a step that copies the license file to C:\ProgramData\AlternetSoft\Licenses but this seems like it’s not likely to work due to differences in Paths. Is there any documentation or guidance on how to get this to ensure the License is validated properly in a linux build enviornment? Thanks.
Hi Gregory,
We support building our libraries with Azure pipeline, please refer to our FAQ :
For specific scenarios like protected environments, multiple build servers, or Azure Pipelines, we provide node-unlocked licenses. These are copied to a specific folder (default: ProgramData\AlternetSoft\Licenses ). You can change this location using the ALTERNET_STUDIO_LICENSE_DIRECTORY environment variabl
However, to my knoweledge, WPF applications can not be build on Linux machines, please let me know if I’m missing something?
Kind regards,
Dmitry
WPF applications can be built on Linux as per MSBuild properties for Microsoft.NET.Sdk - .NET | Microsoft Learn. I already have an unlocked key. So if I place it in /ProgramData/AlternetSoft/Licenses will the license be validated? I’m not sure the logic your software uses to validated the license, and want to verify Linux paths or if lack of C:\ in the path is going to cause the license validation to fail. Thanks.
Could you please point to the web page where is described on how to install WPF workload for Linux? Before checking how our licensing work on Linux, we need to have the ability to compile an empty WPF application on Linux. At this point I have no idea on how to do it.
Hi Gregory,
While we’re still looking at how to build WPF applications on Linux, you can just remove .licx files from your project when building on Linux - this way license checking will not be performed.
Kind regards,
Dmitry
I think the link I posted is all you should need. The documentation in that link states .NET SDK downloads the relevant targeting and runtime packs so long as the EnableWindowsTargeting
is set in the csproj or passed on the build / publish command line argument. You can also pass -r win-x64 but I think it will work fine without that. The build / publish step just won’t output the .exe file so the application will have to be run by using dotnet
on the entry point dll. Hopefully this helps. Thanks.
When I try to build sample wpf application on Linux with dotnet build
, it says:
===========
WpfAppForLinux failed with 1 error(s) (0.0s)
/usr/lib/dotnet/sdk/9.0.102/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(1478,3): error MSB4019: The imported project “/usr/lib/dotnet/sdk/9.0.102/Sdks/Microsoft.NET.Sdk.WindowsDesktop/targets/Microsoft.NET.Sdk.WindowsDesktop.targets” was not found. Confirm that the expression in the Import declaration “;/usr/lib/dotnet/sdk/9.0.102/Sdks/Microsoft.NET.Sdk/targets/../../Microsoft.NET.Sdk.WindowsDesktop/targets/Microsoft.NET.Sdk.WindowsDesktop.targets” is correct, and that the file exists on disk.
Build failed with 1 error(s) in 0.8s
=============
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<EnableWindowsTargeting>true</EnableWindowsTargeting>
<OutputType>WinExe</OutputType>
<TargetFramework>net8.0-windows</TargetFramework>
<Nullable>enable</Nullable>
<ImplicitUsings>enable</ImplicitUsings>
<UseWPF>true</UseWPF>
</PropertyGroup>
</Project>
So I believe EnableWindowsTargeting is not enough. Could you please give more details about your linux configuration? Did you perform any additional installations so EnableWindowsTargeting works on your linux?
My builds are using the microsoft/dotnet-sdk - Docker Image | Docker Hub images. Specifically docker pull mcr.microsoft.com/dotnet/sdk:8.0-noble
Your issue might be related to build .NET 8 using the .NET 9 SDK. dotnet --info
should be able to show you the runtimes installed. I’m not sure if .NET 9 bundles the .NET 8 runtimes. I think the SDK’s bundled with Visual Studio might but the stand alone ones may require installation of other runtimes manually. The best approach might be to use one of the docker containers, but if you don’t have docker installed then I would start by targeting the same runtime as your SDK. Or perhaps compare what is installed in the docker images to your configuration. The docker file links should all be available here dotnet-docker/README.sdk.md at main · dotnet/dotnet-docker · GitHub
Thanks for the information! I installed Docker and successfully created Dockerfiles for .NET console and WPF applications. I was able to build them and retrieve the results from Docker. I’ll post an update here after reviewing the licensing issue.
I am pleased to inform you that we have successfully built our Studio.Wpf demo application in Docker using the pre-release version of Alternet.Studio V10.
Great news! Sounds like there were some changes that needed to be made to support the Linux builds. Is there any guidance you can provide on the licensing aspect? Will any changes required to build on Linux be back ported to version 9 or do we have to wait for version 10? If it is the latter what is expected release timeline for version 10. Thanks.
In the new V10 version, licensing remains the same as in the old version when compiling on Windows. However, when compiling on macOS or Linux, no additional steps are required for licensing.
Currently, only V10 is compatible with Docker builds. There have been many changes—not only related to licensing—that have enabled Docker builds for the WPF part of the library. Additionally, we are actively working on supporting Docker builds for the WinForms part of the library.
We plan to release V10 beta versions, so I believe you will be able to try them in the near future.
1 Like