dotnet run

Questo articolo si applica a: ✔️ .NET 6 SDK e versioni successive

Nome

dotnet run: esegue il codice sorgente senza comandi espliciti di compilazione o avvio.

Riepilogo

dotnet run [<applicationArguments>]
  [-a|--arch <ARCHITECTURE>] [--artifacts-path <ARTIFACTS_DIR>]
  [-c|--configuration <CONFIGURATION>] [--disable-build-servers]
  [-e|--environment <KEY=VALUE>] [--file <FILE_PATH>]
  [-f|--framework <FRAMEWORK>] [--force] [--interactive]
  [-lp|--launch-profile <NAME>] [--no-build] [--no-cache]
  [--no-dependencies] [--no-launch-profile] [--no-restore] [--os <OS>]
  [-p|--property:<PROPERTYNAME>=<VALUE>]
  [--project <PATH>] [-r|--runtime <RUNTIME_IDENTIFIER>]
  [--sc|--self-contained] [--tl:[auto|on|off]] [-v|--verbosity <LEVEL>]
  [[--] [application arguments]]

dotnet run -h|--help

Descrizione

Il comando dotnet run offre un modo pratico per eseguire l'applicazione dal codice sorgente con un solo comando. Questo comando è utile per lo sviluppo iterativo veloce dalla riga di comando. Il comando dipende dal comando dotnet build per compilare il codice. Tutti i requisiti per la compilazione si applicano anche a dotnet run .

I file di output vengono scritti nel percorso predefinito, ovvero bin/<configuration>/<target>. Se ad esempio si ha un'applicazione netcoreapp2.1 e si esegue dotnet run, l'output viene inserito in bin/Debug/netcoreapp2.1. I file vengono sovrascritti in base alle esigenze. I file temporanei vengono inseriti nella directory obj.

Se il progetto specifica più framework, l'esecuzione di dotnet run genera un errore a meno che non venga usata l'opzione -f|--framework <FRAMEWORK> per specificare il framework.

Il comando dotnet run viene usato nel contesto dei progetti e non di assembly di compilazione. Se in alternativa si prova a eseguire la DLL di un'applicazione dipendente da framework, è necessario usare dotnet senza un comando. Ad esempio, per eseguire myapp.dll, usare:

dotnet myapp.dll

Per altre informazioni sul driver dotnet, vedere .NET cli overview.

Per eseguire l'applicazione, il comando dotnet run risolve le dipendenze dell'applicazione esterne al runtime condiviso dalla cache NuGet. È consigliabile non per usare dotnet run per eseguire le applicazioni nell'ambiente di produzione perché questo comando usa dipendenze memorizzate nella cache. In alternativa, creare una distribuzione usando il comando dotnet publish e distribuire l'output pubblicato.

Ripristino implicito

Non è necessario eseguire dotnet restore perché viene eseguito in modo implicito da tutti i comandi che richiedono un ripristino, ad esempio dotnet new, dotnet build, dotnet run, dotnet test, dotnet publish e dotnet pack. Per disabilitare il ripristino implicito, usare l'opzione --no-restore.

Il comando dotnet restore è ancora utile in alcuni scenari in cui il ripristino esplicito ha senso, ad esempio compilazioni di integrazione non significative in Azure DevOps Services o nei sistemi di compilazione che devono controllare in modo esplicito quando si verifica il ripristino.

Per informazioni su come gestire i feed NuGet, vedere la dotnet restore documentazione.

Questo comando supporta le opzioni dotnet restore passate nel formato continuo (ad esempio, --source). Le opzioni in formato breve, come -s, non sono supportate.

Download del manifesto del carico di lavoro

Quando si esegue questo comando, avvia un download in background asincrono dei manifesti pubblicitari per i carichi di lavoro. Se il download è ancora in esecuzione al termine di questo comando, il download viene arrestato. Per altre informazioni, vedere Manifesti pubblicitari.

Profili di avvio

I profili di avvio configurano l'avvio dotnet run di un'app durante lo sviluppo. Per un progetto in stile SDK, inserire le impostazioni in Properties/launchSettings.json. Visual Basic i progetti usano My Project/launchSettings.json invece .

Le app basate su file possono usare un [ApplicationName].run.json file accanto al file di origine. Per l'ordine di ricerca dei file ed esempi, vedere Avviare i profili per le app basate su file.

Il file delle impostazioni di avvio contiene un oggetto di primo livello profiles . Ogni proprietà in profiles definisce un profilo denominato:

