39

What is the purpose of the 'runtimes' folder that gets published along with all my project files? I have a VS Online account, and have the build/deploy process configured through there. The 'runtimes' folder is certainly not a folder that exists in source control or my project folder.

'runtimes' folder contents:

'runtimes' folder contents

example contents:

example contents

Thanks,
Drew

ישו אוהב אותך
  • 28,609
  • 11
  • 78
  • 96
DrewE
  • 423
  • 1
  • 4
  • 5
  • Trying to figure this out myself - not having any luck finding information in the official documentation. – wh-dev Jan 20 '17 at 14:12

7 Answers7

15

Like @Gregory_Ott I was facing a similar issue where my deployment was an FDD deployment and the 'runtimes' folder was still being created. All I did was, mentioned the runtime and set the self-contained property to false. In the following example I have used dotnet to publish:

dotnet publish -c Release -o ..\publish --runtime win-x64 --self-contained false

The following link should help you with the deployment: https://learn.microsoft.com/en-us/dotnet/core/deploying/deploy-with-cli

Bridget
  • 183
  • 1
  • 7
8

These exist because you are building your application as a self contained application as opposed to one that is dependent upon the framework being installed on the machine executing it. Documentation can be found at https://learn.microsoft.com/en-us/dotnet/articles/core/deploying/ describing the various options that can be used to control this output.

Kyle Burns
  • 1,164
  • 7
  • 16
2

If portable target runtime is selected, runtime folder is created.

Mohammad Barbast
  • 1,753
  • 3
  • 17
  • 28
1

FWIW, I was facing this situation with a .NET 5 application. An empty "runtimes" project was there in the output directory. After wasting a few minutes I realized that the folder was a left-over from a previous build. I deleted bin/obj folders completely and published again and the "runtimes" folder is no longer there in the output. I didn't have to change anything in the project file or build options. Hope it saves someone else a few minutes too.

dotNET
  • 33,414
  • 24
  • 162
  • 251
1

Could this explain the existence of a runtimes folder in an FDD deployment:

A framework-dependent deployment with third-party dependencies is only as portable as its third-party dependencies. For example, if a third-party library only supports macOS, the app isn't portable to Windows systems. This happens if the third-party dependency itself depends on native code. A good example of this is Kestrel server, which requires a native dependency on libuv. When an FDD is created for an application with this kind of third-party dependency, the published output contains a folder for each Runtime Identifier (RID) that the native dependency supports (and that exists in its NuGet package).

Source: https://learn.microsoft.com/en-us/dotnet/core/deploying/deploy-with-vs?tabs=vs156#framework-dependent-deployment

Kathleen
  • 133
  • 1
  • 7
1

Setting your RuntimeIdentifier might be the solution. In my case, working with an Azure Function, it cut about 500 megs and reduced my archive down to 174 megs. This is important because on Consumption plans you get very limited storage.

<PropertyGroup>
  <TargetFramework>net6.0</TargetFramework>
  <LangVersion>preview</LangVersion>
  <AzureFunctionsVersion>v4</AzureFunctionsVersion>
  <OutputType>Exe</OutputType>

  <!-- 
  Prevents the runtimes folder from being created in publish, which contained 500 megs of runtime files we  don't need.
  -->
  <RuntimeIdentifier>win-x86</RuntimeIdentifier>    
  <PublishReadyToRun>true</PublishReadyToRun>
</PropertyGroup>
Brian MacKay
  • 31,133
  • 17
  • 86
  • 125
0

In the publish profile in Visual Studio, if Target runtime is set to 'Portable' then all possible runtimes are generated. This is the default, so the output can be reduced by a more selective choice if applicable:

enter image description here

RonnieScotland
  • 132
  • 2
  • 5