Solution-level error when a RuntimeIdentifier is specified

[rainersigwald]

Related to a subset of #696 that won't be fixed by #828.

If a solution build has a RID specified, it will fail.

This can be because (after #828) it double-builds a library (once with RID specified from the solution's global properties, once with it removed):

Or, if nothing is done, this will fail when attempting to specify a RID on a project that doesn't need one.

If VS and the CLI distributed a solution-extension target that ran before Build and errored when '$(RuntimeIdentifier)' != '', it would at least provide guiderails to nudge users back into the more supported scenarios. It could say something like Building a solution with a specific RuntimeIdentifier is not supported. If you would like to publish for a single RID, specifiy the RID at the individual project level instead.

[benmccallum]

I'm in a docker container and running into this. I'm specifically building a base image used by all our individual microservice images to speed things up. As such, restoring and building by pointing at the .sln file makes most sense. (It's not an exact science, but... that's Docker builds...)

My base image is doing:

# Restore NuGet packages, specifying the runtime we'll use
RUN dotnet restore Microservices.sln -r linux-musl-x64

# Copy across the rest of the source files
WORKDIR ..
COPY ./ ./

# Build entire sln
RUN dotnet build Microservices/Microservices.sln -c Release --no-restore -r linux-musl-x64

My services image is doing:

# Test
RUN dotnet test ../Tests/${SERVICE_NAME}.Tests/${SERVICE_NAME}.Tests.csproj -c Release --no-restore

# Publish
RUN dotnet publish -c Release --no-restore -o /dist -r linux-musl-x64

I'm not really sure what alternative I have. Any suggestions?

I guess I'll start by looking at a Build.Directory.props level setting, conditionally included for my microservice projects and the docker build and set this as the rid for the project.

[benmccallum]

Strange that this has been an issue since 2017 but it's never caused us pain until now where it's happening on TeamCity and local dev machines more often than not. here's my solution so I can still build a solution but specify the rid as/when needed.

Directory.Build.props

<Project>
  <PropertyGroup>
    <RuntimeIdentifier Condition="'$(MYCOMPANY_IS_DOCKER_BUILD)' == 'True' And $(MSBuildProjectName.EndsWith('Service'))">linux-musl-x64</RuntimeIdentifier>
  </PropertyGroup>
</Project>

where MYCOMPANY_IS_DOCKER_BUILD is an environment variable I'm setting in my docker container, and 'Service' is the suffix of my deployable microservice projects I want to conditionally apply the rid for.

Hope that helps someone in a similar situation.

Update: This didn't work, see my next comment...

[dsplaisted]

@sfoslund If you're looking for issues to tackle, this one is a candidate

[benmccallum]

@rainersigwald, one week on and this has re-surfaced, so I guess I'd never fixed it. #raceconditions. I'd removed all my uses of -r xyz on dotnet cmds and moved to conditionally specify them via a props file (see above), but its failed on a shared project (netstandard2.0) with an IO exception of file already in use on a .deps.json file.

How can I get the benefit of a restore and build "cache" in my base Docker image so that in my consumer Dockerfile I can just do a dotnet publish? Not really keen on looping over different project files to get that cache all built out...

I don't think I fully understand the problem here though either. If I've got a runtime id of linux-musl-x64 for my ASP.NET app, will a shared project targeting netstandard2.0 that is uses be compiled into two folders, netstandard2.0 and linux-musl-x64? Is the issue that I need to somehow be specifying that linux target across all my projects (the shared projects and not just the ASP.NET app project?) Or perhaps I need to also set the rid on the test projects so that it's not trying to build those projects for a different rid..

Any help would be greatly appreciated!