sdk: Net5.0 RC2: When building a solution with a target runtime ID an error is given

Interestingly enough a dotnet test MySolution.sln -c Release -r win-x64 works fine without any error. It also builds the whole solution with the specified runtime before executing all unit tests. How is that different from dotnet build MySolution.sln -c Release -r win-x64??? 😕

Both should be possible.

Here is another workaround which may be better than creating publish profiles for each project. Create a Directory.Build.props file in the root of your repo with the following contents:

<Project>
  <PropertyGroup>
    <RuntimeIdentifier>$(MyRuntimeIdentifier)</RuntimeIdentifier>
  </PropertyGroup>
</Project>

Then when you build or publish, specify the RuntimeIdentifier with the MyRuntimeIdentifier property instead of the --runtime parameter. For example:

dotnet build MySolution.sln -p:MyRuntimeIdentifier=linux-x64

This is especially confusing because dotnet build --help still lists this as an available option.

  -r, --runtime <RUNTIME_IDENTIFIER>    The target runtime to build for.

Options should not be listed if they are no longer supported.

Like for the others, this change has completely trashed my CI pipelines. Building at project level is not always practical!

Well, this is unexpected. I’ve an AzD pipeline template that is used to build dozens of similar projects and it relies on the solution level actions + rid. E.g. (extra simplified):

dotnet restore -r RID
dotnet build -r RID
dotnet publish -r RID

The RID is passed via CI. The resulting artifacts are used to build docker images for different OS (glibc/musl based) in the subsequent pipeline steps.

It’s especially bad for complex solutions where individual projects depend on other projects, because these dependencies are defined in the solution so you need to manually configure the build to ensure each project is built in order

-Will

On Wed, Dec 23, 2020 at 6:24 AM Dennis notifications@github.com wrote:

so how can we build solution now for particular RID now? If I do not specify RID - it builds for default RID, and then publishing for specific RID fails. All I can do now is to build each single project one by one with RID specified - which sucks tbh

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/dotnet/sdk/issues/14281#issuecomment-750322316, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJUAUQFSUFWPXPSZLTXPTDSWH4SHANCNFSM4S3JMCUQ .

UPDATE: Removed the -c option as it is no longer needed. Microsoft finally fixed the bug requiring it.

Since @marcpopMSFT didn’t specify how to get this to work, here is how you do it:

1. Ensure that you have correctly setup your publish profiles for the executable, which includes the Global RuntimeIdentifier.
2. Use the dotnet command line below to build and publish.

dotnet build "YourSolution.sln" -p:DeployOnBuild=true -p:PublishProfile="<publish profile name>"

Example:

dotnet build "MySolution.sln" -p:DeployOnBuild=true -p:PublishProfile="Debug (linux-x64)"

Here is a sample publish profile for Debug (linux-x64).pubxml:

<?xml version="1.0" encoding="utf-8"?>
<!--
This file is used by the publish/package process of your project. You can customize the behavior of this process
by editing this MSBuild file. In order to learn more about this please visit https://go.microsoft.com/fwlink/?LinkID=208121.
-->
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <WebPublishMethod>FileSystem</WebPublishMethod>
    <PublishProvider>FileSystem</PublishProvider>
    <LastUsedBuildConfiguration>Debug-Publish</LastUsedBuildConfiguration>
    <LastUsedPlatform>x64</LastUsedPlatform>
    <PublishSingleFile>False</PublishSingleFile>
    <IncludeSymbolsInSingleFile>true</IncludeSymbolsInSingleFile>
    <SiteUrlToLaunchAfterPublish />
    <LaunchSiteAfterPublish>True</LaunchSiteAfterPublish>
    <ExcludeApp_Data>False</ExcludeApp_Data>
    <TargetFramework>net5.0</TargetFramework>
    <RuntimeIdentifier>linux-x64</RuntimeIdentifier>
    <ProjectGuid>FA65A960-E4C6-4695-8D3F-3F8BB3C7EEC0</ProjectGuid>
    <SelfContained>true</SelfContained>
    <_IsPortable>false</_IsPortable>
    <publishUrl>..\.publish\MySolution.debug.linux-x64\</publishUrl>
    <DeleteExistingFiles>True</DeleteExistingFiles>
    <PublishTrimmed>False</PublishTrimmed>
  </PropertyGroup>
