starred/dotnet-packaging
1
0
Fork 0
mirror of https://github.com/quamotion/dotnet-packaging.git synced 2026-02-14 13:45:53 +00:00
Code Issues 207 Packages Projects Releases Wiki Activity

Publish .NET Core 2.0 apps for RHEL #4

New Issue
Closed
opened 2026-01-29 16:26:54 +00:00 by claunia · 25 comments
claunia commented 2026-01-29 16:26:54 +00:00
Owner
Copy Link

Originally created by @tmds on GitHub (Aug 24, 2017).

hi @qmfrederik this is a nice package. I'm want to check if it can be used for building .net core 2.0 apps that run on rhel and follow these guidelines: https://access.redhat.com/documentation/en-us/net_core/2.0/html/getting_started_guide/gs_install_dotnet#publish_applications.

My first attempt shows a .net core 1.0 framework is required to run the tool. Do you have plans to make it run on 2.0?

Originally created by @tmds on GitHub (Aug 24, 2017). hi @qmfrederik this is a nice package. I'm want to check if it can be used for building .net core 2.0 apps that run on rhel and follow these guidelines: https://access.redhat.com/documentation/en-us/net_core/2.0/html/getting_started_guide/gs_install_dotnet#publish_applications. My first attempt shows a .net core 1.0 framework is required to run the tool. Do you have plans to make it run on 2.0?
claunia commented 2026-01-29 16:26:55 +00:00
Author
Owner
Copy Link

@qmfrederik commented on GitHub (Aug 24, 2017):

Hi @tmds

Yes, getting this to run on .NET Core 2.0 is definitively a goal. I don't think there's anything in the codebase that's not compatible with 2.0, but the CLI is very picky about how it loads tools.

I'll need to check whether we can get .NET Core 2.0 to load a .NET Core 1.0 executable, or whether we need to cross-build for both platforms.

I did some initial research; 318e1f8ba1 and dotnet/cli#6705 may be releated but I need to double check; Xunit seems to have taken the cross-building approach: xunit/xunit@a88c7327e0

@qmfrederik commented on GitHub (Aug 24, 2017): Hi @tmds Yes, getting this to run on .NET Core 2.0 is definitively a goal. I don't think there's anything in the codebase that's not compatible with 2.0, but the CLI is very picky about how it loads tools. I'll need to check whether we can get .NET Core 2.0 to load a .NET Core 1.0 executable, or whether we need to cross-build for both platforms. I did some initial research; 318e1f8ba1210240a43aeb26d9f32f60a26d62da and dotnet/cli#6705 may be releated but I need to double check; Xunit seems to have taken the cross-building approach: xunit/xunit@a88c7327e0b7a5be39051d69f1e7e40dcc86711c
claunia commented 2026-01-29 16:26:56 +00:00
Author
Owner
Copy Link

@qmfrederik commented on GitHub (Sep 4, 2017):

@tmds I just merged #8 and pushed dotnet-rpm 0.1.1-r180 to NuGet.

That versions should work fine with .NET Core 1.0 and .NET Core 2.0; the demo.csproj file has been updated to target netcoreapp2.0.

Let me know if that works for you

@qmfrederik commented on GitHub (Sep 4, 2017): @tmds I just merged #8 and pushed [dotnet-rpm 0.1.1-r180](https://www.nuget.org/packages/dotnet-rpm/0.1.1-r180) to NuGet. That versions should work fine with .NET Core 1.0 and .NET Core 2.0; the [demo.csproj](https://github.com/qmfrederik/dotnet-packaging/blob/master/demo/demo.csproj) file has been updated to target `netcoreapp2.0`. Let me know if that works for you
claunia commented 2026-01-29 16:26:56 +00:00
Author
Owner
Copy Link

@tmds commented on GitHub (Sep 5, 2017):

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.0</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Packaging.Targets" Version="0.1.1-r180" />
    <DotNetCliToolReference Include="dotnet-rpm" Version="0.1.1-r180" />
  </ItemGroup>
</Project>

fails on restore for rhel.7-x64:

/tmp/console$ dotnet restore -r rhel.7-x64
  Restoring packages for /tmp/console/console.csproj...
  Restore completed in 29.18 ms for /tmp/console/console.csproj.
