Qual è la differenza tra un applet .NET e un controllo ActiveX incorporato in IE

Question

Mi sono imbattuto in alcuni articoli sul web sulle applet .Net e mi chiedevo come differisse da un controllo activex (creato usando un linguaggio .Net)? (per chiarire, questo è per quanto riguarda le applet che girano all'interno di un browser web)

(La differenza: i controlli ActiveX scritti in un linguaggio .Net sono chiamati .Net Applet?)

Ci sono dei vantaggi nell'usare l'uno rispetto all'altro?

Inoltre, come si riferisce a questa tecnologia? (Una ricerca su MSDN non fa apparire nulla chiamato .Net Applets!)

ps: da quello che posso vedere i controlli ActiveX devono essere registrati COM, mentre le applet .Net non lo fanno. Inoltre, nella pagina Web, i controlli activeX sono referenziati usando il loro CLSID, mentre le applet .NET sembrano essere referenziate da un nome completo (percorso, nome dll, spazio dei nomi e classe)

Answer 1

I controlli ActiveX sono semplicemente oggetti COM che, come minimo, implementano IUnknown. Le versioni recenti di IE hanno iniziato a richiedere anche l'oggetto per implementare IObjectSafety. Per fare qualcosa di utile, l'oggetto deve implementare anche alcune altre interfacce Ole, come IDispatch, IOleObject, ecc. L'oggetto deve poter essere creato tramite CoCreateInstance (), il che significa che devi registrati in qualche modo con il registro. Non è necessario utilizzare un guid nel tag, è anche possibile utilizzare AppId se ne registri uno.

Puoi anche scrivere del codice gestito e farlo funzionare anche all'interno di IE. Il modo in cui funziona è che il CLR registra un filtro MIME quando è installato. Quindi, quando IE vede che stai inviando qualcosa del giusto tipo mime, passa il codice al CLR da gestire. Il CLR esegue il sandbox del codice nella misura in cui gli vengono concesse solo le autorizzazioni Internet, quindi non può fare tutto ciò che il framework espone. Dovrai controllare la documentazione specifica per ciò che può e non può essere fatto in questa zona di sicurezza.

Alcuni compromessi:

Facilità di installazione: i controlli ActiveX richiedono di impacchettare tutto in un file .CAB con un file .INI che descrive i requisiti di installazione in modo abbastanza enigmatico. Se devi installare dipendenze aggiuntive con i tuoi moduli (come dll ATL / MFC o altri moduli di terze parti) diventa piuttosto complicato. Con il modulo .net, devi semplicemente inviarlo con il giusto tipo MIME, ma devi assicurarti che i tuoi utenti abbiano la versione corretta del framework (che puoi controllare tramite la stringa dell'agente utente sul tuo sito web).

Sicurezza: i controlli ActiveX sono solo codice nativo in esecuzione sul sistema degli utenti, quindi in teoria possono fare quello che vogliono. In pratica LoRIE lo limita in molti casi e devi fare un mucchio di casi speciali come l'accesso al registro e al file system (vedi Comprensione e funzionamento in modalità protetta ).

Threading: poiché i controlli ActiveX vengono eseguiti sul thread dell'interfaccia utente del browser, devi assicurarti di non eseguire lunghe operazioni di blocco su quel thread, quindi devi eseguire tu stesso il threading. Se la tua lunga operazione di blocco manipola il DOM, devi eseguire il marshalling delle interfacce IHTMLxxx, utilizzando the GIT o COM Marshalling . Non sono sicuro che le applet .net vengano eseguite sul thread dell'interfaccia utente del browser o meno, ma ne sono più sicuro da gestire in C #.

Oggetti browser: se si desidera utilizzare oggetti IE / Shell nella propria estensione gestita, è necessario scrivere l'interoperabilità per la maggior parte del tempo poiché Framework non svolge un ottimo lavoro nel confezionare tali interfacce in oggetti gestiti. Vedi http://pinvoke.net per ottenere un piccolo aiuto per iniziare.

Compatibilità: ci sono problemi con l'hosting di versioni diverse del runtime nello stesso processo. Fino a poco tempo fa non era affatto possibile, ma penso che con le versioni 3.x abbia iniziato a diventare possibile fino a un certo punto. Il risultato è che se scegli come target .net 2.0 e qualcun altro ha già caricato .net 1.0 come parte dell'estensione del browser, perdi. In generale, IE e la shell di Windows non supportano le estensioni gestite. Questa roba del filtro MIME per app .net può essere un'eccezione notevole, ma tieni presente che potrebbero esserci potenziali problemi.

Answer 2

" Controllo ActiveX (creato usando un linguaggio .Net) " e "quot. applet .NET" sono entrambi gerghi per " assembly .NET ospitato in IE " ;.

In effetti, gli assembly .NET possono essere ospitati in una varietà di applicazioni. Vedi:

Creazione di un host per .NET Common Language Runtime

Answer 3

I controlli ActiveX non hanno le stesse restrizioni di sicurezza delle applet .NET, che possono essere un vantaggio o uno svantaggio a seconda di ciò che si desidera fare. Le applet .NET sono generalmente più facili da sviluppare, ActiveX che crei con VB6 o C ++.