{
  "profiles": {
    "Local": {
      "commandName": "Project",
      "commandLineArgs": "--input sample.txt",
      "dotnetRunMessages": true,
      "environmentVariables": {
        "APP_MODE": "local"
      }
    }
  }
}

Il parser delle impostazioni di avvio di .NET SDK accetta commenti JSON e virgole finali.

Selezionare un profilo

Usare --launch-profile <NAME> per selezionare un profilo denominato. La corrispondenza del nome non fa distinzione tra maiuscole e minuscole. I nomi dei profili che differiscono solo per caso sono ambigui e generano un errore.

Se non si specifica un nome, dotnet run selezionare il primo profilo in ordine di file il cui commandName supporto. Usare --no-launch-profile per ignorare il file delle impostazioni di avvio.

Quando dotnet run si applica un profilo, imposta DOTNET_LAUNCH_PROFILE il nome del profilo selezionato nel processo avviato. Un'origine variabile di ambiente successiva può eseguire l'override del valore.

Tipi di profilo supportati

L'SDK di .NET supporta questi commandName valori per dotnet run. I valori fanno distinzione tra maiuscole e minuscole.

`commandName`	Behavior
`Project`	Compila il progetto e avvia il comando prodotto dal progetto.
`Executable`	Avvia il comando specificato da `executablePath`. A meno che non si specifichi `--no-build`, `dotnet run` compila prima il progetto.

Proprietà comuni

dotnet run riconosce queste proprietà per entrambi i tipi di profilo supportati:

dotnet run espande i %NAME% riferimenti alle variabili di ambiente nei valori stringa supportati. In .NET 11 e versioni successive espande anche i riferimenti alle proprietà MSBuild nei valori usati per avviare il processo, usando lo stesso token sostitutivo di Visual Studio. Non espande i riferimenti in stile $NAME shell.

Proprietà	Behavior
`commandLineArgs`	Specifica gli argomenti per il processo avviato. Gli argomenti dell'applicazione espliciti nella riga di comando hanno la precedenza. Per un `Project` profilo, anche gli argomenti forniti dal project hanno la precedenza.
`environmentVariables`	Specifica le variabili di ambiente per il processo avviato. I valori del profilo eseguono l'override delle variabili di ambiente ereditate e generate dall'SDK e `-e\\|--environment` i valori sostituiscono i valori del profilo.
`dotnetRunMessages`	Quando `true`, stampa prima `dotnet run` della compilazione `Building...` del progetto. Il valore predefinito è `false`. Questa proprietà non controlla il messaggio che identifica il file delle impostazioni di avvio.

Usare environmentVariables per applicare le impostazioni di configurazione del runtime in fase di sviluppo con un formato variabile di ambiente. Ad esempio, un profilo può impostare le impostazioni GC, DOTNET_gcServerad esempio . Per le impostazioni disponibili, i nomi delle variabili di ambiente e le regole di precedenza, vedere .NET impostazioni di configurazione del runtime e opzioni di configurazione del runtime per Garbage Collection.

Non tutte le impostazioni di runtime hanno un formato variabile di ambiente. Per configurare un'app indipendentemente dal profilo di avvio, usare una proprietà o RuntimeHostConfigurationOption un elemento MSBuild nel progetto oppure usare un runtimeconfig.template.json file. Alcune impostazioni possono anche essere modificate nel codice con AppContext.SetSwitch. Questi meccanismi producono o modificano la configurazione di runtime dell'app; non sono proprietà aggiuntive launchSettings.json .

Proprietà di `Project`

dotnet run riconosce queste proprietà aggiuntive quando commandName è Project:

Proprietà	Behavior
`applicationUrl`	Imposta `ASPNETCORE_URLS` nel processo avviato. Un `ASPNETCORE_URLS` valore in `environmentVariables` o da `-e\\|--environment` ha la precedenza.
`launchBrowser`	Indica agli strumenti di avvio se aprire un browser. `dotnet run` mantiene questa proprietà nel profilo analizzato, ma non apre un browser.
`launchUrl`	Indica agli strumenti di avvio l'URL da aprire. `dotnet run` mantiene questa proprietà nel profilo analizzato, ma non apre un browser o usa l'URL.

Il applicationUrl comportamento supporta ASP.NET Core, ma i profili di avvio e le altre proprietà comuni si applicano a qualsiasi progetto di .NET in stile SDK eseguibile.

Proprietà di `Executable`

