Applicazione in produzione ha debug attivo su web.config

[d.termini]

Un cliente ci ha segnalato dei problemi di prestazioni avvenuti ultimamente, dovuti a quanto sembra al fatto che l'applicazione stia girando con debug c# attivo. (non il debug di InDe, ma quello su web.config)

Sostanzialmente questa parte (questa in 24.0)

Code: Select all

<?xml version="1.0"?>
<configuration>
  <system.web>
    <!--  DYNAMIC DEBUG COMPILATION
          Set compilation debug="true" to enable ASPX debugging.  Otherwise, setting this value to
          false will improve runtime performance of this application.
          Set compilation debug="true" to insert debugging symbols (.pdb information)
          into the compiled page. Because this creates a larger file that executes
          more slowly, you should set this value to true only when debugging and to
          false at all other times. For more information, refer to the documentation about
          debugging ASP.NET files.
    -->
    <compilation defaultLanguage="c#" debug="true" targetFramework="4.0">
    </compilation>


Che in 21.5 si arricchisce di altre linee

Code: Select all

<compilation defaultLanguage="c#" debug="true">
      <compilers>
      </compilers>
      <assemblies>
      </assemblies>
    </compilation>

Questo sembra causare un utilizzo di RAM e CPU fuori dal normale.
Ah questo debug è attivo su TUTTE le applicazioni in produzione, non solo quella col problema segnalato, ne abbiamo varie con diverse versioni da 21.0 a 24.0
E tutte sono pubblicate con "abilita debug" a false.

C'è qualcosa che posso fare per disattivare il debug? A parte una copia del web.config sulla custom che poi devo costantemente ricordarmi di mantenere allineata se cambio qualche endpoint

[g.lanzi]

La cosa mi interessa molto.
Allo stato attuale è necessario personalizzare il web.config contenuto nel template, ma voglio avviare un'attività per analizzare la cosa.
Ho aggiunto un'attività di verifica di questo aspetto da valutare nelle prossime versioni di Instant Developer Foundation.

[d.termini]

Grazie Giuseppe :)

[d.termini]

Se metto questo flag a false sul web.config nel template di InDe ha qualche effetto indesiderato durante lo sviluppo? Ho provato e il debug normale di InDe funziona, magari serve per la funzione di collegamento col debug passo-passo?

[Gionanni]

seguo

[Tony]

seguo

[d.pierangeli]

No, il debug di Inde è gestito direttamente dal codice sorgente.
Probabilmente nel caso di debug passo-passo invece serve questo parametro.

Però c'è una cosa che non mi torna e su cui internamente faremo delle verifiche, quell'istruzione ha impatto sulla compilazione dell'applicazione fatta da .net, ma in pubblicazione questo non succede perchè l'applicazione viene precompilata dall'IDE e viene mandata la dll a IDManager. Il comando di compilazione non è in debug, quindi non dovrebbero esserci particolari problemi di performance se si usa IDManager.

[d.termini]

Il problema è che quando c'è quel parametro a true su web.config sembra che l'applicazione su IIS parta in debug o si riconfigura in debug

Si intende questa opzione:

Screenshot 2025-02-14 095012.png (23.17 KiB) Viewed 304 times

Cosa faccia con questa configurazione non lo so, perché appunto dovrebbe essere usata solo quando ho i file .cs e non con le DLL, almeno per come la intendo io, ma stando al cliente sembra che abbia un grosso impatto su prestazioni e memoria utilizzata e se la disattiva manualmente funziona tutto meglio.
Teoricamente non dovrebbe esserci codice C# da compilare a runtime visto che l'applicazione è già compilata.

Purtroppo per questioni di conoscenza e di tempo (per sviluppare la conoscenza per farlo) non ho modo di indagare oltre, quindi se qualcuno è più ferrato e ci sa dire di più lo ringrazio.

[d.termini]

Se disattivo il debug, quando eseguo operazioni piuttosto grosse ottengo questo errore:

Code: Select all

Exception information:
    Exception type: NullReferenceException
    Exception message: Riferimento a un oggetto non impostato su un'istanza di oggetto.
   in IDHttpHandler.ProcessRequest(HttpContext context)
   in System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   in System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep step)
   in System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)


Col debug attivo il processo di IIS occupa quasi 500MB in più (837MB senza vs 1277 di picco con debug) ma non dà errore.
Sto provando sul pc locale quindi ci sono solo io...

[d.pierangeli]

Il registro degli eventi dà qualche informazione in più , magari il numero di riga?