

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
```

# Riferimento allo schema del manifesto di distribuzione
<a name="dotnet-manifest-schema"></a>

Il manifesto di distribuzione è un file JSON che definisce in che modo Elastic Beanstalk deve distribuire e configurare le applicazioni Windows. Questa sezione fornisce un riferimento completo per tutte le proprietà e le opzioni di configurazione supportate nello schema del manifesto.

## Struttura del manifesto
<a name="dotnet-manifest-schema-structure"></a>

Il manifesto di distribuzione segue uno schema JSON specifico con la seguente struttura di primo livello:

**Example Struttura del manifesto di base**  

```
{
  "manifestVersion": 1,
  "skipIISReset": false,
  "iisConfig": {
    "websites": [...],
    "appPools": [...]
  },
  "deployments": {
    "msDeploy": [...],
    "aspNetCoreWeb": [...],
    "custom": [...]
  }
}
```

### Proprietà di primo livello
<a name="dotnet-manifest-schema-top-level"></a>

`manifestVersion`(richiesto)  
*Tipo*: numero  
*Impostazione predefinita*: 1  
*Valori validi:* 1  
Speciifica la versione dello schema del manifesto. Attualmente è supportata solo la versione 1.

`skipIISReset` (facoltativo)  
*Tipo*: Booleano  
*Di default:* false  
Controlla se IIS viene ripristinato durante le distribuzioni delle applicazioni. Questo flag influisce su entrambi i tipi `msDeploy` di `aspNetCoreWeb` distribuzione.  
*Comportamento:*  
+ *Non specificato o `false` (impostazione predefinita):* le reimpostazioni di IIS vengono eseguite durante le operazioni di installazione, disinstallazione e aggiornamento. Questo è il comportamento tradizionale.
+ *`true`:* le reimpostazioni IIS vengono ignorate durante le operazioni di distribuzione.
*Vantaggi:*  
+ Tempi di *inattività ridotti*: le applicazioni subiscono interruzioni del servizio più brevi durante le implementazioni.
+ *Implementazioni più rapide*: elimina il tempo necessario a IIS per riavviare e reinizializzare completamente IIS.
Durante l'utilizzo`skipIISReset`, l'[RestartAppServer](https://docs.aws.amazon.com/elasticbeanstalk/latest/api/API_RestartAppServer.html)operazione esegue un ripristino di IIS indipendentemente dall'impostazione di questa bandiera.
*Esempio*:  

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

`deployments`(obbligatorio)  
*Tipo:* oggetto  
Contiene le configurazioni di distribuzione per le tue applicazioni. Questo oggetto può includere `msDeploy` e `aspNetCoreWeb` tipi di `custom` distribuzione.

`iisConfig` (facoltativo)  
*Tipo:* oggetto  
Definisce le impostazioni di configurazione IIS da applicare prima di distribuire le applicazioni. Supporta la configurazione del sito Web e del pool di applicazioni.

## Configurazione IIS
<a name="dotnet-manifest-schema-iis-config"></a>

La `iisConfig` sezione consente di configurare le impostazioni IIS prima di distribuire le applicazioni. Ciò include la configurazione di pool di applicazioni con configurazioni specifiche e la configurazione di siti Web IIS con associazioni personalizzate.

### Siti Web IIS
<a name="dotnet-manifest-schema-websites"></a>

I siti Web IIS consentono di configurare impostazioni personalizzate dei siti Web, inclusi percorsi fisici e collegamenti di rete, prima di distribuire le applicazioni.

**Considerazioni importanti per la creazione di diversi siti Web IIS**  
*Ordine di configurazione dei siti Web:* i siti Web vengono configurati in sequenza nell'ordine in cui appaiono nell'`websites`array. La piattaforma elabora ogni configurazione del sito Web in sequenza, quindi assicurati un ordine corretto in caso di dipendenze tra i siti Web.
*Firewall e accesso alle porte:* solo la porta 80 viene esposta automaticamente tramite la configurazione firewall Windows Elastic Beanstalk predefinita. Se si configurano siti Web per utilizzare porte non standard, è necessario definire regole firewall personalizzate tramite ebextensions o script di distribuzione personalizzati per consentire l'accesso esterno a queste porte.

**Example Configurazione del sito Web**  

```
{
  "iisConfig": {
    "websites": [
      {
        "name": "MyCustomSite",
        "physicalPath": "C:\inetpub\wwwroot\mysite",
        "bindings": [
          {
            "protocol": "http",
            "port": 8080,
            "hostName": "mysite.local"
          },
          {
            "protocol": "https",
            "port": 8443
          }
        ]
      }
    ]
  }
}
```Proprietà del sito Web

`name`(richiesto)  
▬*Tipo:* stringa  
Il nome del sito Web IIS. Questo nome viene utilizzato per identificare il sito Web in IIS Manager e deve essere univoco all'interno della configurazione IIS.

`physicalPath`(richiesto)  
▬*Tipo:* stringa  
Il percorso fisico sul server in cui sono archiviati i file del sito Web. Questo percorso deve essere accessibile al processo di lavoro IIS.

`bindings`(obbligatorio)  
*Tipo*: matrice  
*Numero minimo di articoli:* 1  
Una serie di configurazioni vincolanti che definiscono il modo in cui il sito Web risponde alle richieste di rete. Ogni associazione specifica un protocollo, una porta e un nome host opzionale.

#### Associazioni a siti Web
<a name="dotnet-manifest-schema-bindings"></a>

Le associazioni ai siti Web definiscono gli endpoint di rete in cui il sito Web IIS ascolterà le richieste in arrivo.

`protocol`(richiesto)  
▬*Tipo:* stringa  
*Valori validi:* «http», «https»  
Il protocollo utilizzato per l'associazione.

`port`(richiesto)  
*Tipo*: integer  
*Intervallo valido: 1-65535*  
Il numero di porta su cui il sito Web ascolterà le richieste.

`hostName` (facoltativo)  
▬*Tipo:* stringa  
Il nome host (nome di dominio) per l'associazione.

### Pool di applicazioni
<a name="dotnet-manifest-schema-app-pools"></a>

I pool di applicazioni forniscono l'isolamento tra le applicazioni e consentono di configurare le impostazioni di runtime per gruppi di applicazioni.

**Example Configurazione del pool di applicazioni**  

```
{
  "iisConfig": {
    "appPools": [
      {
        "name": "MyAppPool",
        "enable32Bit": false,
        "managedPipelineMode": "Integrated",
        "managedRuntimeVersion": "v4.0",
        "queueLength": 1000,
        "cpu": {
          "limitPercentage": 80,
          "limitAction": "Throttle",
          "limitMonitoringInterval": 5
        },
        "recycling": {
          "regularTimeInterval": 1440,
          "requestLimit": 10000,
          "memory": 1048576,
          "privateMemory": 524288
        }
      }
    ]
  }
}
```Proprietà del pool di applicazioni

`name`(richiesto)  
▬*Tipo:* stringa  
Il nome del pool di applicazioni. Questo nome viene utilizzato per fare riferimento al pool nelle configurazioni di distribuzione.

`enable32Bit` (facoltativo)  
*Tipo*: Booleano  
Consente l'esecuzione di un'applicazione a 32 bit su una versione a 64 bit di Windows. Impostato su `true` per le applicazioni legacy che richiedono la compatibilità a 32 bit.

`managedPipelineMode` (facoltativo)  
▬*Tipo:* stringa  
*Valori validi:* «Integrato», «Classico»  
Speciifica la modalità di elaborazione delle richieste per il pool di applicazioni.

`managedRuntimeVersion` (facoltativo)  
▬*Tipo:* stringa  
*Valori validi:* «No Managed Code», «v2.0", «v4.0"  
Speciifica la versione.NET Framework per il pool di applicazioni.

`queueLength` (facoltativo)  
*Tipo*: integer  
Numero massimo di richieste che HTTP.sys mette in coda per il pool di applicazioni prima di rifiutare richieste aggiuntive.

#### Configurazione della CPU
<a name="dotnet-manifest-schema-cpu-config"></a>

L'`cpu`oggetto configura i limiti di utilizzo della CPU e il monitoraggio per il pool di applicazioni.

`limitPercentage` (facoltativo)  
*Tipo*: numero  
Percentuale massima di tempo di CPU che i processi di lavoro nel pool di applicazioni possono consumare.

`limitAction` (facoltativo)  
▬*Tipo:* stringa  
*Valori validi:* "NoAction«, «killW3WP», «Throttle», "» ThrottleUnderLoad  
Azione da intraprendere quando viene raggiunto il limite della CPU.

`limitMonitoringInterval` (facoltativo)  
*Tipo*: numero  
Periodo di ripristino (in minuti) per il monitoraggio della CPU e i limiti di limitazione.

#### Configurazione del riciclaggio
<a name="dotnet-manifest-schema-recycling-config"></a>

L'`recycling`oggetto configura quando e come i processi di lavoro del pool di applicazioni vengono riciclati.

`regularTimeInterval` (facoltativo)  
*Tipo*: integer  
Intervallo di tempo (in minuti) dopo il quale il pool di applicazioni viene riciclato. Impostare su 0 per disabilitare il riciclo basato sul tempo.

`requestLimit` (facoltativo)  
*Tipo*: integer  
Numero massimo di richieste elaborate dal pool di applicazioni prima del riciclaggio.

`memory` (facoltativo)  
*Tipo*: integer  
Quantità di memoria virtuale (in kilobyte) che attiva il riciclaggio dei processi di lavoro.

`privateMemory` (facoltativo)  
*Tipo*: integer  
Quantità di memoria privata (in kilobyte) che attiva il riciclaggio dei processi di lavoro.

## Tipi di implementazione
<a name="dotnet-manifest-schema-deployments"></a>

L'`deployments`oggetto contiene matrici di configurazioni di distribuzione per diversi tipi di applicazioni. Ogni tipo di distribuzione ha proprietà e casi d'uso specifici.

### MSDeploy distribuzioni
<a name="dotnet-manifest-schema-msdeploy"></a>

MSDeploy le distribuzioni vengono utilizzate per le tradizionali applicazioni.NET Framework che possono essere distribuite utilizzando Web Deploy (). MSDeploy

**Example MSDeploy configurazione di distribuzione**  

```
{
  "deployments": {
    "msDeploy": [
      {
        "name": "WebApp",
        "description": "Main web application",
        "parameters": {
          "appBundle": "webapp.zip",
          "iisPath": "/",
          "appPool": "DefaultAppPool"
        }
      }
    ]
  }
}
```MSDeploy proprietà di distribuzione

`name`(richiesto)  
▬*Tipo:* stringa  
Nome univoco per la distribuzione. Questo nome deve essere univoco in tutte le distribuzioni del manifesto.

`description` (facoltativo)  
▬*Tipo:* stringa  
Descrizione della distribuzione in formato leggibile dall'uomo.

`parameters`(richiesto)  
*Tipo:* oggetto  
Parametri di configurazione per l' MSDeploy operazione.

`scripts` (facoltativo)  
*Tipo:* oggetto  
PowerShell script da eseguire in varie fasi del ciclo di vita dell'implementazione.

#### MSDeploy parametri
<a name="dotnet-manifest-schema-msdeploy-parameters"></a>

`appBundle`(richiesto)  
▬*Tipo:* stringa  
Percorso del pacchetto dell'applicazione (file ZIP) relativo al file manifest. Questo pacchetto contiene i file dell'applicazione da distribuire.

`iisWebSite` (facoltativo)  
▬*Tipo:* stringa  
*Predefinito:* «Sito Web predefinito»  
Il sito Web IIS su cui distribuire l'applicazione. Per impostazione predefinita, le applicazioni vengono distribuite nel «Sito Web predefinito». Facoltativamente, è possibile specificare un nome di sito Web diverso, ad esempio quello configurato nella `iisConfig.websites` sezione.

`iisPath` (facoltativo)  
▬*Tipo:* stringa  
*Predefinito:* «/»  
Percorso della directory virtuale in IIS in cui verrà distribuita l'applicazione. Usa «/» per il percorso principale o «/api» per una sottodirectory.

`appPool` (facoltativo)  
▬*Tipo:* stringa  
Nome del pool di applicazioni per eseguire questa applicazione.

### Distribuzioni ASP.NET Core
<a name="dotnet-manifest-schema-aspnetcore"></a>

Le distribuzioni ASP.NET Core sono progettate specificamente per le applicazioni.NET Core e.NET 5\$1.

**Example Configurazione della distribuzione di ASP.NET Core**  

```
{
  "deployments": {
    "aspNetCoreWeb": [
      {
        "name": "CoreAPI",
        "description": "ASP.NET Core Web API",
        "parameters": {
          "appBundle": "coreapi.zip",
          "iisPath": "/api",
          "appPool": "CoreAppPool"
        }
      }
    ]
  }
}
```

Le distribuzioni ASP.NET Core utilizzano la stessa struttura di proprietà delle MSDeploy distribuzioni, con la differenza fondamentale nell'ambiente di runtime e nel modello di hosting utilizzati per l'applicazione.Parametri di distribuzione di ASP.NET Core

`appBundle`(richiesto)  
▬*Tipo:* stringa  
Percorso del bundle dell'applicazione relativo al file manifest. Può trattarsi di un archivio ZIP o di un percorso di directory contenente l'applicazione ASP.NET Core pubblicata.

`iisWebSite` (facoltativo)  
▬*Tipo:* stringa  
*Predefinito:* «Sito Web predefinito»  
Il sito Web IIS su cui distribuire l'applicazione ASP.NET Core. Per impostazione predefinita, le applicazioni vengono distribuite nel «Sito Web predefinito». Facoltativamente, è possibile specificare un nome di sito Web diverso, ad esempio quello configurato nella `iisConfig.websites` sezione.

`iisPath` (facoltativo)  
▬*Tipo:* stringa  
*Predefinito:* «/»  
Percorso della directory virtuale in IIS per l'applicazione ASP.NET Core.

`appPool` (facoltativo)  
▬*Tipo:* stringa  
Pool di applicazioni per l'applicazione ASP.NET Core. Il pool verrà configurato in modo appropriato per l'hosting ASP.NET Core.

### Distribuzioni personalizzate
<a name="dotnet-manifest-schema-custom"></a>

Le distribuzioni personalizzate forniscono il controllo completo sul processo di distribuzione tramite script. PowerShell Questo tipo di distribuzione è utile per scenari complessi che richiedono installazione, configurazione o logica di distribuzione personalizzate.

**Example Configurazione di distribuzione personalizzata**  

```
{
  "deployments": {
    "custom": [
      {
        "name": "CustomService",
        "description": "Custom Windows service deployment",
        "architecture": 32,
        "scripts": {
          "install": {
            "file": "install-service.ps1"
          },
          "restart": {
            "file": "restart-service.ps1"
          },
          "uninstall": {
            "file": "uninstall-service.ps1",
            "ignoreErrors": true
          }
        }
      }
    ]
  }
}
```Proprietà di distribuzione personalizzate

`name`(obbligatorio)  
▬*Tipo:* stringa  
Nome univoco per la distribuzione personalizzata.

`description` (facoltativo)  
▬*Tipo:* stringa  
Descrizione della distribuzione personalizzata.

`architecture` (facoltativo)  
*Tipo*: integer  
Valore *predefinito:* 32  
*Valori validi:* 32, 64  
Le specifiche di architettura per la modalità di esecuzione degli script PowerShell

`scripts`(richiesto)  
*Tipo:* oggetto  
PowerShell script che definiscono il comportamento di distribuzione. Le distribuzioni personalizzate supportano tipi di script aggiuntivi rispetto ad altri tipi di distribuzione.

## Script di distribuzione
<a name="dotnet-manifest-schema-scripts"></a>

Gli script di distribuzione sono PowerShell script che vengono eseguiti in momenti specifici durante il ciclo di vita della distribuzione. Diversi tipi di distribuzione supportano diversi set di eventi di script.

### Eventi di script
<a name="dotnet-manifest-schema-script-events"></a>

I seguenti eventi di script sono disponibili a seconda del tipo di distribuzione:Script di distribuzione standard (MSDeploy e Web) aspNetCore

`preInstall`  
Viene eseguito prima dell'installazione o dell'aggiornamento dell'applicazione.

`postInstall`  
Viene eseguito dopo l'installazione o l'aggiornamento dell'applicazione.

`preRestart`  
Viene eseguito prima del riavvio dell'applicazione.

`postRestart`  
Viene eseguito dopo il riavvio dell'applicazione.

`preUninstall`  
Viene eseguito prima della disinstallazione dell'applicazione.

`postUninstall`  
Viene eseguito dopo la disinstallazione dell'applicazione.Script di distribuzione personalizzati (solo distribuzioni personalizzate)

`install`  
Script di installazione principale per distribuzioni personalizzate. Questo script è responsabile dell'installazione dell'applicazione o del servizio.

`restart`  
Script per riavviare l'applicazione o il servizio. Chiamato al riavvio dell'ambiente.

`uninstall`  
Script per disinstallare l'applicazione o il servizio. Chiamato durante la chiusura dell'ambiente o la rimozione dell'applicazione.

### Proprietà dello script
<a name="dotnet-manifest-schema-script-properties"></a>

Ogni script è definito come un oggetto con le seguenti proprietà:

`file`(obbligatorio)  
▬*Tipo:* stringa  
Percorso del file di PowerShell script relativo al file manifest. Lo script deve avere un'`.ps1`estensione.

`ignoreErrors` (facoltativo)  
*Tipo*: Booleano  
*Di default:* false  
Se impostato su`true`, la distribuzione continua anche se lo script fallisce. Utilizzalo per script o operazioni di pulizia non critici.

**Example Esempio di configurazione dello script**  

```
{
  "scripts": {
    "preInstall": {
      "file": "backup-config.ps1",
      "ignoreErrors": true
    },
    "postInstall": {
      "file": "configure-app.ps1"
    }
  }
}
```