dotnet run riconosce queste proprietà aggiuntive quando commandName è Executable:

Proprietà	Behavior
`executablePath`	Required. Specifica il processo da avviare. L'SDK espande i riferimenti alle variabili supportate, ma non risolve un valore relativo rispetto al file delle impostazioni di avvio. Usare un percorso assoluto o un comando che il sistema operativo può individuare.
`workingDirectory`	Optional. Specifica la directory di lavoro per il processo avviato. L'SDK espande i riferimenti alle variabili supportate e risolve un percorso relativo nella directory contenente il file delle impostazioni di avvio. Se si omette la proprietà , per impostazione predefinita la directory di lavoro contiene il progetto o l'app basata su file.

estensioni Visual Studio e debugger

launchSettings.json è un formato di input condiviso, ma ogni consumer decide quali valori supportare e come interpretarli. Visual Studio, debugger e altri strumenti possono riconoscere più commandName valori e proprietà di dotnet run.

La tabella seguente confronta il dotnet run contratto con il comportamento comune .NET del sistema di progetto in Visual Studio:

Impostazione o comportamento	`dotnet run`	Visual Studio
Tipi di profilo supportati	Supporta `Project` e `Executable`.	Supporta `Project`, `Executable`e un oggetto vuoto `commandName`. Le estensioni di project-system installate possono aggiungere altri tipi di profilo.
Espansione variabile	Espande i `%NAME%` riferimenti alle variabili di ambiente. In .NET 11 e versioni successive espande anche i riferimenti alle proprietà MSBuild nei valori usati per avviare il processo.	Espande le variabili di ambiente e le proprietà di MSBuild in `executablePath`, `commandLineArgsworkingDirectory`, `launchUrl`, , valori delle variabili di ambiente e impostazioni di estensione con valori di stringa.
`commandLineArgs` per `Project`	Usa il valore del profilo solo quando il progetto non fornisce argomenti di esecuzione e non si passano argomenti dell'applicazione nella riga di comando.	Aggiunge il valore del profilo agli argomenti di esecuzione del progetto.
`workingDirectory` per `Project`	Ignora la proprietà .	Supporta la proprietà . Un percorso relativo è relativo alla directory del progetto.
`workingDirectory` per `Executable`	Un percorso relativo è relativo alla directory che contiene il file delle impostazioni di avvio. Se omesso, il percorso viene impostato per impostazione predefinita sulla directory del progetto o dell'app basata su file.	Un percorso relativo è relativo alla directory del progetto. Se omesso, il percorso viene impostato per impostazione predefinita sulla directory di output quando tale directory esiste o sulla directory del progetto in caso contrario.
Relativo `executablePath`	Passa il valore al sistema operativo senza ribasarlo.	Risolve un valore con i componenti del percorso dalla directory di lavoro del profilo. Per un nome eseguibile bare, Visual Studio controlla la propria directory corrente e quindi `PATH`.
`launchBrowser` e `launchUrl`	Mantiene i valori nel profilo analizzato, ma non apre un browser.	Rende disponibili i valori per un provider di avvio. Ad esempio, ASP.NET Core strumenti può aprire un browser.
`applicationUrl`	Imposta `ASPNETCORE_URLS`.	Rende disponibile il valore per i provider di avvio installati, ad esempio gli strumenti ASP.NET Core.
`dotnetRunMessages`	Controlla il `Building...` messaggio.	Non usa la proprietà per controllare Visual Studio output.
Proprietà del debugger	Ignora le proprietà specifiche del debugger.	Usa proprietà come `nativeDebugging`, `jsWebView2DebuggingsqlDebugging`, , `remoteDebugEnabled`e `hotReloadEnabled` quando il progetto e il debugger supportano la funzionalità.

In .NET 11 e versioni successive entrambi i consumer espandono "$(ProjectDir)". Nelle versioni precedenti, nessun valore singolo workingDirectory identifica la directory del progetto per entrambi i consumer. Visual Studio espande "$(ProjectDir)", mentre dotnet run lo considera come testo letterale e risolve i percorsi relativi dalla directory che contiene il file delle impostazioni di avvio. Pertanto, usare ".." per dotnet run con un file o My Project/launchSettings.json convenzionaleProperties/launchSettings.json. Visual Studio risolve lo stesso valore nell'elemento padre della directory del progetto.