</Project>

I don’t know why Microsoft didn’t provide this information, but they haven’t been very helpful as of late. I hope this helps everyone who has been affected by this issue, as it appears that Microsoft does not care.

This change cost of a week of productivity. The strange thing is we are using DotNet Core 3.1 installed via the pipeline. The latest SDK on the build VM is 2.1.518, so why would a DotNet 5.0 change affect us?

I’ve 2 workarounds for now:

1. Since we use Azure DevOps’ .NET Core CLI task in the templates, specifying projects as **/*.csproj works. Previously we had *.sln there. This is not exactly the same, since we lose the ability to control project builds via solution (e.g. devs could easily disable them there if needed), but it’s a start.
2. The error is generated in the SolutionFile/ImportAfter/Microsoft.NET.Sdk.Solution.targets. By specifying -p:ImportByWildcardBeforeSolution=false targets from there wouldn’t be imported and the solution level build with runtime identifier will work.
   Example: dotnet build --runtime linux-x64 -p:ImportByWildcardBeforeSolution=false
   Please note that this will disable the import of the other targets which might be needed. On my local machine I also have Microsoft.NuGet.ImportAfter.targets there. I’m not sure if it’s needed, my quick tests with build and pack commands work fine even if it’s not imported.

So how do we compile for e.g. both win10-x64 and linux-x64 in the same build process?

I have a solution with multiple projects to publish. In the past, I could specify the runtime once, and then publish all the projects with the --no-build flag:

dotnet build MySolution.sln --runtime linux-x64 dotnet publish MyProject1\MyProject1.csproj -no-build dotnet publish MyProject2\MyProject2.csproj -no-build

and it worked fine.

Now, if I pass the the runtime to the publish step, it fails:

dotnet build MySolution.sln dotnet publish MyProject1\MyProject1.csproj -no-build --runtime linux-x64 dotnet publish MyProject2\MyProject2.csproj -no-build --runtime linux-x64

because a bunch of files are missing:

C:\Program Files\dotnet\sdk\5.0.301\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Publish.targets(238,5): 
error MSB3030: Could not copy the file "obj\Release\netcoreapp3.1\linux-x64\MyProject1.pdb" because it was not found. [D:\MyProject1\MyProject1.csproj]

C:\Program Files\dotnet\sdk\5.0.301\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Publish.targets(238,5): 
error MSB3030: Could not copy the file "obj\Release\netcoreapp3.1\linux-x64\MyProject1.dll" because it was not found. [D:\MyProject1\MyProject1.csproj]

@marcpopMSFT this change is unacceptable, and actually violates the intent of the MSBuild changes. About 1.5 years ago, we spent 3 months working directly with the “dotnet” and “msbuild” teams to get our current build system working, as “dotnet” is parsing the command line, when it should not be. The original intent was for “dotnet” to pass the command line unchanged to “msbuild”, or with string manipulation ONLY! The “dotnet” command was never supposed to parse the command line for “msbuild” operations.

Because of this change, and the fact that you have not provided any work-arounds to allow automated builds to work, we are now dead in the water. Using Premier Support takes months to get a resolution, which you are forcing us to use. You have basically backed us into a corner again, with this change.

In Pull #828 it specifically states:

With this change, I think the intention is to have this flow, with two contexts for lib.csproj but only one build completed

for the image used in #863, which is what you have broken here.

can we have a comment from MS team if this issue is being considered for the future dotnet CLI releases at all?

It seems like there is still no realisation how royally this screwed up big solutions that should be built self-contained for multiple RIDs at once

If there is no plan to change current behaviour - we would need to create a separate dotnet CLI wrapper just to bypass this issue, which is ugly

so how can we build solution for particular RID now? If I do not specify RID - it builds for default RID, and then publishing for specific RID fails. All I can do now is to build each single project one by one with RID specified - which sucks tbh

I would love to have this back too. We pass in the desired architecture in our CI pipeline and build scripts because we have both windows and Linux machines.

Same question here. I need to compile a Solution for both Windows and Linux. How would I do that?

+1 on this issue from me, it’s quite annoying…

Same, CI has just failed after updating to sdk 5.0… Bit annoying to have to specify each project individually!

One alternative that’s relatively cheap would be to just change the error to a warning (with a modified message). Would that work for folks who were utilizing this behavior before? You can then suppress the warning if desired but wouldn’t be blocked.

I would really appreciate this!

We did recently add IsRidAgnostic but unfortunately, we were not able to enable it for solution files. We found that it was either going to greatly impact performance for solutions but essentially doing multiple builds or require a significant amount of logic.

Daniel’s workaround here is still the only solution at the moment: https://github.com/dotnet/sdk/issues/14281#issuecomment-876510589 We’ll take another look at our options in 8.0.1xx

@marcpopMSFT Just ran into this one where I want to build + run a debug server on WSL. CLI parameters should just override the configs and warn people if both are specified. I prefer not changing code I have to remember to change back.

Sorry for the slow reply on this as my notifications were not set up to see the replies here until the mention a couple weeks ago. I’ve synced with a couple of people offline about this.

Per the issue I originally mentioned (#863), when a library is included in a solution and referenced by another project in that solution AND you build the solution with a RID, we end up building the library twice. Once without the RID (as part of the referenced project build) and once with the RID (as part of the root solution build) to the same location. This can cause issues like build failures if there is a timing issue and the file is locked. This can also cause issues if the application has behavior chnages dependent on the RID. The issues that will arise when doing this won’t always happen since the primary issue is a race condition. It also won’t happen if every project already has RIDs specified in the project.

A long-term solution would be to put the IsRidAgnostic logic into the solution handling logic which would avoid the duplicate build. At the moment, it’s not high on our priority list to enable that but CCing @KathleenDollard and @richlander in case they have prioritization opinions.

One alternative that’s relatively cheap would be to just change the error to a warning (with a modified message). Would that work for folks who were utilizing this behavior before? You can then suppress the warning if desired but wouldn’t be blocked.

@Ben238 Building at project level is not always practical!

I’d say it’s highly impractical as soon as you’re slightly beyond the enthusiast level. I’ve been managing .NET CI for more then 10 years in several orgs and it’s always solution-level builds. This way you can have stuff like debug/demo projects included in the repo, but disabled in solution. This is convenient, since they don’t interfere with the day-to-day operations, but always within arm’s reach if you need them. Plus, I might be mistaken, but solution level-builds should be slightly faster, since MSBuild generates a metaproject from the solution and it means that dependency resolution builds a single graph. I wouldn’t mind a warning for theoretically unsupported scenarios, but blocking builds outright… meh.

@turowicz From what I can tell, it looks like buildx passes the platform as TARGETARCH, so you should be able to do something like this:

dotnet build MySolution -p:TargetArch=$TARGETARCH

<Project>
  <PropertyGroup Condition="'$(TargetArch)' == 'x86'">
    <RuntimeIdentifier>linux-x86</RuntimeIdentifier>
  </PropertyGroup>
  <!-- Note! Docker buildx uses amd64 instead of x64! -->
  <PropertyGroup Condition="'$(TargetArch)' == 'amd64'">
    <RuntimeIdentifier>linux-x64</RuntimeIdentifier>
  </PropertyGroup>
  <PropertyGroup Condition="'$(TargetArch)' == 'arm64'">
    <RuntimeIdentifier>linux-arm64</RuntimeIdentifier>
  </PropertyGroup>
</Project>