Può capitare di dover creare più applicazioni web per sfruttare più autenticazioni o in generale avere più controllo sulla stessa. Per evitare di duplicare più volte un assembly la miglior soluzione sarebbe quella di usare la GAC. Se non fosse possibile la sezione assemblyBinding permette di specificare il percorso di un assembly:
<configuration> <runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="Ora" culture="" /> <codeBase version="1.0.0.0" href="file:///c:/Inetpub/wwwroot/prove/binding/Ora.dll"/> </dependentAssembly> </assemblyBinding> </runtime> AssemblyIdentity identifica l'assembly sul quale vogliamo agire. Accetta il culture (la lingua), name (il nome dell'assembly) e publicKeyToken (la chiave pubblica che permette di individuare l'assembly in modo veloce). Il tag codeBase indica dove è collocato l'assembly. L'attributo href può contenere anche un indirizzo internet, version invece identifica ulteriormente l'assembly per versione. Bisogna prestare attenzione all'utilizzo di questa funzione. Innanzitutto, la sezione runtime va inserita nella cartella principale dell'applicazione web e non in cartelle non dichiarate come applicazioni in IIS (il CLR non segnala alcun errore). Nel caso l'assembly non abbia uno strong name, dovrà essere collocato nella stessa directory dov'è presente il web.config o in sottocartelle (anche se configurate come applicazioni), per evitare che il CRL segnali un errore. Inoltre per far sì che il framework, quando elabora la nostra pagina, cerchi un assembly, è necessario referenziare lo stesso. Normalmente non c'è bisogno perché al primo avvio della nostra pagina, durante la compilazione automatica, gli assemblies da noi utilizzati vengono referenziati automaticamente, cercandoli nelle directory di probing. Quando utilizziamo il codeBase (codice in linea) questo non succede e perciò dobbiamo aggiungere la direttiva che segue alla nostra pagina: [code lang="aspx"]<%@ Assembly name="nomeassembly" %>
Questo problema non si verifica quando usiamo il codebehind e referenziamo la DLL in fase di compilazione.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Gestire dati sensibili nella configurazione in ASP.NET Core
Migliorare la scalabilità di ASP.NET Core 7 grazie all'output cache
Migrare un progetto ASP.NET Core da .NET 6 a .NET 7
Gestire tipi complessi in query string grazie a IParsable in ASP.NET Core 7.0
Taggare la output cache in base al routing in ASP.NET Core
Cache policy su route groups di Minimal API in ASP.NET Core 7
Effettuare il deploy di immagini solo da container registry approvati in Kubernetes
Usare ASP.NET Core dev tunnels per testare le applicazioni su internet
Sfruttare l'output cache di ASP.NET Core 7 con i controller
Raggruppare i parametri di una minimal API in un singolo oggetto in ASP.NET Core
Sfruttare la local cache del browser tramite gli ETag in ASP.NET Core
Sfruttare i tag nell'output cache di ASP.NET Core 7