Windows Forms e macchine virtuali Windows app non aggiungono un altro dotnet run tipo di profilo. Usare un Project profilo con impostazioni comuni, ad commandLineArgs esempio e environmentVariables. In Visual Studio, questi tipi di progetto desktop possono anche usare proprietà del debugger applicabili, ad esempio nativeDebugging per il debug gestito e nativo misto o jsWebView2Debugging per WebView2. Le proprietà del browser e dell'URL hanno effetto solo quando un provider di avvio o l'applicazione li utilizza.

Altri tipi di progetto e carichi di lavoro Visual Studio possono installare provider di avvio che aggiungono tipi di profilo o interpretano proprietà aggiuntive. Queste estensioni non aggiungono supporto a dotnet run: l'interfaccia della riga di comando ignora i tipi di profilo non supportati durante la selezione predefinita e segnala un errore quando si seleziona uno in modo esplicito.

Per le impostazioni del debugger supportate di Visual Studio e l'interfaccia utente di project, vedere impostazioni Project per una configurazione di debug C# .NET.

Arguments

<applicationArguments>

Argomenti passati all'applicazione in esecuzione.

Tutti gli argomenti non riconosciuti da dotnet run vengono passati all'applicazione. Per separare gli argomenti per dotnet run dagli argomenti per l'applicazione, usare l'opzione -- .

Inoltrare argomenti all'applicazione

dotnet run inoltra qualsiasi token che non riconosce all'applicazione. I token inoltrati mantengono l'ordine originale, ma dotnet run prima di tutto rimuove le opzioni che riconosce. Quando viene visualizzata un'opzione riconosciuta tra un nome di opzione non riconosciuto e il relativo valore, la rimozione dell'opzione riconosciuta può modificare il significato dei token di sinistra.

Ad esempio, il comando seguente interleaves l'opzione --project riconosciuta tra i token che l'applicazione deve ricevere:

dotnet run --app-flag --app-name --project ConsoleApp.csproj A.txt

Dopo dotnet run aver utilizzato --project ConsoleApp.csproj, l'applicazione riceve --app-flag --app-name A.txt. L'applicazione considera A.txt quindi il valore di , che non corrisponde alla riga di --app-namecomando originale.

Per evitare questa ambiguità, inserire gli argomenti dell'applicazione dopo un valore letterale --:

dotnet run --project ConsoleApp.csproj -- --app-flag --app-name A.txt

Il -- separatore contrassegna ogni token seguente come argomento dell'applicazione, quindi dotnet run non li riordina o li reinterpreta. Il separatore esegue anche script a prova di futuro rispetto a nuove dotnet run opzioni che potrebbero successivamente corrispondere a un token inoltrato in precedenza all'applicazione.

Annotazioni

Lo stesso comportamento si applica a dotnet build e a dotnet test in Microsoft. Modalità Testing.Platform (MTP), che inoltra i token non riconosciuti rispettivamente a MSBuild o all'applicazione di test. Per altre informazioni su dotnet test, vedere Inoltrare gli argomenti all'applicazione di test.

Opzioni

--

Delimita gli argomenti a dotnet run dagli argomenti per l'applicazione in esecuzione. Tutti gli argomenti dopo questo delimitatore vengono passati all'applicazione in esecuzione.
-a|--arch <ARCHITECTURE>

Specifica l'architettura di destinazione. Si tratta di una sintassi abbreviata per l'impostazione dell'identificatore di runtime (RID), in cui il valore fornito viene combinato con il RID predefinito. Ad esempio, in un computer win-x64, specificando --arch x86 si imposta il RID su win-x86. Se si usa questa opzione, non usare l'opzione -r|--runtime. Disponibile a partire da .NET 6 Preview 7.
--artifacts-path <ARTIFACTS_DIR>

Tutti i file di output di compilazione del comando eseguito verranno inseriti nelle sottocartelle nel percorso specificato, separati dal progetto. Per altre informazioni, vedere layout di output artefatti. Questa opzione e il valore fornito devono essere a catena in modo esplicito in qualsiasi dotnet comando che dipende dall'output di un altro dotnet comando, ad esempio quando si usano dotnet build --no-restore e dotnet publish --no-build. Disponibile a partire da .NET 8 SDK.
-c|--configuration <CONFIGURATION>

Definisce la configurazione di compilazione. Il valore predefinito per la maggior parte dei progetti è Debug, ma è possibile eseguire l'override delle impostazioni di configurazione della compilazione nel progetto.
--disable-build-servers

