Issue 2064: Mono70 moniker #2142

Serg046 · 2022-10-07T00:25:35Z

Not sure I understand the task properly, please take a look
#2064

Serg046 · 2022-10-07T00:26:23Z

src/BenchmarkDotNet/Environments/Runtimes/CoreRuntime.cs

@@ -19,6 +19,7 @@ public class CoreRuntime : Runtime
        public static readonly CoreRuntime Core50 = new CoreRuntime(RuntimeMoniker.Net50, "net5.0", ".NET 5.0");
        public static readonly CoreRuntime Core60 = new CoreRuntime(RuntimeMoniker.Net60, "net6.0", ".NET 6.0");
        public static readonly CoreRuntime Core70 = new CoreRuntime(RuntimeMoniker.Net70, "net7.0", ".NET 7.0");
+        public static readonly CoreRuntime Mono70 = new CoreRuntime(RuntimeMoniker.Mono70, "mono7.0", "Mono with .NET 7.0");


Not sure if this should be here or in MonoRuntime

I agree, MonoRuntime would most likely be a better place.

timcassell · 2022-10-07T02:18:29Z

src/BenchmarkDotNet/Portability/RuntimeInformation.cs

@@ -25,7 +25,7 @@ internal static class RuntimeInformation
        internal const string ReleaseConfigurationName = "RELEASE";
        internal const string Unknown = "?";

-        public static bool IsMono { get; } = Type.GetType("Mono.Runtime") != null; // it allocates a lot of memory, we need to check it once in order to keep Engine non-allocating!
+        public static bool IsMono { get; } = Type.GetType("Mono.RuntimeStructs") != null; // it allocates a lot of memory, we need to check it once in order to keep Engine non-allocating!


Does this still return true on the old Mono runtime?

Mono checks are performed elsewhere in the library like in the memory diagnoser (GcStats) since it did not support AppDomain.MonitoringIsEnabled. Is that still the case with the new Mono runtime?

It's also checked in the MonoDisassembler, and I have no idea if that's relevant here.

And other places in RuntimeInformation.cs, all of which should be verified.

I have checked it through this sample running on latest Mono 6.12.0 and Mono 5.0.0.100 (2017-05-11). The property returns true on those versions.

