Però ora è possibile utilizzare e sviluppare appoggiandosi anche a .NET 4.0 Framework. E' chiaro che occorrerà in aggiunta al 3.5SP1 installare anche il framework 4.0 perchè quest'ultimo non include la versione 3.5.
Se la nostra applicazione richiede funzionalità presenti solo nel Framework 4.0, possiamo estendere i prodotti ESRI con componenti scritte nel Framework 4.0. In questo caso dovremo verificare nella distribuzione della nostra applicazione che il framework sia installato sul sistema di destinazione.
Per poter 'debuggare' il nostro add-in o il nostro componente personalizzato con ArcGIS Desktop, lo sviluppatore deve modificare lo specifico file di configurazione (ArcMap, ArcCatalog ecc.) sulla propria macchina per aggiungere il supporto per il runtime .NET 4.0, oppure in alternativa è possibile agganciare il processo attraverso Visual Studio.
Ad esempio, se uno sviluppatore crea un add-in con .NET 4.0 per ArcMap, per eseguire il debug dovrà modificare il file ArcMap.exe.config posizionato nella cartella bin di ArcGIS Desktop. Questa configurazione specifica i CLR che sono supportati con l'applicazione e redirige gli assembly per consentire ai componenti più vecchi di essere testati nella versione corrente di ArcGIS. Nel file di configurazione dell'applicazione dovresti vedere le seguenti informazioni XML:
<startup>
<!--<supportedRuntime version="v4.0.30319"/>-->
<supportedRuntime version="v2.0.50727"/>
</startup>
Per abilitare il debug occorre rimuovere il commento per l'elemento <supportedRuntime> della versione 4.0
Si sottolinea però il fatto che, poichè gli add-in .NET non richiedono un particolare setup per la distribuzione poichè possono essere installati semplicemente con un doppio click o utilizzando l'add-in Manager, non c'è modo di verificare che la macchina di destinazione abbia il .NET framework installato prima dell'installazione dell'add-in. Di conseguenza, se utilizziamo il framework 4.0, potenzialmente potremmo limitare l'utilizzo del nostro add-in ad alcuni utenti se non hanno installato il framework 4.0.
Se il nostro add-in utilizza il framework 3.5 non dobbiamo invece preoccuparci di nulla perchè il .NET 3.5 SP1 è, come detto, richiesto da ArcGIS for Desktop e ArcGIS Engine per Windows.
Le precedenti versioni del .NET Framework possono essere installate nella stessa macchina, ma solo una versione del framework può essere caricata in un processo. Questo causò problemi di compatibilità con soluzioni sviluppate utilizzando il più vecchio framework (Microsoft ovviò a questo creando i framework 3.0 e 3.5 ancora basati sul CLR della versione 2.0 e quindi mantenendo la retrocompatibilità con le applicazioni scritte per la versione 2.0).
Diversamente dalle precedenti versioni del .NET framework, una caratteristica del .NET Framework 4.0 consente di coesistere nello stesso processo con il .NET Framework 2.0 (In-Process Side-by-Side). Questo significa che un processo può utilizzare entrambe le versioni del framework contemporaneamente. Di conseguenza, componenti COM e codice gestito 3.5 Framework gireranno in Framework 3.5 consentendo di sfruttare le nuove funzionalità .NET Framemork 4.0 senza doversi preoccupare di problemi di compatibilità con la nuova versione del framework.
L'Embed Interop Types è una nuova caratteristica del .NET Framework 4.0 che consente di includere le informazione degli attributi che sono normalmente memorizzate nell'assembly di interoperabilità primario (PIA) nell'eseguibile o nella dll. Questo è stato fatto perchè la distribuzione di soluzioni gestite sviluppate su certe tecnologie basate su COM era difficoltosa poichè la distribuzione e la verifica del PIA erano anche fatte sulla macchina di destinazione.
Un Assembly di interoperabilità primario (PIA) contiene la descrizione ufficiale dei tipi come definiti dal pubblicatore dei tipi. Un assembly di interoperabilità primario è un assembly che contiene un insieme di classi wrapper firmato che consente di chiamare codice non gestito da codice gestito.
Un assembly di interoperabilità primario è un assembly univoco fornito dal produttore che contiene le definizioni di tipo dei tipi che sono implementati utilizzando il modello COM. In un assembly di interoperabilità primario sono contenute le definizioni dei tipi come metadati. Il pubblicatore di libreria di tipo COM deve firmare solo un assembly di interoperabilità primario con un nome sicuro. Un singolo PIA può disporre di più versioni della stessa libreria dei tipi.
Una libreria dei tipi COM che viene importata come un assembly e che è firmata da un pubblicatore diverso dal pubblicatore della libreria di tipi originale non può essere un assembly di interoperabilità primario. Solo il pubblicatore della libreria dei tipi può creare un assembly di interoperabilità primario che diventa l'unità di definizioni di tipo ufficiale per l'interoperabilità con i tipi COM sottostanti.
In modo predefinito, quando si aggiunge un PIA in un progetto Visual Studio .NET 4.0 senza utilizzare il plug-in Add ArcGIS Reference, la proprietà Embed Interop Types della PIA è impostata a true. La best practice è cambiare l'impostazione a false quando si distribuisce la personalizzazione di ArcGIS, perchè l'installer di ArcGIS imposta gli appropriati PIA e assembly nel sistema, pertanto non si dovrebbe includere nella propria soluzione.
Nella versione 10.1 ArcGIS for Server è un'applicazione nativa a 64bit mentre ArcGIS for Desktop e ArcGIS Engine rimangono a 32bit (x86). Di conseguenza, i PIA sono ripristinati al loro precedente stato MSIL (Microsoft Intermediate Language). Questo consente agli stessi assembly di essere usati in entrambi gli ambienti: 32bit per ArcGIS for Desktop e ArcGIS Engine e 64bit per ArcGIS for Server.
Post
Nessun commento:
Posta un commento