/tmp/console/console.csproj : error NU1605: Detected package downgrade: System.Collections from 4.3.0 to 4.0.11. Reference the package directly from the project to select a different version. 
/tmp/console/console.csproj : error NU1605:  console (>= 1.0.0) -> Packaging.Targets (>= 0.1.1-r180) -> Microsoft.Build.Utilities.Core (>= 15.1.1012) -> System.Console (>= 4.0.0) -> runtime.unix.System.Console (>= 4.3.0) -> System.Collections (>= 4.3.0) 
/tmp/console/console.csproj : error NU1605:  console (>= 1.0.0) -> Packaging.Targets (>= 0.1.1-r180) -> Microsoft.Build.Utilities.Core (>= 15.1.1012) -> System.Collections (>= 4.0.11)
/tmp/console/console.csproj : error NU1605: Detected package downgrade: System.IO.FileSystem.Primitives from 4.3.0 to 4.0.1. Reference the package directly from the project to select a different version. 
/tmp/console/console.csproj : error NU1605:  console (>= 1.0.0) -> Packaging.Targets (>= 0.1.1-r180) -> Microsoft.Build.Utilities.Core (>= 15.1.1012) -> System.Console (>= 4.0.0) -> runtime.unix.System.Console (>= 4.3.0) -> System.IO.FileSystem.Primitives (>= 4.3.0) 
/tmp/console/console.csproj : error NU1605:  console (>= 1.0.0) -> Packaging.Targets (>= 0.1.1-r180) -> Microsoft.Build.Utilities.Core (>= 15.1.1012) -> System.IO.FileSystem.Primitives (>= 4.0.1)
/tmp/console/console.csproj : error NU1605: Detected package downgrade: System.Threading from 4.3.0 to 4.0.11. Reference the package directly from the project to select a different version. 
/tmp/console/console.csproj : error NU1605:  console (>= 1.0.0) -> Packaging.Targets (>= 0.1.1-r180) -> Microsoft.Build.Utilities.Core (>= 15.1.1012) -> System.Console (>= 4.0.0) -> runtime.unix.System.Console (>= 4.3.0) -> System.Threading (>= 4.3.0) 
/tmp/console/console.csproj : error NU1605:  console (>= 1.0.0) -> Packaging.Targets (>= 0.1.1-r180) -> Microsoft.Build.Utilities.Core (>= 15.1.1012) -> System.Threading (>= 4.0.11)
/tmp/console/console.csproj : error NU1605: Detected package downgrade: System.Collections from 4.3.0 to 4.0.11. Reference the package directly from the project to select a different version. 
/tmp/console/console.csproj : error NU1605:  console (>= 1.0.0) -> Packaging.Targets (>= 0.1.1-r180) -> Microsoft.Build.Utilities.Core (>= 15.1.1012) -> System.IO.FileSystem (>= 4.0.1) -> runtime.unix.System.IO.FileSystem (>= 4.3.0) -> System.Collections (>= 4.3.0) 
/tmp/console/console.csproj : error NU1605:  console (>= 1.0.0) -> Packaging.Targets (>= 0.1.1-r180) -> Microsoft.Build.Utilities.Core (>= 15.1.1012) -> System.Collections (>= 4.0.11)
/tmp/console/console.csproj : error NU1605: Detected package downgrade: System.Diagnostics.Debug from 4.3.0 to 4.0.11. Reference the package directly from the project to select a different version. 
/tmp/console/console.csproj : error NU1605:  console (>= 1.0.0) -> Packaging.Targets (>= 0.1.1-r180) -> Microsoft.Build.Utilities.Core (>= 15.1.1012) -> System.IO.FileSystem (>= 4.0.1) -> runtime.unix.System.IO.FileSystem (>= 4.3.0) -> System.Diagnostics.Debug (>= 4.3.0) 
/tmp/console/console.csproj : error NU1605:  console (>= 1.0.0) -> Packaging.Targets (>= 0.1.1-r180) -> Microsoft.Build.Utilities.Core (>= 15.1.1012) -> System.Diagnostics.Debug (>= 4.0.11)
/tmp/console/console.csproj : error NU1605: Detected package downgrade: System.IO.FileSystem.Primitives from 4.3.0 to 4.0.1. Reference the package directly from the project to select a different version. 
/tmp/console/console.csproj : error NU1605:  console (>= 1.0.0) -> Packaging.Targets (>= 0.1.1-r180) -> Microsoft.Build.Utilities.Core (>= 15.1.1012) -> System.IO.FileSystem (>= 4.0.1) -> runtime.unix.System.IO.FileSystem (>= 4.3.0) -> System.IO.FileSystem.Primitives (>= 4.3.0) 
/tmp/console/console.csproj : error NU1605:  console (>= 1.0.0) -> Packaging.Targets (>= 0.1.1-r180) -> Microsoft.Build.Utilities.Core (>= 15.1.1012) -> System.IO.FileSystem.Primitives (>= 4.0.1)
/tmp/console/console.csproj : error NU1605: Detected package downgrade: System.Threading from 4.3.0 to 4.0.11. Reference the package directly from the project to select a different version. 
/tmp/console/console.csproj : error NU1605:  console (>= 1.0.0) -> Packaging.Targets (>= 0.1.1-r180) -> Microsoft.Build.Utilities.Core (>= 15.1.1012) -> System.IO.FileSystem (>= 4.0.1) -> runtime.unix.System.IO.FileSystem (>= 4.3.0) -> System.Threading (>= 4.3.0) 
/tmp/console/console.csproj : error NU1605:  console (>= 1.0.0) -> Packaging.Targets (>= 0.1.1-r180) -> Microsoft.Build.Utilities.Core (>= 15.1.1012) -> System.Threading (>= 4.0.11)
  Restore failed in 519.61 ms for /tmp/console/console.csproj.
@tmds commented on GitHub (Sep 5, 2017): ``` <Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <OutputType>Exe</OutputType> <TargetFramework>netcoreapp2.0</TargetFramework> </PropertyGroup> <ItemGroup> <PackageReference Include="Packaging.Targets" Version="0.1.1-r180" /> <DotNetCliToolReference Include="dotnet-rpm" Version="0.1.1-r180" /> </ItemGroup> </Project> ``` fails on restore for rhel.7-x64: ``` /tmp/console$ dotnet restore -r rhel.7-x64 Restoring packages for /tmp/console/console.csproj... Restore completed in 29.18 ms for /tmp/console/console.csproj. /tmp/console/console.csproj : error NU1605: Detected package downgrade: System.Collections from 4.3.0 to 4.0.11. Reference the package directly from the project to select a different version. /tmp/console/console.csproj : error NU1605: console (>= 1.0.0) -> Packaging.Targets (>= 0.1.1-r180) -> Microsoft.Build.Utilities.Core (>= 15.1.1012) -> System.Console (>= 4.0.0) -> runtime.unix.System.Console (>= 4.3.0) -> System.Collections (>= 4.3.0) /tmp/console/console.csproj : error NU1605: console (>= 1.0.0) -> Packaging.Targets (>= 0.1.1-r180) -> Microsoft.Build.Utilities.Core (>= 15.1.1012) -> System.Collections (>= 4.0.11) /tmp/console/console.csproj : error NU1605: Detected package downgrade: System.IO.FileSystem.Primitives from 4.3.0 to 4.0.1. Reference the package directly from the project to select a different version. /tmp/console/console.csproj : error NU1605: console (>= 1.0.0) -> Packaging.Targets (>= 0.1.1-r180) -> Microsoft.Build.Utilities.Core (>= 15.1.1012) -> System.Console (>= 4.0.0) -> runtime.unix.System.Console (>= 4.3.0) -> System.IO.FileSystem.Primitives (>= 4.3.0) /tmp/console/console.csproj : error NU1605: console (>= 1.0.0) -> Packaging.Targets (>= 0.1.1-r180) -> Microsoft.Build.Utilities.Core (>= 15.1.1012) -> System.IO.FileSystem.Primitives (>= 4.0.1) /tmp/console/console.csproj : error NU1605: Detected package downgrade: System.Threading from 4.3.0 to 4.0.11. Reference the package directly from the project to select a different version. /tmp/console/console.csproj : error NU1605: console (>= 1.0.0) -> Packaging.Targets (>= 0.1.1-r180) -> Microsoft.Build.Utilities.Core (>= 15.1.1012) -> System.Console (>= 4.0.0) -> runtime.unix.System.Console (>= 4.3.0) -> System.Threading (>= 4.3.0) /tmp/console/console.csproj : error NU1605: console (>= 1.0.0) -> Packaging.Targets (>= 0.1.1-r180) -> Microsoft.Build.Utilities.Core (>= 15.1.1012) -> System.Threading (>= 4.0.11) /tmp/console/console.csproj : error NU1605: Detected package downgrade: System.Collections from 4.3.0 to 4.0.11. Reference the package directly from the project to select a different version. /tmp/console/console.csproj : error NU1605: console (>= 1.0.0) -> Packaging.Targets (>= 0.1.1-r180) -> Microsoft.Build.Utilities.Core (>= 15.1.1012) -> System.IO.FileSystem (>= 4.0.1) -> runtime.unix.System.IO.FileSystem (>= 4.3.0) -> System.Collections (>= 4.3.0) /tmp/console/console.csproj : error NU1605: console (>= 1.0.0) -> Packaging.Targets (>= 0.1.1-r180) -> Microsoft.Build.Utilities.Core (>= 15.1.1012) -> System.Collections (>= 4.0.11) /tmp/console/console.csproj : error NU1605: Detected package downgrade: System.Diagnostics.Debug from 4.3.0 to 4.0.11. Reference the package directly from the project to select a different version. /tmp/console/console.csproj : error NU1605: console (>= 1.0.0) -> Packaging.Targets (>= 0.1.1-r180) -> Microsoft.Build.Utilities.Core (>= 15.1.1012) -> System.IO.FileSystem (>= 4.0.1) -> runtime.unix.System.IO.FileSystem (>= 4.3.0) -> System.Diagnostics.Debug (>= 4.3.0) /tmp/console/console.csproj : error NU1605: console (>= 1.0.0) -> Packaging.Targets (>= 0.1.1-r180) -> Microsoft.Build.Utilities.Core (>= 15.1.1012) -> System.Diagnostics.Debug (>= 4.0.11) /tmp/console/console.csproj : error NU1605: Detected package downgrade: System.IO.FileSystem.Primitives from 4.3.0 to 4.0.1. Reference the package directly from the project to select a different version. /tmp/console/console.csproj : error NU1605: console (>= 1.0.0) -> Packaging.Targets (>= 0.1.1-r180) -> Microsoft.Build.Utilities.Core (>= 15.1.1012) -> System.IO.FileSystem (>= 4.0.1) -> runtime.unix.System.IO.FileSystem (>= 4.3.0) -> System.IO.FileSystem.Primitives (>= 4.3.0) /tmp/console/console.csproj : error NU1605: console (>= 1.0.0) -> Packaging.Targets (>= 0.1.1-r180) -> Microsoft.Build.Utilities.Core (>= 15.1.1012) -> System.IO.FileSystem.Primitives (>= 4.0.1) /tmp/console/console.csproj : error NU1605: Detected package downgrade: System.Threading from 4.3.0 to 4.0.11. Reference the package directly from the project to select a different version. /tmp/console/console.csproj : error NU1605: console (>= 1.0.0) -> Packaging.Targets (>= 0.1.1-r180) -> Microsoft.Build.Utilities.Core (>= 15.1.1012) -> System.IO.FileSystem (>= 4.0.1) -> runtime.unix.System.IO.FileSystem (>= 4.3.0) -> System.Threading (>= 4.3.0) /tmp/console/console.csproj : error NU1605: console (>= 1.0.0) -> Packaging.Targets (>= 0.1.1-r180) -> Microsoft.Build.Utilities.Core (>= 15.1.1012) -> System.Threading (>= 4.0.11) Restore failed in 519.61 ms for /tmp/console/console.csproj. ```
claunia commented 2026-01-29 16:26:56 +00:00
Author
Owner
Copy Link