Ok, I just tested (using Adam's example), and it seems monitoring is still not available on the new Core/Mono runtime. I would assume everything else behaves the same, too (MonoDisassembler), but I didn't test.

adamsitnik

@Serg046 I am impressed that you have selected such ambitious task for first contribution!

It looks promising, but we need a new toolchain to make sure it actually runs Mono. PTAL at my comments. Thank you!

adamsitnik · 2022-10-11T19:40:03Z

src/BenchmarkDotNet.Annotations/Jobs/RuntimeMoniker.cs

+        MonoAOTLLVMNet70,
+
+        /// <summary>
+        /// Mono with .net7.0


nit: the comment could be improved

Suggested change

/// Mono with .net7.0

/// .NET 7 using MonoVM (not CLR which is the default)

src/BenchmarkDotNet.Annotations/Jobs/RuntimeMoniker.cs

adamsitnik · 2022-10-11T20:12:25Z

src/BenchmarkDotNet/ConsoleArguments/ConfigParser.cs

@@ -410,11 +408,21 @@ private static Job CreateJobForGivenRuntime(Job baseJob, string runtimeId, Comma
                    return MakeMonoAOTLLVMJob(baseJob, options, "net6.0");
                case RuntimeMoniker.MonoAOTLLVMNet70:
                    return MakeMonoAOTLLVMJob(baseJob, options, "net7.0");
+                case RuntimeMoniker.Mono70:
+                    return CreateCoreJob(baseJob, "net7.0", "Mono with .NET 7.0", options, CoreRuntime.Core70)
+                        .WithArguments(new Argument[] { new MsBuildArgument("/p:UseMonoRuntime=true") });


I am afraid that this might not be enough. I've failed to find any official documentation (this is sad), but according to https://twitter.com/lambdageek/status/1457784508371980291 we need to specify /p:UseMonoRuntime=true and publish a self-contained application for specific runtime.

Here is a small repro:

Console.WriteLine(Type.GetType("Mono.RuntimeStructs") != null);

PS D:\projects\repros\consoleBdn> dotnet publish -c Release -f net7.0 --self-contained -r win-x64 /p:UseMonoRuntime=true MSBuild version 17.4.0-preview-22428-01+14c24b2d3 for .NET Determining projects to restore... Restored D:\projects\repros\consoleBdn\consoleBdn.csproj (in 11 ms). C:\Program Files\dotnet\sdk\7.0.100-rc.1.22431.12\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.RuntimeIdentifierInference.targets(219,5): message NETSDK1057: You are using a preview version of .NET. See: https://aka.ms/dotnet-support-p olicy [D:\projects\repros\consoleBdn\consoleBdn.csproj] consoleBdn -> D:\projects\repros\consoleBdn\bin\Release\net7.0\win-x64\consoleBdn.dll consoleBdn -> D:\projects\repros\consoleBdn\bin\Release\net7.0\win-x64\publish\ PS D:\projects\repros\consoleBdn> D:\projects\repros\consoleBdn\bin\Release\net7.0\win-x64\publish\consoleBdn.exe True PS D:\projects\repros\consoleBdn> dotnet build -c Release -f net7.0 /p:UseMonoRuntime=true MSBuild version 17.4.0-preview-22428-01+14c24b2d3 for .NET Determining projects to restore... Restored D:\projects\repros\consoleBdn\consoleBdn.csproj (in 5 ms). C:\Program Files\dotnet\sdk\7.0.100-rc.1.22431.12\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.RuntimeIdentifierInference.targets(219,5): message NETSDK1057: You are using a preview version of .NET. See: https://aka.ms/dotnet-support-p olicy [D:\projects\repros\consoleBdn\consoleBdn.csproj] consoleBdn -> D:\projects\repros\consoleBdn\bin\Release\net7.0\consoleBdn.dll Build succeeded. 0 Warning(s) 0 Error(s) Time Elapsed 00:00:00.29 PS D:\projects\repros\consoleBdn> dotnet D:\projects\repros\consoleBdn\bin\Release\net7.0\consoleBdn.dll False

adamsitnik · 2022-10-11T20:13:35Z

src/BenchmarkDotNet/ConsoleArguments/ConfigParser.cs

+        {
+            return baseJob
+                .WithRuntime(runtime)
+                .WithToolchain(CsProjCoreToolchain.From(new NetCoreAppSettings(runtimeId, null, runtimeName, options.CliPath?.FullName, options.RestorePath?.FullName)));


CsProjCoreToolchain uses DotNetCliBuilder for building:

BenchmarkDotNet/src/BenchmarkDotNet/Toolchains/CsProj/CsProjCoreToolchain.cs

Line 38 in 1f5637c

new DotNetCliBuilder(settings.TargetFrameworkMoniker, settings.CustomDotNetCliPath),

which performs dotnet build to build the benchmark:

BenchmarkDotNet/src/BenchmarkDotNet/Toolchains/DotNetCli/DotNetCliBuilder.cs

Line 39 in 1f5637c

.RestoreThenBuild();

and then DotNetCliExecutor to run the executable:

BenchmarkDotNet/src/BenchmarkDotNet/Toolchains/CsProj/CsProjCoreToolchain.cs

Line 39 in 1f5637c

new DotNetCliExecutor(settings.CustomDotNetCliPath),

the executor basically performs dotnet $pathToLibrary.dll to run the benchmarks:

BenchmarkDotNet/src/BenchmarkDotNet/Toolchains/DotNetCli/DotNetCliExecutor.cs

Line 72 in 1f5637c

$"{executableName.EscapeCommandLine()} {benchmarkId.ToArguments(inputFromBenchmark.GetClientHandleAsString(), acknowledgments.GetClientHandleAsString())}",

You most likely need to define a new toolchain that consists of:

CsProjGenerator same way as CsProjCoreToolchain does:

BenchmarkDotNet/src/BenchmarkDotNet/Toolchains/CsProj/CsProjCoreToolchain.cs

Line 37 in 1f5637c

new CsProjGenerator(settings.TargetFrameworkMoniker, settings.CustomDotNetCliPath, settings.PackagesPath, settings.RuntimeFrameworkVersion),

DotNetCliPublisher with extraArguments set to -r $runtimeId:

BenchmarkDotNet/src/BenchmarkDotNet/Toolchains/DotNetCli/DotNetCliPublisher.cs

Line 11 in 1f5637c

public DotNetCliPublisher(string customDotNetCliPath = null, string extraArguments = null, IReadOnlyList<EnvironmentVariable> environmentVariables = null)

You can take a look at NatvieAOTToolchain to see how it provides the runtime id:

BenchmarkDotNet/src/BenchmarkDotNet/Toolchains/NativeAot/NativeAotToolchain.cs

Line 46 in 1f5637c

public static string GetExtraArguments(string runtimeIdentifier) => $"-r {runtimeIdentifier}";

Executor that runs provided .exe rather than dotnet $pathTo.dll: https://github.com/dotnet/BenchmarkDotNet/blob/1f5637c784ad9887a2d5abdba54d1337655281b1/src/BenchmarkDotNet/Toolchains/Executor.cs

The tricky part will be to make sure that ExecutablePath provided by CsProjGenerator is the one that points to the executable build by dotnet publish, not the dll build by dotnet build.

It's used here by the executor:

BenchmarkDotNet/src/BenchmarkDotNet/Toolchains/Executor.cs

Line 27 in 1f5637c

string exePath = executeParameters.BuildResult.ArtifactsPaths.ExecutablePath;

It comes from here:

BenchmarkDotNet/src/BenchmarkDotNet/Toolchains/GeneratorBase.cs

Line 114 in 1f5637c

protected virtual string GetExecutablePath(string binariesDirectoryPath, string programName) => Path.Combine(binariesDirectoryPath, $"{programName}{GetExecutableExtension()}");

BenchmarkDotNet/src/BenchmarkDotNet/Toolchains/CsProj/CsProjGenerator.cs

Line 52 in 1f5637c

=> Path.Combine(buildArtifactsDirectoryPath, "bin", configuration, TargetFrameworkMoniker);

You might need to introduce a new type that derives from CsProjGenerator and does this:

BenchmarkDotNet/src/BenchmarkDotNet/Toolchains/NativeAot/Generator.cs

Lines 66 to 67 in 1f5637c

protected override string GetBinariesDirectoryPath(string buildArtifactsDirectoryPath, string configuration)

=> Path.Combine(buildArtifactsDirectoryPath, "bin", configuration, TargetFrameworkMoniker, runtimeIdentifier, "publish");

Thanks for very well-detailed explanation. Everything is clear, just few notes you might want to comment on:

DotNetCliPublisher with extraArguments set to -r $runtimeId

I will do this because I see there is a way to obtain it automatically anyway (so that it is still user-friendly). But your small repro returns true with dotnet publish -c Release -f net6.0 --self-contained -r win-x64 /p:UseMonoRuntime=true as well as with dotnet publish -c Release -f net6.0 --self-contained /p:UseMonoRuntime=true on my local Windows 10.

Executor that runs provided .exe rather than dotnet $pathTo.dll:

Same thing here. Both .exe execution and dotnet $pathTo.dll works fine locally.
However, I am not sure what happens on Linux and Mac. I can check on Linux using Docker or WSL if you are interested in, otherwise I will just do what you suggested (just ignore these notes then).

dotnet publish -c Release -f net6.0 --self-contained /p:UseMonoRuntime=true

This is something new to me, I remember dotnet SDK always complaining about lack of runtime id when running --self-contained. But the produced exe is put to the runtime-specific folder, so we might need it anyway:

PS D:\projects\repros\consoleBdn> dotnet publish -c Release -f net7.0 --self-contained /p:UseMonoRuntime=true MSBuild version 17.4.0-preview-22428-01+14c24b2d3 for .NET Determining projects to restore... All projects are up-to-date for restore. C:\Program Files\dotnet\sdk\7.0.100-rc.1.22431.12\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.RuntimeIdentifierInference.targets(219,5): message NETSDK1057: You are using a preview version of .NET. See: https://aka.ms/dotnet-support-p olicy [D:\projects\repros\consoleBdn\consoleBdn.csproj] consoleBdn -> D:\projects\repros\consoleBdn\bin\Release\net7.0\win-x64\consoleBdn.dll consoleBdn -> D:\projects\repros\consoleBdn\bin\Release\net7.0\win-x64\publish\

However, I am not sure what happens on Linux and Mac

If you add a test similar to what I've described in #2142 (comment) and it works on your Windows machine it should work on Linux and Mac too and it's enough to just use CI to verify that.

Thank you @adamsitnik, this is done. Could you please take a look?

adamsitnik · 2022-10-11T20:14:03Z

src/BenchmarkDotNet/Environments/Runtimes/CoreRuntime.cs

@@ -19,6 +19,7 @@ public class CoreRuntime : Runtime
        public static readonly CoreRuntime Core50 = new CoreRuntime(RuntimeMoniker.Net50, "net5.0", ".NET 5.0");
        public static readonly CoreRuntime Core60 = new CoreRuntime(RuntimeMoniker.Net60, "net6.0", ".NET 6.0");
        public static readonly CoreRuntime Core70 = new CoreRuntime(RuntimeMoniker.Net70, "net7.0", ".NET 7.0");
+        public static readonly CoreRuntime Mono70 = new CoreRuntime(RuntimeMoniker.Mono70, "mono7.0", "Mono with .NET 7.0");


I agree, MonoRuntime would most likely be a better place.

adamsitnik · 2022-10-11T20:18:00Z

tests/BenchmarkDotNet.Tests/ConfigParserTests.cs

+            Assert.NotNull(toolchain);
+            Assert.Equal(actualRuntimeId, ((DotNetCliGenerator)toolchain.Generator).TargetFrameworkMoniker);
+        }
+


Please add tests similar to NativeAotTests where you ask to run a Mono .NET 6 benchmark (our CI uses .NET 6 SDK) and the benchmark just throws when it does not run on Mono. Like here where we do that for NativeAOT:

BenchmarkDotNet/tests/BenchmarkDotNet.IntegrationTests/NativeAotTests.cs

Lines 55 to 57 in 1f5637c

public void Check()

{

if (!RuntimeInformation.IsNativeAOT)

Serg046 · 2022-10-24T14:37:07Z

src/BenchmarkDotNet/Toolchains/CsProj/CsProjCoreToolchain.cs

@@ -24,7 +24,7 @@ public class CsProjCoreToolchain : Toolchain, IEquatable<CsProjCoreToolchain>
        [PublicAPI] public static readonly IToolchain NetCoreApp60 = From(NetCoreAppSettings.NetCoreApp60);
        [PublicAPI] public static readonly IToolchain NetCoreApp70 = From(NetCoreAppSettings.NetCoreApp70);

-        private CsProjCoreToolchain(string name, IGenerator generator, IBuilder builder, IExecutor executor, string customDotNetCliPath)
+        internal CsProjCoreToolchain(string name, IGenerator generator, IBuilder builder, IExecutor executor, string customDotNetCliPath)


I can keep it private but then I will have to inherit from Toolchain in MonoToolchain and copy/paste Validate method

@Serg046 making it internal was the right choice! 👍

Serg046 · 2022-10-24T14:37:45Z

src/BenchmarkDotNet/Toolchains/Mono/MonoGenerator.cs

+        protected override string GetRuntimeSettings(GcMode gcMode, IResolver resolver)
+        {
+            // Workaround for 'Found multiple publish output files with the same relative path' error
+            return base.GetRuntimeSettings(gcMode, resolver) + "<PropertyGroup><ErrorOnDuplicatePublishOutputFiles>false</ErrorOnDuplicatePublishOutputFiles></PropertyGroup>";


Same issue #2079

Serg046 · 2022-10-24T14:39:23Z

src/BenchmarkDotNet/Toolchains/Mono/MonoPublisher.cs

+                    buildPartition,
+                    EnvironmentVariables,
+                    buildPartition.Timeout)
+                .Publish().ToBuildResult(generateResult);


The thing is that --self-contained is not supported for restore/build operations that's why I introduce a new publisher and call publish only here.

Serg046 · 2022-10-24T14:40:36Z

src/BenchmarkDotNet/Toolchains/Mono/MonoToolchain.cs

+                        new MonoGenerator(settings.TargetFrameworkMoniker, settings.CustomDotNetCliPath, settings.PackagesPath, settings.RuntimeFrameworkVersion),
+                        new MonoPublisher(
+                            settings.CustomDotNetCliPath,
+                            $"--self-contained -r {runtimeIdentifier} /p:UseMonoRuntime=true /p:RuntimeIdentifiers={runtimeIdentifier}"),


I set RuntimeIdentifiers explicitly here because I had the issue describe here.

For that it would be great to add a comment to the code and provide the link to the issue (so in the future we don't remove it by accident).

I also wonder if this logic should be moved to MonoPublisher, as it's specific for this publisher and it won't ever be reused by other toolchains.

Serg046 · 2022-10-24T16:49:31Z

tests/BenchmarkDotNet.IntegrationTests/MonoTests.cs

+        {
+            var config = ManualConfig.CreateEmpty().AddJob(Job.Dry.WithRuntime(MonoRuntime.Mono60));
+            CanExecute<MonoBenchmark>(config);
+        }


Not sure if there is a need to add something like

if (ContinuousIntegration.IsAppVeyorOnWindows()) // too time consuming for AppVeyor (1h limit) return;

https://github.com/dotnet/BenchmarkDotNet/blob/master/tests/BenchmarkDotNet.IntegrationTests/NativeAotTests.cs#L24

If AppVeyor CI builds are passing, we don't need it, we can always add it in the future when it becomes a problem,

adamsitnik

It looks very, very good!

I have one last request: could you please fix the runtime name displayed for the "new" Mono:

The code can be found here:

BenchmarkDotNet/src/BenchmarkDotNet/Portability/RuntimeInformation.cs

Lines 164 to 166 in c02c3d8

    
           internal static string GetRuntimeVersion() 
        
           { 
        
               if (IsMono)

Thank you for your contribution!

adamsitnik · 2022-10-25T08:31:26Z

src/BenchmarkDotNet/ConsoleArguments/ConfigParser.cs

+        {
+            return baseJob
+                .WithRuntime(runtime)
+                .WithToolchain(MonoToolchain.From(new NetCoreAppSettings(runtime.MsBuildMoniker, null, runtime.Name, options.CliPath?.FullName, options.RestorePath?.FullName)));


nit: it would be nice to use named parameters so it's obvious that all strings are passed as right arguments (when they are multiple arguments of the same type it's easy to provide them in wrong order).

You could refactor following logic to a separate method:

BenchmarkDotNet/src/BenchmarkDotNet/ConsoleArguments/ConfigParser.cs

Lines 534 to 539 in c02c3d8

new NetCoreAppSettings(

targetFrameworkMoniker: RuntimeInformation.GetCurrentRuntime().MsBuildMoniker,

customDotNetCliPath: options.CliPath?.FullName,

runtimeFrameworkVersion: null,

name: RuntimeInformation.GetCurrentRuntime().Name,

packagesPath: options.RestorePath?.FullName)));

Done 14a256e

adamsitnik · 2022-10-25T08:34:02Z

src/BenchmarkDotNet/Toolchains/CsProj/CsProjCoreToolchain.cs

@@ -24,7 +24,7 @@ public class CsProjCoreToolchain : Toolchain, IEquatable<CsProjCoreToolchain>
        [PublicAPI] public static readonly IToolchain NetCoreApp60 = From(NetCoreAppSettings.NetCoreApp60);
        [PublicAPI] public static readonly IToolchain NetCoreApp70 = From(NetCoreAppSettings.NetCoreApp70);

-        private CsProjCoreToolchain(string name, IGenerator generator, IBuilder builder, IExecutor executor, string customDotNetCliPath)
+        internal CsProjCoreToolchain(string name, IGenerator generator, IBuilder builder, IExecutor executor, string customDotNetCliPath)


@Serg046 making it internal was the right choice! 👍

adamsitnik · 2022-10-25T08:35:35Z

src/BenchmarkDotNet/Toolchains/Mono/MonoToolchain.cs

+                        new MonoGenerator(settings.TargetFrameworkMoniker, settings.CustomDotNetCliPath, settings.PackagesPath, settings.RuntimeFrameworkVersion),
+                        new MonoPublisher(
+                            settings.CustomDotNetCliPath,
+                            $"--self-contained -r {runtimeIdentifier} /p:UseMonoRuntime=true /p:RuntimeIdentifiers={runtimeIdentifier}"),


For that it would be great to add a comment to the code and provide the link to the issue (so in the future we don't remove it by accident).

I also wonder if this logic should be moved to MonoPublisher, as it's specific for this publisher and it won't ever be reused by other toolchains.

src/BenchmarkDotNet/Toolchains/Mono/MonoGenerator.cs

src/BenchmarkDotNet/Environments/Runtimes/MonoRuntime.cs

adamsitnik · 2022-10-25T08:47:08Z

tests/BenchmarkDotNet.IntegrationTests/MonoTests.cs

+        {
+            var config = ManualConfig.CreateEmpty().AddJob(Job.Dry.WithRuntime(MonoRuntime.Mono60));
+            CanExecute<MonoBenchmark>(config);
+        }


If AppVeyor CI builds are passing, we don't need it, we can always add it in the future when it becomes a problem,

Co-authored-by: Adam Sitnik <[email protected]>

adamsitnik

Looks great to me @Serg046 ! Very impressive PR, thank you!

Serg046 added 2 commits October 7, 2022 02:54

Issue dotnet#2064: Add mono7.0

baa3cc5

Issue dotnet#2064: Add a preconfigured runtime instance

b7189e7

Serg046 commented Oct 7, 2022

View reviewed changes

timcassell reviewed Oct 7, 2022

View reviewed changes

adamsitnik reviewed Oct 11, 2022

View reviewed changes

Serg046 added 4 commits October 24, 2022 15:44

Add MonoToolchain

9940f9c

Merge from master

5e0877b

Correct ToolchainExtensions

8225989

Issue dotnet#2064: Update MonoJobAttribute to support mono60 and mono70

5d39e54

Serg046 commented Oct 24, 2022

View reviewed changes

adamsitnik reviewed Oct 25, 2022

View reviewed changes

Serg046 and others added 4 commits October 26, 2022 04:24

Issue dotnet#2064: Move some logic from the toolchain to the publisher

97dd80b

Update src/BenchmarkDotNet/Toolchains/Mono/MonoGenerator.cs

f47709c

Co-authored-by: Adam Sitnik <[email protected]>

Issue dotnet#2064: Fix the runtime name

14a256e

Update src/BenchmarkDotNet/Environments/Runtimes/MonoRuntime.cs

e8d95ae

Co-authored-by: Adam Sitnik <[email protected]>

adamsitnik added this to the v0.13.3 milestone Oct 26, 2022

adamsitnik added the Area:Toolchains label Oct 26, 2022

adamsitnik approved these changes Oct 26, 2022

View reviewed changes

adamsitnik merged commit 64c3a3c into dotnet:master Oct 26, 2022

adamsitnik mentioned this pull request Nov 18, 2022

[wasm] Perf pipeline (dotnet-runtime-perf) completely broken for main dotnet/runtime#78575

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Issue 2064: Mono70 moniker #2142

Issue 2064: Mono70 moniker #2142

Serg046 commented Oct 7, 2022 •

edited

Loading

Serg046 Oct 7, 2022

adamsitnik Oct 11, 2022

timcassell Oct 7, 2022

Serg046 Oct 7, 2022 •

edited

Loading

timcassell Oct 11, 2022

adamsitnik left a comment

adamsitnik Oct 11, 2022

adamsitnik Oct 11, 2022

adamsitnik Oct 11, 2022

Serg046 Oct 11, 2022

adamsitnik Oct 12, 2022

Serg046 Oct 24, 2022

adamsitnik Oct 11, 2022

adamsitnik Oct 11, 2022

Serg046 Oct 24, 2022

adamsitnik Oct 25, 2022

Serg046 Oct 24, 2022

Serg046 Oct 24, 2022

Serg046 Oct 24, 2022

adamsitnik Oct 25, 2022

Serg046 Oct 24, 2022

adamsitnik Oct 25, 2022

adamsitnik left a comment

adamsitnik Oct 25, 2022

Serg046 Oct 26, 2022

adamsitnik Oct 25, 2022

adamsitnik Oct 25, 2022

adamsitnik Oct 25, 2022

adamsitnik left a comment

	/// Mono with .net7.0
	/// .NET 7 using MonoVM (not CLR which is the default)

	protected override string GetBinariesDirectoryPath(string buildArtifactsDirectoryPath, string configuration)
	=> Path.Combine(buildArtifactsDirectoryPath, "bin", configuration, TargetFrameworkMoniker, runtimeIdentifier, "publish");

	new NetCoreAppSettings(
	targetFrameworkMoniker: RuntimeInformation.GetCurrentRuntime().MsBuildMoniker,
	customDotNetCliPath: options.CliPath?.FullName,
	runtimeFrameworkVersion: null,
	name: RuntimeInformation.GetCurrentRuntime().Name,
	packagesPath: options.RestorePath?.FullName)));

Issue 2064: Mono70 moniker #2142

Issue 2064: Mono70 moniker #2142

Conversation

Serg046 commented Oct 7, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Serg046 Oct 7, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

adamsitnik left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

adamsitnik left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

adamsitnik left a comment

Choose a reason for hiding this comment

Serg046 commented Oct 7, 2022 •

edited

Loading

Serg046 Oct 7, 2022 •

edited

Loading