Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Esecuzione di più applicazioni e delle applicazioni ASP.NET Core con un manifest di distribuzione
<a name="dotnet-manifest"></a>

È possibile utilizzare un manifest di distribuzione per indicare a Elastic Beanstalk come distribuire l'applicazione. Utilizzando questo metodo, non è necessario utilizzare `MSDeploy` per generare un bundle di origine per una singola applicazione ASP.NET che viene eseguita nel percorso root del sito Web. Piuttosto, è possibile utilizzare un file manifest per eseguire più applicazioni in percorsi diversi. In alternativa, puoi chiedere a Elastic Beanstalk di distribuire ed eseguire l'app con ASP.NET Core. È inoltre possibile utilizzare un manifest di distribuzione per configurare un pool di applicazioni in cui eseguire le applicazioni.

I manifest di distribuzione aggiungono il supporto per [Applicazioni .NET Core](#dotnet-manifest-dotnetcore) su Elastic Beanstalk. È possibile distribuire un'applicazione .NET Framework senza un manifest di distribuzione. Tuttavia, le applicazioni .NET Core richiedono un manifest di distribuzione per essere eseguite su Elastic Beanstalk. Quando utilizzi un manifest di distribuzione, è necessario creare un archivio del sito per ogni applicazione e quindi raggruppare gli archivi del sito in un secondo archivio ZIP che contiene il manifest di distribuzione.

I manifest di distribuzione aggiungono anche la possibilità di [eseguire più applicazioni in diversi percorsi](#dotnet-manifest-multiapp). Un manifest di distribuzione definisce una gamma di obiettivi di distribuzione, ognuno con un archivio del sito e un percorso su cui IIS dovrebbe eseguirlo. Ad esempio, è possibile eseguire un'API Web nel percorso `/api` per servire richieste asincrone e un'app Web nel percorso root che utilizza l'API.

È possibile utilizzare un manifesto di distribuzione per [configurare i siti Web IIS con collegamenti e percorsi fisici personalizzati](#dotnet-manifest-websites). Ciò consente di configurare siti Web che ascoltano su porte o nomi host specifici prima di distribuire le applicazioni.

È inoltre possibile utilizzare un manifest di distribuzione per [eseguire più applicazioni utilizzando pool di applicazioni in IIS o Kestrel](#dotnet-manifest-apppool). È possibile configurare un pool di applicazioni per riavviare le proprie applicazioni periodicamente, eseguire applicazioni a 32 bit o utilizzare una versione specifica del runtime di .NET Framework.

Per una personalizzazione completa, puoi [scrivere i tuoi script di distribuzione](#dotnet-manifest-custom) in Windows PowerShell e indicare a Elastic Beanstalk quali script eseguire per installare, disinstallare e riavviare l'applicazione.

I manifest di distribuzione e le relative caratteristiche richiedono una piattaforma Windows Server [versione 1.2.0 o più recente](dotnet-v2migration.md).

[Per informazioni dettagliate su tutte le opzioni di configurazione, le proprietà e le funzionalità avanzate disponibili, come ignorare le reimpostazioni di IIS, consulta il riferimento allo schema del manifesto di distribuzione.](dotnet-manifest-schema.md)

**Topics**
+ [App .NET Core](#dotnet-manifest-dotnetcore)
+ [Esecuzione di più applicazioni](#dotnet-manifest-multiapp)
+ [Configurazione dei siti Web IIS](#dotnet-manifest-websites)
+ [Utilizzo dell'Application Request Routing (ARR)](#dotnet-manifest-arr)
+ [Configurazione dei pool delle applicazioni](#dotnet-manifest-apppool)
+ [Definizione delle distribuzioni personalizzate](#dotnet-manifest-custom)
+ [Riferimento allo schema del manifesto di distribuzione](dotnet-manifest-schema.md)

## App .NET Core
<a name="dotnet-manifest-dotnetcore"></a>

È possibile utilizzare un manifest di implementazione per eseguire applicazioni .NET Core su Elastic Beanstalk. .NET Core è una versione multipiattaforma di .NET fornita con uno strumento a riga di comando (`dotnet`). È possibile utilizzarlo per generare un'applicazione, eseguirla in locale e prepararla per la pubblicazione.

Per eseguire un'applicazione .NET Core su Elastic Beanstalk, esegui `dotnet publish` e raggruppa l'output in un archivio ZIP senza includere le directory. Posiziona l'archivio del sito in un bundle di origine con un manifest di distribuzione con una destinazione di distribuzione di tipo `aspNetCoreWeb`.

Il seguente manifest di distribuzione esegue un'applicazione .NET Core da un archivio del sito denominato `dotnet-core-app.zip` al percorso root.

**Example aws-windows-deployment-manifest.json - .NET core**  

```
{
  "manifestVersion": 1,
  "deployments": {
    "aspNetCoreWeb": [
      {
        "name": "my-dotnet-core-app",
        "parameters": {
          "archive": "dotnet-core-app.zip",
          "iisPath": "/"
        }
      }
    ]
  }
}
```

Raggruppa il manifest e l'archivio del sito in un archivio ZIP per creare un bundle di origine.

**Example dotnet-core-bundle.zip**  

```
.
|-- aws-windows-deployment-manifest.json
`-- dotnet-core-app.zip
```

L'archivio del sito contiene il codice compilato dell'applicazione, le dipendenze e il file `web.config`.

**Example dotnet-core-app.zip**  

```
.
|-- Microsoft.AspNetCore.Hosting.Abstractions.dll
|-- Microsoft.AspNetCore.Hosting.Server.Abstractions.dll
|-- Microsoft.AspNetCore.Hosting.dll
|-- Microsoft.AspNetCore.Http.Abstractions.dll
|-- Microsoft.AspNetCore.Http.Extensions.dll
|-- Microsoft.AspNetCore.Http.Features.dll
|-- Microsoft.AspNetCore.Http.dll
|-- Microsoft.AspNetCore.HttpOverrides.dll
|-- Microsoft.AspNetCore.Server.IISIntegration.dll
|-- Microsoft.AspNetCore.Server.Kestrel.dll
|-- Microsoft.AspNetCore.WebUtilities.dll
|-- Microsoft.Extensions.Configuration.Abstractions.dll
|-- Microsoft.Extensions.Configuration.EnvironmentVariables.dll
|-- Microsoft.Extensions.Configuration.dll
|-- Microsoft.Extensions.DependencyInjection.Abstractions.dll
|-- Microsoft.Extensions.DependencyInjection.dll
|-- Microsoft.Extensions.FileProviders.Abstractions.dll
|-- Microsoft.Extensions.FileProviders.Physical.dll
|-- Microsoft.Extensions.FileSystemGlobbing.dll
|-- Microsoft.Extensions.Logging.Abstractions.dll
|-- Microsoft.Extensions.Logging.dll
|-- Microsoft.Extensions.ObjectPool.dll
|-- Microsoft.Extensions.Options.dll
|-- Microsoft.Extensions.PlatformAbstractions.dll
|-- Microsoft.Extensions.Primitives.dll
|-- Microsoft.Net.Http.Headers.dll
|-- System.Diagnostics.Contracts.dll
|-- System.Net.WebSockets.dll
|-- System.Text.Encodings.Web.dll
|-- dotnet-core-app.deps.json
|-- dotnet-core-app.dll
|-- dotnet-core-app.pdb
|-- dotnet-core-app.runtimeconfig.json
`-- web.config
```

## Esecuzione di più applicazioni
<a name="dotnet-manifest-multiapp"></a>

È possibile eseguire più applicazioni con un manifest di distribuzione definendo più target di distribuzione.

Il seguente manifesto di distribuzione configura due applicazioni .NET Core. L'`WebApiSampleApp`applicazione implementa una semplice API web e serve richieste asincrone sul percorso. `/api` `DotNetSampleApp` è un'applicazione Web che fornisce richieste al percorso root.

**Example aws-windows-deployment-manifest.json: più app**  

```
{
  "manifestVersion": 1,
  "deployments": {
    "aspNetCoreWeb": [
      {
        "name": "WebAPISample",
        "parameters": {
          "appBundle": "WebApiSampleApp.zip",
          "iisPath": "/api"
        }
      },
      {
        "name": "DotNetSample",
        "parameters": {
          "appBundle": "DotNetSampleApp.zip",
          "iisPath": "/"
        }
      }
    ]
  }
}
```

Un'applicazione di esempio con più applicazioni è disponibile qui:
+ **[Pacchetto sorgente distribuibile - -v2.zip dotnet-multiapp-sample-bundle](samples/dotnet-multiapp-sample-bundle-v2.zip)**
+ **[Codice sorgente: -v2.zip dotnet-multiapp-sample-source](samples/dotnet-multiapp-sample-source-v2.zip)**

## Configurazione dei siti Web IIS
<a name="dotnet-manifest-websites"></a>

È possibile configurare i siti Web IIS con collegamenti e percorsi fisici personalizzati utilizzando il manifesto di distribuzione. Ciò è utile quando è necessario configurare siti Web che ascoltano su porte specifiche, utilizzano nomi host personalizzati o forniscono contenuti da directory specifiche.

Il seguente manifesto di distribuzione configura un sito Web IIS personalizzato che ascolta su HTTP con un numero di porta specifico e un percorso fisico personalizzato:

**Example aws-windows-deployment-manifest.json - configurazione del sito Web IIS**  

```
{
  "manifestVersion": 1,
  "iisConfig": {
    "websites": [
      {
        "name": "MyCustomSite",
        "physicalPath": "C:\inetpub\wwwroot\mysite",
        "bindings": [
          {
            "protocol": "http",
            "port": 8080,
            "hostName": "mysite.local"
          }
        ]
      }
    ]
  },
  "deployments": {
    "aspNetCoreWeb": [
      {
        "name": "my-dotnet-core-app",
        "parameters": {
          "appBundle": "dotnet-core-app.zip",
          "iisWebSite": "MyCustomSite",
          "iisPath": "/"
        }
      }
    ]
  }
}
```

In questo esempio:
+ Un sito Web denominato "MyCustomSite" viene creato con un percorso fisico personalizzato
+ Il sito Web ha un'associazione HTTP sulla porta 8080 con un nome host specifico
+ L'applicazione ASP.NET Core viene distribuita su questo sito Web personalizzato utilizzando il parametro `iisWebSite`

## Utilizzo dell'Application Request Routing (ARR)
<a name="dotnet-manifest-arr"></a>

I moduli Application Request Routing (ARR) e URL Rewrite sono preinstallati e disponibili in Elastic Beanstalk Windows. AMIs Questi moduli consentono scenari di routing avanzati e la manipolazione degli URL tramite la configurazione IIS utilizzando ebextensions o la configurazione dell'applicazione.

L'esempio seguente mostra un semplice manifesto di distribuzione che configura un sito Web con una porta personalizzata, combinato con una configurazione ebextensions che imposta il routing ARR di base:

**Example aws-windows-deployment-manifest.json: configurazione ARR semplice**  

```
{
  "manifestVersion": 1,
  "iisConfig": {
    "websites": [
      {
        "name": "ARRSite",
        "physicalPath": "C:\\inetpub\\wwwroot\\arrsite",
        "bindings": [
          {
            "protocol": "http",
            "port": 8080,
            "hostName": "localhost"
          }
        ]
      }
    ]
  },
  "deployments": {
    "aspNetCoreWeb": [
      {
        "name": "BackendApp",
        "parameters": {
          "appBundle": "backend-app.zip",
          "iisWebSite": "ARRSite",
          "iisPath": "/backend"
        }
      }
    ]
  }
}
```

La configurazione ARR viene eseguita tramite ebextensions. La seguente configurazione imposta le regole di routing ARR di base:

**Example .ebextensions/arr-config.config - Configurazione ARR di base**  

```
files:
  "C:\\temp\\configure-arr.ps1":
    content: |
      # Enable ARR proxy at server level
      Set-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Filter 'system.webServer/proxy' -Name 'enabled' -Value 'True'
      
      # Clear any existing global rules to avoid conflicts
      Clear-WebConfiguration -PSPath 'MACHINE/WEBROOT/APPHOST' -Filter 'system.webServer/rewrite/globalRules'

      # Add global rule to route all requests to backend
      Add-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' `
        -Filter 'system.webServer/rewrite/globalRules' `
        -Name '.' `
        -Value @{
          name = 'Route_to_Backend'
          stopProcessing = 'True'
          match = @{ url = '^(?!backend/)(.*)' }
          action = @{
            type = 'Rewrite'
            url = 'http://localhost:8080/backend/{R:1}'
          }
        }

container_commands:
  01_configure_arr:
    command: powershell -ExecutionPolicy Bypass -File "C:\\temp\\configure-arr.ps1"
    waitAfterCompletion: 0
```

Questa configurazione crea un sito Web sulla porta 8080 e configura ARR per indirizzare tutte le richieste in arrivo all'applicazione di backend in esecuzione su quel sito.

## Configurazione dei pool delle applicazioni
<a name="dotnet-manifest-apppool"></a>

È possibile supportare più applicazioni nell'ambiente Windows. Sono disponibili due approcci:
+ È possibile utilizzare il modello di out-of-process hosting con il server web Kestrel. Con questo modello, è possibile configurare più applicazioni per l'esecuzione in un unico pool di applicazioni.
+ È possibile utilizzare il modello di hosting in-process. Con questo modello, è possibile utilizzare più pool di applicazioni per eseguire più applicazioni con una sola applicazione in ogni pool. Se utilizzi il server IIS e desideri eseguire più applicazioni, devi utilizzare questo approccio.

Per configurare Kestrel ed eseguire più applicazioni in un pool di applicazioni, aggiungi `hostingModel="OutofProcess"` nel file `web.config`. Considera i seguenti esempi:

**Example web.config - per il modello di hosting Kestrel out-of-process**  

```
<configuration>
<location path="." inheritInChildApplications="false">
<system.webServer>
<handlers>
<add 
    name="aspNetCore" 
    path="*" verb="*" 
    modules="AspNetCoreModuleV2" 
    resourceType="Unspecified" />
</handlers>
<aspNetCore 
    processPath="dotnet" 
    arguments=".\CoreWebApp-5-0.dll" 
    stdoutLogEnabled="false" 
    stdoutLogFile=".\logs\stdout" 
    hostingModel="OutofProcess" />
</system.webServer>
</location>
</configuration>
```

**Example aws-windows-deployment-manifest.json: più applicazioni**  

```
{
"manifestVersion": 1,
  "deployments": {"msDeploy": [
      {"name": "Web-app1",
        "parameters": {"archive": "site1.zip",
          "iisPath": "/"
        }
      },
      {"name": "Web-app2",
        "parameters": {"archive": "site2.zip",
          "iisPath": "/app2"
        }
      }
    ]
  }
}
```

IIS non supporta più applicazioni in un pool di applicazioni perché utilizza il modello di hosting in-process. Pertanto, è necessario configurare più applicazioni assegnando ciascuna applicazione a un pool di applicazioni. In altre parole, assegnare una sola applicazione a un pool di applicazioni.

È possibile configurare IIS per utilizzare diversi pool di applicazioni nel file `aws-windows-deployment-manifest.json`. Apporta i seguenti aggiornamenti consultando il file di esempio successivo:
+ Aggiungi una sezione `iisConfig` che includa una sottosezione denominata `appPools`.
+ Nel blocco `appPools`, elenca i pool di applicazioni. 
+ Nella sezione `deployments`, definisci una sezione `parameters` per ogni applicazione.
+ Per ogni applicazione, la sezione `parameters` specifica un archivio, un percorso per eseguirla e un `appPool` in cui eseguirla.

Il seguente manifest di distribuzione consente di configurare due pool di applicazioni che riavviano l'applicazione ogni 10 minuti. Essi inoltre allegano le loro applicazioni a un'applicazione Web .NET Framework che viene eseguita nel percorso specificato.

**Example aws-windows-deployment-manifest.json: un'applicazione per pool di applicazioni**  

```
{
"manifestVersion": 1,
  "iisConfig": {"appPools": [
      {"name": "MyFirstPool",
       "recycling": {"regularTimeInterval": 10}
      },
      {"name": "MySecondPool",
       "recycling": {"regularTimeInterval": 10}
      }
     ]
    },
  "deployments": {"msDeploy": [
      {"name": "Web-app1",
        "parameters": {
           "archive": "site1.zip",
           "iisPath": "/",
           "appPool": "MyFirstPool"
           }
      },
      {"name": "Web-app2",
        "parameters": {
           "archive": "site2.zip",
           "iisPath": "/app2",
           "appPool": "MySecondPool"
          }
      }
     ]
    }
}
```

## Definizione delle distribuzioni personalizzate
<a name="dotnet-manifest-custom"></a>

Per un maggiore controllo, è possibile personalizzare completamente la distribuzione di un'applicazione definendo una *distribuzione personalizzata*.

Questo manifesto di distribuzione indica a Elastic Beanstalk PowerShell di eseguire gli script in modalità a 32 bit. [Specifica tre script: `install` uno script (`siteInstall.ps1`) che viene eseguito durante l'avvio e la distribuzione dell'istanza, uno `uninstall` script (`siteUninstall.ps1`) che viene eseguito prima di installare nuove versioni durante le distribuzioni e uno `restart` script (`siteRestart.ps1`) che viene eseguito quando si seleziona Riavvia App Server nella console di gestione.](environments-dashboard-actions.md) AWS 

**Example aws-windows-deployment-manifest.json: distribuzione personalizzata**  

```
{
  "manifestVersion": 1,
  "deployments": {
    "custom": [
      {
        "name": "Custom site",
        "architecture" : 32,
        "scripts": {
          "install": {
            "file": "siteInstall.ps1"
          },
          "restart": {
            "file": "siteRestart.ps1"
          },
          "uninstall": {
            "file": "siteUninstall.ps1"
          }
        }
      }
    ]
  }
}
```

Include eventuali artefatti necessari per eseguire l'applicazione nel bundle di origine con il manifest e gli script.

**Example C - .zip ustom-site-bundle**  

```
.
|-- aws-windows-deployment-manifest.json
|-- siteInstall.ps1
|-- siteRestart.ps1
|-- siteUninstall.ps1
`-- site-contents.zip
```