@qmfrederik commented on GitHub (Sep 5, 2017):

Yup, that's weird because it restores correctly if you don't specify rhel.7-x64. Let me have a look.

@qmfrederik commented on GitHub (Sep 5, 2017): Yup, that's weird because it restores correctly if you don't specify `rhel.7-x64`. Let me have a look.
claunia commented 2026-01-29 16:26:57 +00:00
Author
Owner
Copy Link

@qmfrederik commented on GitHub (Sep 5, 2017):

@tmds OK, this should work now. You need to specify the RuntimeIdentifier in your .csproj file, though. Here's what worked for me (with latest dotnet-rpm version).

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.0</TargetFramework>
    <RuntimeIdentifier>rhel.7-x64</RuntimeIdentifier>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Packaging.Targets" Version="0.1.1-r205" />
    <DotNetCliToolReference Include="dotnet-rpm" Version="0.1.1-r205" />
  </ItemGroup>
</Project>

Let me know if it works for you.

@qmfrederik commented on GitHub (Sep 5, 2017): @tmds OK, this should work now. You need to specify the `RuntimeIdentifier` in your `.csproj` file, though. Here's what worked for me (with latest dotnet-rpm version). ``` <Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <OutputType>Exe</OutputType> <TargetFramework>netcoreapp2.0</TargetFramework> <RuntimeIdentifier>rhel.7-x64</RuntimeIdentifier> </PropertyGroup> <ItemGroup> <PackageReference Include="Packaging.Targets" Version="0.1.1-r205" /> <DotNetCliToolReference Include="dotnet-rpm" Version="0.1.1-r205" /> </ItemGroup> </Project> ``` Let me know if it works for you.
claunia commented 2026-01-29 16:26:57 +00:00
Author
Owner
Copy Link

@tmds commented on GitHub (Sep 26, 2017):

Sorry it took a while for me to respond. I'm giving this another try and making some suggestions.

Restore works when adding the RuntimeIdentifier.
Suggestion: it should work without having to set the RuntimeIdentifier.

$ dotnet rpm
You must specify a target framework.
/tmp/console$ dotnet rpm -f netcoreapp2.0
You must specify a target runtime.
/tmp/console$ dotnet rpm -f netcoreapp2.0 -r rhel.7-x64
Microsoft (R) Build Engine version 15.3.409.57025 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  console -> /tmp/console/bin/Debug/netcoreapp2.0/rhel.7-x64/console.dll
  console -> /tmp/console/bin/Debug/netcoreapp2.0/rhel.7-x64/publish/
/home/tmds/.nuget/packages/packaging.targets/0.1.1-r205/build/Packaging.Targets.targets(34,5): error MSB4018: The "RpmTask" task failed unexpectedly. [/tmp/console/console.csproj]
/home/tmds/.nuget/packages/packaging.targets/0.1.1-r205/build/Packaging.Targets.targets(34,5): error MSB4018: System.TypeInitializationException: The type initializer for 'Packaging.Targets.IO.NativeMethods' threw an exception. ---> System.IO.FileLoadException: Could not load the lzma.so library. The error code was . Make sure you've installed liblzma-dev or an equivalent package [/tmp/console/console.csproj]

Suggestion: the target framework and runtime may be picked up from the csproj to improve usablility.

I installed lzma-devel and lzma-libs. But the error persists.
A manual fix is needed $ sudo ln -s /usr/lib64/liblzma.so.5 /usr/lib64/liblzma.so.
Looking at the package info, it seems lzma is deprecated by xz.
Suggestion: maybe move to xz or not depend on native libraries (if possible)