Forza il comando a ignorare tutti i server di compilazione permanenti. Questa opzione consente di disabilitare in modo coerente l'uso della memorizzazione nella cache di compilazione, che forza una compilazione da zero. Una compilazione che non si basa sulle cache è utile quando le cache potrebbero essere danneggiate o errate per qualche motivo. Disponibile a partire da .NET 7 SDK.
-e|--environment <KEY=VALUE>

Imposta la variabile di ambiente specificata nel processo che verrà eseguita dal comando . La variabile di ambiente specificata non viene applicata al dotnet run processo.

Le variabili di ambiente passate tramite questa opzione hanno la precedenza sulle variabili di ambiente, sulle direttive System.CommandLine env e environmentVariables dal profilo di avvio scelto. Per altre informazioni, vedere Variabili di ambiente.

Questa opzione è stata aggiunta in .NET SDK 9.0.200.
-f|--framework <FRAMEWORK>

Compila ed esegue l'app usando il framework specificato. Il framework deve essere specificato nel file di progetto.
--file <FILE_PATH>

Percorso dell'app basata su file da eseguire. Se non viene specificato un percorso, la directory corrente viene usata per trovare ed eseguire il file. Per altre informazioni sulle app basate su file, vedere Creare app C# basate su file.

In Unix eseguire le app basate su file direttamente usando il nome file aggiungendo una direttiva shebang (#!) e impostando l'autorizzazione di esecuzione. Per altre informazioni, vedere Supporto di Unix shebang (#!).

Introdotto in .NET SDK 10.0.100.
--force

Forza la risoluzione di tutte le dipendenze, anche se l'ultimo ripristino ha avuto esito positivo. La specifica di questo flag equivale all'eliminazione del file project.assets.json.
--interactive

Consente al comando di arrestarsi e attendere l'input o l'azione dell'utente, ad esempio il completamento dell'autenticazione.
-lp|--launch-profile <NAME>

Nome del profilo di avvio da usare durante l'avvio dell'applicazione. Per altre informazioni, vedere Profili di avvio.
--no-build

Non compila il progetto prima dell'esecuzione. Imposta anche in modo implicito il flag --no-restore.
--no-cache

Ignorare i controlli aggiornati e compilare sempre il programma prima dell'esecuzione.
--no-dependencies

Durante il ripristino di un progetto con riferimenti da progetto a progetto, ripristina il progetto radice e non i riferimenti.
--no-launch-profile

Non tenta di usare launchSettings.json per configurare l'applicazione.
--no-restore

Non esegue un ripristino implicito quando si esegue il comando.
--no-self-contained

Pubblicare l'applicazione come applicazione dipendente dal framework. Per eseguire l'applicazione, è necessario installare un runtime di .NET compatibile nel computer di destinazione.
--os <OS>

Specifica il sistema operativo di destinazione. Si tratta di una sintassi abbreviata per l'impostazione dell'identificatore di runtime (RID), in cui il valore fornito viene combinato con il RID predefinito. Ad esempio, in un computer win-x64, specificando --os linux si imposta il RID su linux-x64. Se si usa questa opzione, non usare l'opzione -r|--runtime. Disponibile dal .NET 6.
--project <PATH>

Specifica il percorso del file di progetto da eseguire: nome della cartella o percorso completo. Se non specificato, per impostazione predefinita il percorso corrisponde alla directory corrente.

L'abbreviazione -p per --project è deprecata a partire da .NET 6 SDK. Per un periodo di tempo limitato, -p può comunque essere usato per --project nonostante l'avviso di deprecazione. Se l'argomento fornito per l'opzione non contiene =, il comando accetta -p come breve per --project. In caso contrario, il comando presuppone che -p sia breve per --property. Questo uso flessibile di -p per --project verrà eliminato gradualmente in .NET 7.
--property:<NAME>=<VALUE>

Imposta una o più proprietà di MSBuild. Specificare più proprietà delimitate da punti e virgola o ripetendo l'opzione:
```
--property:<NAME1>=<VALUE1>;<NAME2>=<VALUE2>
--property:<NAME1>=<VALUE1> --property:<NAME2>=<VALUE2>
```
Il formato -p breve può essere usato per --property. Se l'argomento fornito per l'opzione contiene =, -p viene accettato come breve per --property. In caso contrario, il comando presuppone che -p sia breve per --project.

Per passare --property all'applicazione anziché impostare una proprietà MSBuild, fornire l'opzione dopo il separatore di sintassi --, ad esempio:
```
dotnet run -- --property name=value
```
-r|--runtime <RUNTIME_IDENTIFIER>

Specifica il runtime di destinazione per cui ripristinare i pacchetti. Per un elenco degli identificatori di runtime (RID, Runtime Identifier), vedere il catalogo RID.
--sc|--self-contained

Pubblicare il runtime di .NET con l'applicazione in modo che il runtime non debba essere installato nel computer di destinazione.
--tl:[auto|on|off]

Specifica se il Logger terminale deve essere usato per l'output di compilazione. Il valore predefinito è auto, che prima di abilitare la registrazione del terminale verifica l'ambiente. Prima di abilitare il nuovo logger, il controllo dell'ambiente verifica che il terminale sia in grado di usare le funzionalità di output moderne e che non utilizzi un output standard reindirizzato. on ignora il controllo dell'ambiente e abilita la registrazione del terminale. off ignora il controllo dell'ambiente e usa il logger di console predefinito.

Terminale Logger mostra la fase di ripristino seguita dalla fase di compilazione. Durante ogni fase, i progetti che sono in corso di compilazione vengono visualizzati nella parte inferiore del terminale. Ogni progetto che compila restituisce sia la destinazione MSBuild attualmente in fase di compilazione che la quantità di tempo impiegato per tale destinazione. È possibile cercare queste informazioni per altre informazioni sulla compilazione. Al termine della compilazione di un progetto, viene scritta una singola sezione "compilazione completata" che acquisisce:
- Il nome del progetto compilato.
- Il framework di destinazione (se sono presenti più destinazioni).
- Lo stato della compilazione.
- L'output primario di tale compilazione (con collegamento ipertestuale).
- Qualsiasi diagnostica generata per il progetto.
Questa opzione è disponibile a partire da .NET 8.
-v|--verbosity <LEVEL>

Imposta il livello di dettaglio del comando. I valori consentiti sono q[uiet], m[inimal], n[ormal], d[etailed] e diag[nostic]. Il valore predefinito è minimal. Per ulteriori informazioni, vedere LoggerVerbosity.
-?|-h|--help

Stampa una descrizione di come usare il comando.

Variabili di ambiente

Le origini seguenti applicano le variabili di ambiente all'applicazione avviata:

Variabili di ambiente del sistema operativo quando viene eseguito il comando.
Direttive System.CommandLine env , ad esempio [env:key=value]. Questi si applicano all'intero dotnet run processo, non solo al progetto eseguito da dotnet run.
Valori generati dal profilo di avvio scelto. dotnet run imposta DOTNET_LAUNCH_PROFILEe applicationUrl in un Project profilo imposta ASPNETCORE_URLS.
environmentVariables dal profilo di avvio scelto, se presente. Questi si applicano al progetto in esecuzione da dotnet run.
-e|--environment valori delle opzioni dell'interfaccia della riga di comando (aggiunti in .NET SDK versione 9.0.200). Questi si applicano al progetto in esecuzione da dotnet run.

L'ambiente viene costruito nello stesso ordine di questo elenco, quindi l'opzione -e|--environment ha la precedenza più alta.

Esempi

Eseguire il progetto nella directory corrente:
```
dotnet run
```
Eseguire l'app basata su file specificata nella directory corrente:
```
dotnet run --file ConsoleApp.cs
```
Il supporto delle app basate su file è stato aggiunto in .NET SDK 10.0.100.

Eseguire il progetto specificato:

dotnet run --project ./projects/proj1/proj1.csproj

Eseguire il progetto nella directory corrente, specificando la configurazione della versione:
```
dotnet run --property:Configuration=Release
```
Eseguire il progetto nella directory corrente. L'argomento --help in questo esempio viene passato all'applicazione perché viene usata l'opzione -- vuota:
```
dotnet run --configuration Release -- --help
```
Ripristinare dipendenze e strumenti per il progetto nella directory corrente visualizzando solo output minimo e quindi eseguire il progetto:
```
dotnet run --verbosity m
```
Eseguire il progetto nella directory corrente usando il framework specificato e passare argomenti all'applicazione:
```
dotnet run -f net6.0 -- arg1 arg2
```
Nell'esempio seguente vengono passati tre argomenti all'applicazione. Un argomento viene passato usando -e due argomenti vengono passati dopo --:
```
dotnet run -f net6.0 -arg1 -- arg2 arg3
```

Commenti e suggerimenti

Questa pagina è stata utile?

Last updated on 2026-09-08