$ dotnet rpm -f netcoreapp2.0 -r rhel.7-x64
Microsoft (R) Build Engine version 15.3.409.57025 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  console -> /tmp/console/bin/Debug/netcoreapp2.0/rhel.7-x64/console.dll
  console -> /tmp/console/bin/Debug/netcoreapp2.0/rhel.7-x64/publish/

No more error!
Suggestion: Like the cli does for the assembly, print out the path where the rpm was generated.

$ find . -name *.rpm
./bin/Debug/netcoreapp2.0/rhel.7-x64/console..rhel.7-x64.rpm

🎉

$ rpm -qip console..rhel.7-x64.rpm 
error: console..rhel.7-x64.rpm: sigh load: BAD
error: console..rhel.7-x64.rpm: not an rpm package (or package manifest)

Perhaps I should have added some more metadata for it to show up here.

Let me know if I can help implement some of these suggestions.

@tmds commented on GitHub (Sep 26, 2017): Sorry it took a while for me to respond. I'm giving this another try and making some suggestions. Restore works when adding the `RuntimeIdentifier`. Suggestion: it should work without having to set the RuntimeIdentifier. ``` $ dotnet rpm You must specify a target framework. /tmp/console$ dotnet rpm -f netcoreapp2.0 You must specify a target runtime. /tmp/console$ dotnet rpm -f netcoreapp2.0 -r rhel.7-x64 Microsoft (R) Build Engine version 15.3.409.57025 for .NET Core Copyright (C) Microsoft Corporation. All rights reserved. console -> /tmp/console/bin/Debug/netcoreapp2.0/rhel.7-x64/console.dll console -> /tmp/console/bin/Debug/netcoreapp2.0/rhel.7-x64/publish/ /home/tmds/.nuget/packages/packaging.targets/0.1.1-r205/build/Packaging.Targets.targets(34,5): error MSB4018: The "RpmTask" task failed unexpectedly. [/tmp/console/console.csproj] /home/tmds/.nuget/packages/packaging.targets/0.1.1-r205/build/Packaging.Targets.targets(34,5): error MSB4018: System.TypeInitializationException: The type initializer for 'Packaging.Targets.IO.NativeMethods' threw an exception. ---> System.IO.FileLoadException: Could not load the lzma.so library. The error code was . Make sure you've installed liblzma-dev or an equivalent package [/tmp/console/console.csproj] ``` Suggestion: the target framework and runtime may be picked up from the csproj to improve usablility. I installed lzma-devel and lzma-libs. But the error persists. A manual fix is needed `$ sudo ln -s /usr/lib64/liblzma.so.5 /usr/lib64/liblzma.so`. Looking at the package info, it seems lzma is deprecated by xz. Suggestion: maybe move to xz or not depend on native libraries (if possible) ``` $ dotnet rpm -f netcoreapp2.0 -r rhel.7-x64 Microsoft (R) Build Engine version 15.3.409.57025 for .NET Core Copyright (C) Microsoft Corporation. All rights reserved. console -> /tmp/console/bin/Debug/netcoreapp2.0/rhel.7-x64/console.dll console -> /tmp/console/bin/Debug/netcoreapp2.0/rhel.7-x64/publish/ ``` No more error! Suggestion: Like the cli does for the assembly, print out the path where the rpm was generated. ``` $ find . -name *.rpm ./bin/Debug/netcoreapp2.0/rhel.7-x64/console..rhel.7-x64.rpm ``` :tada: ``` $ rpm -qip console..rhel.7-x64.rpm error: console..rhel.7-x64.rpm: sigh load: BAD error: console..rhel.7-x64.rpm: not an rpm package (or package manifest) ``` Perhaps I should have added some more metadata for it to show up here. Let me know if I can help implement some of these suggestions.
claunia commented 2026-01-29 16:26:57 +00:00
Author
Owner
Copy Link

@qmfrederik commented on GitHub (Sep 26, 2017):

Hi @tmds Thanks for the feedback!

I split off some of the issues you found in separate issues. They're all marked "up for grabs" :-).

Regarding the last error, one thing that catches my eye is that the package version number is missing from the package path (there should be a version number in between the two dots in console..rhel.7-x64.rpm).

The RPM version number is based off the PackageVersion variable which is set to either AssemblyFileVersion or 1.0.0 if AssemblyFileVersion is empty. So it's weird you get an empty string anyhow.

Can you add a AssemblyFileVersion property in your .csproj file and set it to a value like 1.0.0 and let me know what happens?

@qmfrederik commented on GitHub (Sep 26, 2017): Hi @tmds Thanks for the feedback! I split off some of the issues you found in separate issues. They're all marked "up for grabs" :-). Regarding the last error, one thing that catches my eye is that the package version number is missing from the package path (there should be a version number in between the two dots in `console..rhel.7-x64.rpm`). The RPM version number is based off the `PackageVersion` variable which is set to either `AssemblyFileVersion` or `1.0.0` if `AssemblyFileVersion` is empty. So it's weird you get an empty string anyhow. Can you add a `AssemblyFileVersion` property in your `.csproj` file and set it to a value like `1.0.0` and let me know what happens?
claunia commented 2026-01-29 16:26:57 +00:00
Author
Owner
Copy Link

@qmfrederik commented on GitHub (Sep 26, 2017):

Barring that, you should also be able to run:

dotnet msbuild /t:CreateRpm /p:RuntimeIdentifier=rhel.7-x64 /p:TargetFramework=netcoreapp2.0  /v:diag

to capture additional output from the build process.

@qmfrederik commented on GitHub (Sep 26, 2017): Barring that, you should also be able to run: ``` dotnet msbuild /t:CreateRpm /p:RuntimeIdentifier=rhel.7-x64 /p:TargetFramework=netcoreapp2.0 /v:diag ``` to capture additional output from the build process.
claunia commented 2026-01-29 16:26:58 +00:00
Author
Owner
Copy Link

@tmds commented on GitHub (Oct 9, 2017):

Without adding AssemblyFileVersion, console.AssemblyInfo.cs (under obj/Debug/netcoreapp2.0/rhel.7-x64) has:

[assembly: System.Reflection.AssemblyCompanyAttribute("console")]
[assembly: System.Reflection.AssemblyConfigurationAttribute("Debug")]
[assembly: System.Reflection.AssemblyDescriptionAttribute("Package Description")]
[assembly: System.Reflection.AssemblyFileVersionAttribute("1.0.0.0")]
[assembly: System.Reflection.AssemblyInformationalVersionAttribute("1.0.0")]
[assembly: System.Reflection.AssemblyProductAttribute("console")]
[assembly: System.Reflection.AssemblyTitleAttribute("console")]
[assembly: System.Reflection.AssemblyVersionAttribute("1.0.0.0")]

dotnet msbuild /t:CreateRpm /p:RuntimeIdentifier=rhel.7-x64 /p:TargetFramework=netcoreapp2.0 /v:diag
gives this output:
https://paste.fedoraproject.org/paste/fsKAupoYPbcHsDUDZsxJUQ

@tmds commented on GitHub (Oct 9, 2017): Without adding `AssemblyFileVersion`, `console.AssemblyInfo.cs` (under obj/Debug/netcoreapp2.0/rhel.7-x64) has: ``` [assembly: System.Reflection.AssemblyCompanyAttribute("console")] [assembly: System.Reflection.AssemblyConfigurationAttribute("Debug")] [assembly: System.Reflection.AssemblyDescriptionAttribute("Package Description")] [assembly: System.Reflection.AssemblyFileVersionAttribute("1.0.0.0")] [assembly: System.Reflection.AssemblyInformationalVersionAttribute("1.0.0")] [assembly: System.Reflection.AssemblyProductAttribute("console")] [assembly: System.Reflection.AssemblyTitleAttribute("console")] [assembly: System.Reflection.AssemblyVersionAttribute("1.0.0.0")] ``` `dotnet msbuild /t:CreateRpm /p:RuntimeIdentifier=rhel.7-x64 /p:TargetFramework=netcoreapp2.0 /v:diag` gives this output: https://paste.fedoraproject.org/paste/fsKAupoYPbcHsDUDZsxJUQ
claunia commented 2026-01-29 16:26:58 +00:00
Author
Owner
Copy Link

@qmfrederik commented on GitHub (Oct 10, 2017):

@tmds I had another look at this this evening.

I can confirm that you currently need to set the AssemblyFileVersion for dotnet rpm to generate a valid RPM package. Once that's done, it works pretty well for me, though.

Let's take the following .csproj file:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.0</TargetFramework>
    <RuntimeIdentifier>rhel.7-x64</RuntimeIdentifier>
    <AssemblyFileVersion>1.0.0</AssemblyFileVersion>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Packaging.Targets" Version="0.1.1-r231" />
    <DotNetCliToolReference Include="dotnet-rpm" Version="0.1.1-r231" />
  </ItemGroup>
</Project>

Running dotnet rpm gives this output

[vagrant@localhost demo]$ dotnet rpm -f netcoreapp2.0 -r rhel.7-x64
Microsoft (R) Build Engine version 15.3.409.57025 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  demo -> /home/vagrant/demo/bin/Debug/netcoreapp2.0/rhel.7-x64/demo.dll
  demo -> /home/vagrant/demo/bin/Debug/netcoreapp2.0/rhel.7-x64/publish/
  Creating RPM package /home/vagrant/demo/bin/Debug/netcoreapp2.0/rhel.7-x64/demo.1.0.0.rhel.7-x64.rpm

RPM seems to be (fairly) happy with the generated RPM package:

[vagrant@localhost demo]$ rpm -qip bin/Debug/netcoreapp2.0/rhel.7-x64/demo.1.0.0.rhel.7-x64.rpm
warning: bin/Debug/netcoreapp2.0/rhel.7-x64/demo.1.0.0.rhel.7-x64.rpm: Header V3 RSA/SHA256 Signature, key ID d97e5b2c: NOKEY
Name        : demo
Version     : 1.0.0
Release     : 0
Architecture: x86_64
Install Date: (not installed)
Group       : System Environment/Libraries
Size        : 68170737
License     : demo License
Signature   : RSA/SHA256, Tue 10 Oct 2017 06:02:57 PM EDT, Key ID d96a51b7d97e5b2c
Source RPM  : demo-1.0.0-0.src.rpm
Build Date  : Tue 10 Oct 2017 06:02:26 PM EDT
Build Host  : dotnet-rpm
Relocations : (not relocatable)
Vendor      :
URL         :
Summary     : demo version 1.0.0-0
Description :
demo version 1.0.0-0

And installing works as well:

[vagrant@localhost demo]$ sudo yum install -y bin/Debug/netcoreapp2.0/rhel.7-x64/demo.1.0.0.rhel.7-x64.rpm
Loaded plugins: langpacks, product-id, search-disabled-repos
Examining bin/Debug/netcoreapp2.0/rhel.7-x64/demo.1.0.0.rhel.7-x64.rpm: demo-1.0.0-0.x86_64
Marking bin/Debug/netcoreapp2.0/rhel.7-x64/demo.1.0.0.rhel.7-x64.rpm to be installed
Resolving Dependencies
--> Running transaction check
---> Package demo.x86_64 0:1.0.0-0 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

==============================================================================================================================================
 Package                     Arch                          Version                        Repository                                     Size
==============================================================================================================================================
Installing:
 demo                        x86_64                        1.0.0-0                        /demo.1.0.0.rhel.7-x64                         65 M

Transaction Summary
==============================================================================================================================================
Install  1 Package

Total size: 65 M
Installed size: 65 M
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : demo-1.0.0-0.x86_64                                                                                                        1/1
  Verifying  : demo-1.0.0-0.x86_64                                                                                                        1/1

Installed:
  demo.x86_64 0:1.0.0-0

Complete!

And yes, the demo project has been deployed to /usr/local/demo:

[vagrant@localhost demo]$ ls -l /usr/share/demo/
total 66936
(...)
-rwxr-xr-x 1 root root    97408 Oct 10 18:02 demo
(...)

and it runs:

[vagrant@localhost demo]$ /usr/share/demo/demo
Hello World!

Just to be sure - does generating a package based on the .csproj at the top of this comment work for you?

PS: Ping me if you ever happen to be close to the Brussels area; I have the feeling we can straighten out most of the dotnet rpm issues in a couple of hours ;-)

@qmfrederik commented on GitHub (Oct 10, 2017): @tmds I had another look at this this evening. I can confirm that you currently need to set the `AssemblyFileVersion` for `dotnet rpm` to generate a valid RPM package. Once that's done, it works pretty well for me, though. Let's take the following `.csproj` file: ``` <Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <OutputType>Exe</OutputType> <TargetFramework>netcoreapp2.0</TargetFramework> <RuntimeIdentifier>rhel.7-x64</RuntimeIdentifier> <AssemblyFileVersion>1.0.0</AssemblyFileVersion> </PropertyGroup> <ItemGroup> <PackageReference Include="Packaging.Targets" Version="0.1.1-r231" /> <DotNetCliToolReference Include="dotnet-rpm" Version="0.1.1-r231" /> </ItemGroup> </Project> ``` Running `dotnet rpm` gives this output ``` [vagrant@localhost demo]$ dotnet rpm -f netcoreapp2.0 -r rhel.7-x64 Microsoft (R) Build Engine version 15.3.409.57025 for .NET Core Copyright (C) Microsoft Corporation. All rights reserved. demo -> /home/vagrant/demo/bin/Debug/netcoreapp2.0/rhel.7-x64/demo.dll demo -> /home/vagrant/demo/bin/Debug/netcoreapp2.0/rhel.7-x64/publish/ Creating RPM package /home/vagrant/demo/bin/Debug/netcoreapp2.0/rhel.7-x64/demo.1.0.0.rhel.7-x64.rpm ``` RPM seems to be (fairly) happy with the generated RPM package: ``` [vagrant@localhost demo]$ rpm -qip bin/Debug/netcoreapp2.0/rhel.7-x64/demo.1.0.0.rhel.7-x64.rpm warning: bin/Debug/netcoreapp2.0/rhel.7-x64/demo.1.0.0.rhel.7-x64.rpm: Header V3 RSA/SHA256 Signature, key ID d97e5b2c: NOKEY Name : demo Version : 1.0.0 Release : 0 Architecture: x86_64 Install Date: (not installed) Group : System Environment/Libraries Size : 68170737 License : demo License Signature : RSA/SHA256, Tue 10 Oct 2017 06:02:57 PM EDT, Key ID d96a51b7d97e5b2c Source RPM : demo-1.0.0-0.src.rpm Build Date : Tue 10 Oct 2017 06:02:26 PM EDT Build Host : dotnet-rpm Relocations : (not relocatable) Vendor : URL : Summary : demo version 1.0.0-0 Description : demo version 1.0.0-0 ``` And installing works as well: ``` [vagrant@localhost demo]$ sudo yum install -y bin/Debug/netcoreapp2.0/rhel.7-x64/demo.1.0.0.rhel.7-x64.rpm Loaded plugins: langpacks, product-id, search-disabled-repos Examining bin/Debug/netcoreapp2.0/rhel.7-x64/demo.1.0.0.rhel.7-x64.rpm: demo-1.0.0-0.x86_64 Marking bin/Debug/netcoreapp2.0/rhel.7-x64/demo.1.0.0.rhel.7-x64.rpm to be installed Resolving Dependencies --> Running transaction check ---> Package demo.x86_64 0:1.0.0-0 will be installed --> Finished Dependency Resolution Dependencies Resolved ============================================================================================================================================== Package Arch Version Repository Size ============================================================================================================================================== Installing: demo x86_64 1.0.0-0 /demo.1.0.0.rhel.7-x64 65 M Transaction Summary ============================================================================================================================================== Install 1 Package Total size: 65 M Installed size: 65 M Downloading packages: Running transaction check Running transaction test Transaction test succeeded Running transaction Installing : demo-1.0.0-0.x86_64 1/1 Verifying : demo-1.0.0-0.x86_64 1/1 Installed: demo.x86_64 0:1.0.0-0 Complete! ``` And yes, the demo project has been deployed to `/usr/local/demo`: ``` [vagrant@localhost demo]$ ls -l /usr/share/demo/ total 66936 (...) -rwxr-xr-x 1 root root 97408 Oct 10 18:02 demo (...) ``` and it runs: ``` [vagrant@localhost demo]$ /usr/share/demo/demo Hello World! ``` Just to be sure - does generating a package based on the `.csproj` at the top of this comment work for you? PS: Ping me if you ever happen to be close to the Brussels area; I have the feeling we can straighten out most of the `dotnet rpm` issues in a couple of hours ;-)
claunia commented 2026-01-29 16:26:58 +00:00
Author
Owner
Copy Link

@tmds commented on GitHub (Oct 11, 2017):

/tmp/console2$ dotnet rpm -f netcoreapp2.0 -r rhel.7-x64
Microsoft (R) Build Engine version 15.3.409.57025 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

Program.cs(1,1): warning SA1652: Enable XML documentation output [/tmp/console2/console.csproj]
Program.cs(1,1): warning SA1633: The file header is missing or not located at the top of the file. [/tmp/console2/console.csproj]
Program.cs(5,11): warning SA1400: Element 'Program' must declare an access modifier [/tmp/console2/console.csproj]
Program.cs(1,1): warning SA1200: Using directive must appear within a namespace declaration [/tmp/console2/console.csproj]
Program.cs(3,11): warning SA1300: Element 'console2' must begin with an uppercase letter [/tmp/console2/console.csproj]
Program.cs(7,21): warning SA1400: Element 'Main' must declare an access modifier [/tmp/console2/console.csproj]
  console -> /tmp/console2/bin/Debug/netcoreapp2.0/rhel.7-x64/console.dll
  console -> /tmp/console2/bin/Debug/netcoreapp2.0/rhel.7-x64/publish/
  Creating RPM package /tmp/console2/bin/Debug/netcoreapp2.0/rhel.7-x64/console.1.0.0.rhel.7-x64.rpm
/tmp/console2$ rpm -qip /tmp/console2/bin/Debug/netcoreapp2.0/rhel.7-x64/console.1.0.0.rhel.7-x64.rpm
error: /tmp/console2/bin/Debug/netcoreapp2.0/rhel.7-x64/console.1.0.0.rhel.7-x64.rpm: sigh load: BAD
error: /tmp/console2/bin/Debug/netcoreapp2.0/rhel.7-x64/console.1.0.0.rhel.7-x64.rpm: not an rpm package (or package manifest)

Some things are working better than before. The package seems not to be ok. It also fails to install due to sigh load: BAD.
I am doing this on Fedora 25.

PS: Ping me if you ever happen to be close to the Brussels area; I have the feeling we can straighten out most of the dotnet rpm issues in a couple of hours ;-)

It doesn't happen often I am near Brussels. I will investigate further (probably next week). Thank you for support and follow-up!

@tmds commented on GitHub (Oct 11, 2017): ``` /tmp/console2$ dotnet rpm -f netcoreapp2.0 -r rhel.7-x64 Microsoft (R) Build Engine version 15.3.409.57025 for .NET Core Copyright (C) Microsoft Corporation. All rights reserved. Program.cs(1,1): warning SA1652: Enable XML documentation output [/tmp/console2/console.csproj] Program.cs(1,1): warning SA1633: The file header is missing or not located at the top of the file. [/tmp/console2/console.csproj] Program.cs(5,11): warning SA1400: Element 'Program' must declare an access modifier [/tmp/console2/console.csproj] Program.cs(1,1): warning SA1200: Using directive must appear within a namespace declaration [/tmp/console2/console.csproj] Program.cs(3,11): warning SA1300: Element 'console2' must begin with an uppercase letter [/tmp/console2/console.csproj] Program.cs(7,21): warning SA1400: Element 'Main' must declare an access modifier [/tmp/console2/console.csproj] console -> /tmp/console2/bin/Debug/netcoreapp2.0/rhel.7-x64/console.dll console -> /tmp/console2/bin/Debug/netcoreapp2.0/rhel.7-x64/publish/ Creating RPM package /tmp/console2/bin/Debug/netcoreapp2.0/rhel.7-x64/console.1.0.0.rhel.7-x64.rpm /tmp/console2$ rpm -qip /tmp/console2/bin/Debug/netcoreapp2.0/rhel.7-x64/console.1.0.0.rhel.7-x64.rpm error: /tmp/console2/bin/Debug/netcoreapp2.0/rhel.7-x64/console.1.0.0.rhel.7-x64.rpm: sigh load: BAD error: /tmp/console2/bin/Debug/netcoreapp2.0/rhel.7-x64/console.1.0.0.rhel.7-x64.rpm: not an rpm package (or package manifest) ``` Some things are working better than before. The package seems not to be ok. It also fails to install due to `sigh load: BAD`. I am doing this on Fedora 25. > PS: Ping me if you ever happen to be close to the Brussels area; I have the feeling we can straighten out most of the dotnet rpm issues in a couple of hours ;-) It doesn't happen often I am near Brussels. I will investigate further (probably next week). Thank you for support and follow-up!
claunia commented 2026-01-29 16:26:59 +00:00
Author
Owner
Copy Link

@qmfrederik commented on GitHub (Oct 11, 2017):

@tmds Thanks, I can reproduce this on Fedora 25. It's likely something's wrong with way I calculate the signature; it's odd since RHEL 7.3 and Centos 7.3 don't complain about the generated package.

In other news, I pushed r240 to NuGet which fixes a couple of the other items you've put forward:

  • You no longer need to set the AssemblyFileVersion property in the project; rather, we now use Version which is populated automatically by the tools (if you don't set it it'll default to 1.0.0)
  • Although you still need to install liblzma, we can now load liblzma.so.5, so no need to symlink.
@qmfrederik commented on GitHub (Oct 11, 2017): @tmds Thanks, I can reproduce this on Fedora 25. It's likely something's wrong with way I calculate the signature; it's odd since RHEL 7.3 and Centos 7.3 don't complain about the generated package. In other news, I pushed r240 to NuGet which fixes a couple of the other items you've put forward: - You no longer need to set the `AssemblyFileVersion` property in the project; rather, we now use `Version` which is populated automatically by the tools (if you don't set it it'll default to 1.0.0) - Although you still need to install liblzma, we can now load `liblzma.so.5`, so no need to symlink.
claunia commented 2026-01-29 16:26:59 +00:00
Author
Owner
Copy Link

@qmfrederik commented on GitHub (Oct 11, 2017):

The RPM version seem to be different:

On RHEL7:

[vagrant@localhost ~]$ rpm --version
RPM version 4.11.3

On Fedora 25:

[vagrant@localhost demo]$ rpm --version
RPM version 4.13.0.1

Let me check what changed.

(note: command to configure RPM: CPPFLAGS="-I/usr/include/nspr4 -I/usr/include/nss3" ./autogen.sh --with-external-db)

@qmfrederik commented on GitHub (Oct 11, 2017): The RPM version seem to be different: On RHEL7: ``` [vagrant@localhost ~]$ rpm --version RPM version 4.11.3 ``` On Fedora 25: ``` [vagrant@localhost demo]$ rpm --version RPM version 4.13.0.1 ``` Let me check what changed. (note: command to configure RPM: `CPPFLAGS="-I/usr/include/nspr4 -I/usr/include/nss3" ./autogen.sh --with-external-db`)
claunia commented 2026-01-29 16:26:59 +00:00
Author
Owner
Copy Link

@qmfrederik commented on GitHub (Oct 11, 2017):

The packages we generate work with RPM 4.13.0 but fail with RPM 4.13.0.1. Looking at the git history, there seem to be about ~20 commits between both releases, most focused on validating the GPG signatures, so it's likely the issue is with the GPG signature we generate.

I'll try to dive into that the coming days.

@qmfrederik commented on GitHub (Oct 11, 2017): The packages we generate work with RPM 4.13.0 but fail with RPM 4.13.0.1. [Looking at the git history](https://github.com/rpm-software-management/rpm/commits/rpm-4.13.0.1-release), there seem to be about ~20 commits between both releases, most focused on validating the GPG signatures, so it's likely the issue is with the GPG signature we generate. I'll try to dive into that the coming days.
claunia commented 2026-01-29 16:26:59 +00:00
Author
Owner
Copy Link

@qmfrederik commented on GitHub (Oct 12, 2017):

bb45f3364e is causing the validation to fail.

@qmfrederik commented on GitHub (Oct 12, 2017): https://github.com/rpm-software-management/rpm/commit/bb45f3364e561ba62d369ae703235a4b1f0cbccd is causing the validation to fail.
claunia commented 2026-01-29 16:27:00 +00:00
Author
Owner
Copy Link

@qmfrederik commented on GitHub (Oct 12, 2017):

@tmds OK - I think I managed to fix this one, it the ordering of the signature fields which was not to RPM's taste. It should work now on Fedora 25.

I'll do some tests with RPM from master - it looks like even stricter validation has been added in the dev versions of RPM.

@qmfrederik commented on GitHub (Oct 12, 2017): @tmds OK - I think I managed to fix this one, it the ordering of the signature fields which was not to RPM's taste. It should work now on Fedora 25. I'll do some tests with RPM from master - it looks like even stricter validation has been added in the dev versions of RPM.
claunia commented 2026-01-29 16:27:01 +00:00
Author
Owner
Copy Link

@qmfrederik commented on GitHub (Oct 13, 2017):

RPM master added one more validation check (no empty arrays in metadata) which we violated; I fixed that and the RPM packages generated by dotnet rpm now work with the latest version of RPM. I've pushed that to NuGet as version 0.1.1-r260.

@qmfrederik commented on GitHub (Oct 13, 2017): RPM master added one more validation check (no empty arrays in metadata) which we violated; I fixed that and the RPM packages generated by dotnet rpm now work with the latest version of RPM. I've pushed that to NuGet as version 0.1.1-r260.
claunia commented 2026-01-29 16:27:01 +00:00
Author
Owner
Copy Link

@ms0713 commented on GitHub (Nov 14, 2017):

@tmds Have you tried bulding .net core 2.0 app in Windows and running it on RHEL7? If yes then please share the steps here. I m able to build .net core 2.0 app using Visual Studio but not able to run it on RHEL.

When I build my .net core 2.0 app in 32bit runtime, it runs successfully in RHEL 7. But building 64bit .net core 2.0 app is not running in RHEL 7. My Visual Studio is 32 bit application so while running 32bit .net core 2.0 app it works fine as it runs on 32bit dotnet.exe. I have already installed 64bit dotnet.exe but my Visual Studio always launches 32bit dotnet.exe while running .net core appliaction.

Solution should be like that my Visual Studio must be able to identify between 32bit/64bit arch and launch dotnet.exe accordingly. How to acheive this that i dont know.

@ms0713 commented on GitHub (Nov 14, 2017): @tmds Have you tried bulding .net core 2.0 app in Windows and running it on RHEL7? If yes then please share the steps here. I m able to build .net core 2.0 app using Visual Studio but not able to run it on RHEL. When I build my .net core 2.0 app in 32bit runtime, it runs successfully in RHEL 7. But building 64bit .net core 2.0 app is not running in RHEL 7. My Visual Studio is 32 bit application so while running 32bit .net core 2.0 app it works fine as it runs on 32bit dotnet.exe. I have already installed 64bit dotnet.exe but my Visual Studio always launches 32bit dotnet.exe while running .net core appliaction. Solution should be like that my Visual Studio must be able to identify between 32bit/64bit arch and launch dotnet.exe accordingly. How to acheive this that i dont know.
claunia commented 2026-01-29 16:27:01 +00:00
Author
Owner
Copy Link

@tmds commented on GitHub (Nov 14, 2017):

@ms0713 Can you try publishing your .net core apps for RHEL following the guidelines here: https://access.redhat.com/documentation/en-us/net_core/2.0/html/getting_started_guide/gs_install_dotnet#publish_applications.
The goal of this issue is to see if 'dotnet rpm' can be used to package according to those guidelines.

@tmds commented on GitHub (Nov 14, 2017): @ms0713 Can you try publishing your .net core apps for RHEL following the guidelines here: https://access.redhat.com/documentation/en-us/net_core/2.0/html/getting_started_guide/gs_install_dotnet#publish_applications. The goal of this issue is to see if 'dotnet rpm' can be used to package according to those guidelines.
claunia commented 2026-01-29 16:27:02 +00:00
Author
Owner
Copy Link

@tmds commented on GitHub (Nov 14, 2017):

@qmfrederik I came across https://github.com/daveaglick/Buildalyzer/. I think it can it can help to figure out values from the project file for the packaging. Please take a look and let me know what you think.

@tmds commented on GitHub (Nov 14, 2017): @qmfrederik I came across https://github.com/daveaglick/Buildalyzer/. I think it can it can help to figure out values from the project file for the packaging. Please take a look and let me know what you think.
claunia commented 2026-01-29 16:27:02 +00:00
Author
Owner
Copy Link

@qmfrederik commented on GitHub (Nov 15, 2017):

@tmds Thanks, may be useful, I'll have a closer look at it.

That said, I was wondering now that corefx 2.0 is portable on Linux, whether we still need to worry about the RIDs. We're still building separately for rhel-x64 and ubuntu-x64 but I'm wondering whether we should just start targetting linux-x64 instead.

What RID do you see most of RedHat/CentOS project targetting? Vanilla linux-x64 or something more targetted?

@qmfrederik commented on GitHub (Nov 15, 2017): @tmds Thanks, may be useful, I'll have a closer look at it. That said, I was wondering now that corefx 2.0 is portable on Linux, whether we still need to worry about the RIDs. We're still building separately for `rhel-x64` and `ubuntu-x64` but I'm wondering whether we should just start targetting `linux-x64` instead. What RID do you see most of RedHat/CentOS project targetting? Vanilla `linux-x64` or something more targetted?
claunia commented 2026-01-29 16:27:03 +00:00
Author
Owner
Copy Link

@tmds commented on GitHub (Nov 17, 2017):

For dotnet publish, targetting rhel.7-x64 is the same as linux-x64.
In the docs, we suggest using the rhel.7-x64 as a way of customizing the csproj for that distro.
dotnet rpm could do this similar:

<PropertyGroup Condition"'$(RuntimeIdentifier)' == 'rhel.7-x64'">
  <PackageDependencies>rh-dotnet20</PackageDependencies>
  <PackageRunScript>run-on-rhel.sh<PackageRunScript>
</PropertyGroup>
@tmds commented on GitHub (Nov 17, 2017): For dotnet publish, targetting rhel.7-x64 is the same as linux-x64. In the docs, we suggest using the rhel.7-x64 as a way of customizing the csproj for that distro. `dotnet rpm` could do this similar: ```xml <PropertyGroup Condition"'$(RuntimeIdentifier)' == 'rhel.7-x64'"> <PackageDependencies>rh-dotnet20</PackageDependencies> <PackageRunScript>run-on-rhel.sh<PackageRunScript> </PropertyGroup> ```
claunia commented 2026-01-29 16:27:03 +00:00
Author
Owner
Copy Link

@qmfrederik commented on GitHub (Aug 31, 2018):

@tmds I've fixed a couple of other RPM-related bugs recently, plus added integration tests which create RPM packages and install them in Docker containers running Fedora, CentOS & friends.

I was thinking I could add CI test that packages a project that match your requirements and installs it in a Docker container based on RHEL, to make sure we don't regress on this scenario.

There doesn't seem to be a readily-available RHEL Docker image on Docker Hub, is that correct?

@qmfrederik commented on GitHub (Aug 31, 2018): @tmds I've fixed a couple of other RPM-related bugs recently, plus added integration tests which create RPM packages and install them in Docker containers running Fedora, CentOS & friends. I was thinking I could add CI test that packages a project that match your requirements and installs it in a Docker container based on RHEL, to make sure we don't regress on this scenario. There doesn't seem to be a readily-available RHEL Docker image on Docker Hub, is that correct?
claunia commented 2026-01-29 16:27:03 +00:00
Author
Owner
Copy Link

@tmds commented on GitHub (Aug 31, 2018):

If you have CentOS, then you covered RHEL too. There are no RHEL images on Docker Hub.

@tmds commented on GitHub (Aug 31, 2018): If you have CentOS, then you covered RHEL too. There are no RHEL images on Docker Hub.
claunia commented 2026-01-29 16:27:04 +00:00
Author
Owner
Copy Link

@tmds commented on GitHub (Jun 11, 2019):

I'm no longer looking into this, so I'll close the issue.

@tmds commented on GitHub (Jun 11, 2019): I'm no longer looking into this, so I'll close the issue.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
enhancement
pending-validation
pull-request
Mirrored from GitHub Pull Request
 up-for-grabs
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/dotnet-packaging#4
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?