Come gestire ActiveX / OCX oggi - Una tabella decisionale Mantieni / Avvolgi / Sostituisci

I progetti in cui compaiono le parole ActiveX / OCX di solito hanno un’aria leggermente pesante.

• Le app VB6 o le vecchie app C++ / MFC sono ancora in servizio attivo
• Il SDK per apparecchiature industriali o strumenti di misura viene spedito solo come OCX
• L’app Web interna presuppone ActiveX e non può sfuggire a IE mode
• Vuoi passare da 32-bit a 64-bit, ma un solo OCX scuote la testa

Detto questo, sia “è vecchio, quindi butta via tutto” sia “funziona, quindi conservalo per sempre” sono sciatti. Ciò che conta è distinguere se il ActiveX / OCX è un semplice componente dell’UI o una superficie di confine che trasporta regole aziendali e specifiche del dispositivo.

Questo articolo organizza, in un ordine che facilita la decisione, quale tra mantenere, avvolgere o sostituire scegliere quando trovi ActiveX / OCX.

Gli obiettivi sono casi come questi, per esempio.

• App desktop esistenti nella famiglia VB6 / MFC / WinForms
• Migrazione graduale a C# / .NET
• Schermate precedenti che coinvolgono WebBrowser / IE mode
• App Windows contenenti controlli ActiveX forniti dal fornitore

Sommario

1. Prima la conclusione (in una riga)
2. Cosa significa questo articolo per ActiveX / OCX
3. La tabella decisionale da considerare per prima
   • 3.1. Il quadro generale
   • 3.2. Il caso della conservazione
   • 3.3. Il caso del confezionamento
   • 3.4. Il caso della sostituzione
   • 3.5. Le dipendenze del browser sono una categoria separata
4. Punti che distorcono facilmente la decisione
   • 4.1. È un componente dell’UI o un componente con specifiche?
   • 4.2. 32-bit / 64-bit e confini del processo
   • 4.3. Registrazione, distribuzione, privilegi, licenza
   • 4.4. STA / Loop di messaggi / Richiamate
   • 4.5. Esistono i test? Puoi osservarlo?
5. Raccomandazioni per modello tipico
   • 5.1. Un’app desktop interna che funziona ancora in modo stabile
   • 5.2. Vuoi portare un 32-bit OCX sul lato 64-bit
   • 5.3. Schermi realizzati su IE / WebBrowser
   • 5.4. ActiveX Controllo del dispositivo di trasporto o specifiche proprietarie
6. Anti-pattern comuni
7. Lista di controllo per avviare una migrazione
8. Una guida decisionale approssimativa
9. Consulenze che si adattano bene
10. Riepilogo
11. Riferimenti

1. Prima la conclusione (in una riga)

• Quando vedi ActiveX / OCX la prima cosa da giudicare non è “se è vecchio” ma cosa ha assunto quel componente
• Se si tratta di un semplice componente dell’UI, la sostituzione è relativamente semplice
• Se comporta il controllo dei dispositivi, la generazione di report, formati di file proprietari o anni di abitudini operative, completarlo prima è più sicuro che lanciarsi nella reimplementazione
• Se funziona stabilmente sul desktop e l’ambito della modifica è limitato, mantenerlo è una decisione perfettamente valida
• Le dipendenze ActiveX ospitate dal browser possono essere mantenute in supporto vitale, ma il futuro è sottile: considerale con la sostituzione come priorità
• Non è possibile caricare un 32-bit OCX direttamente in un processo 64-bit. Nessuna quantità di forza di volontà supera questa linea
• Registrazione, DLLs dipendente, privilegi di amministratore, licenza, STA / MTA: gli attriti al di fuori dell’implementazione tendono ad essere dove le cose si fanno difficili
• Sia il “riscrivere tutto” che il “congelarlo per sempre per paura” hanno tassi di incidenti elevati

Insomma, l’ordine di giudizio è questo.

1. Cosa contiene quel OCX?
2. È necessario che venga eseguito nello stesso processo?
3. 32-bit / 64-bit, la registrazione o le dipendenze del browser ti bloccheranno?
4. Dovresti costruire un confine verificabile prima della sostituzione?

Viste in questo ordine, le cose diventano notevolmente più facili da risolvere.

2. Cosa significa questo articolo per ActiveX / OCX

Fissiamo innanzitutto la terminologia utilizzata in questo articolo.

A rigor di termini, ActiveX e COM non sono la stessa cosa. Ma i punti in cui fanno male nella pratica sono abbastanza simili.

• I pezzi 32-bit / 64-bit si incastrano tra loro?
• Come distribuisci la registrazione e i dipendenti DLLs?
• In quale host / contenitore viene eseguito?
• STA, loop di messaggi o richiamate ti bloccheranno?
• Le dipendenze del browser sono ancora in agguato?Questo articolo tratta insieme questi punti decisionali pratici.

3. La tabella decisionale da considerare per prima

3.1. Il quadro generale

Iniziate con questo tavolo e la politica approssimativa si risolverà per lo più da sola.

flowchart TD
    start["Hai ActiveX / OCX"] --> q1{"Dipendenza dal browser?"}
    q1 -- "SÌ" --> p1["Dai priorità alla modalità sostituzione<br/>IE è supporto vitale"]
    q1 -- "NO" --> q2{"Principalmente un componente dell'UI?"}
    q2 -- "SÌ" --> q3{"È disponibile un'alternativa equivalente?"}
    q3 -- "SÌ" --> p2["Valuta la possibilità di sostituirlo"]
    q3 -- "NO" --> p3["Avvolgi prima e sistema il confine"]
    q2 -- "NO" --> q4{"Supporta il controllo del dispositivo / le specifiche proprietarie / la logica dei report?"}
    q4 -- "SÌ" --> p4["Avvolgi prima<br/>assembla i test, quindi sostituiscili in più fasi"]
    q4 -- "NO" --> q5{"Registrazione / bitness / distribuzione dolorosa?"}
    q5 -- "SÌ" --> p5["Riconsiderare la configurazione<br/>considerare il bridging out-of-process / processo separato / Reg-Free COM"]
    q5 -- "NO" --> p6["Anche mantenerlo è realistico"]

Di seguito, esaminiamo ciascun modello a turno.

3.2. Il caso della conservazione

Essere ActiveX / OCX non rende automaticamente qualcosa un bersaglio sostitutivo. Quando si verificano condizioni come queste, mantenerle spesso è semplicemente l’opzione più economica.

• L’ambito di utilizzo è chiuso e l’ambiente operativo è fisso: distribuzione interna, bundle con apparecchiature e così via
• Il controllo funziona ancora in modo stabile e le richieste di modifica non sono grandi
• Il venditore è ancora attivo oppure il tuo team può eseguire una manutenzione minima
• Non dipende dal browser e risiede interamente all’interno di un host desktop esistente
• La premessa 32-bit / 64-bit non necessita di modifiche nel prossimo futuro

Ciò che conta qui è che mantenere non significa trascurare. Se lo tieni, vuoi almeno questo a posto.

• Documentare L’OS supportato, il bitness, il DLLs dipendente richiesto e i passaggi di registrazione
• Sposta l’installazione, la registrazione e l’annullamento della registrazione negli script o in un programma di installazione, non in promemoria umani
• Preparare un test del fumo in un ambiente pulito
• Incanalare le chiamate al controllo in un unico posto il più possibile, invece di disperderle nell’app

Il risultato peggiore è continuare a dire “funziona, quindi non toccarlo” per 10 anni finché nessuno riuscirà più a spiegarne le premesse. Più scegli di conservare, più diventa importante rendere visibili i locali.

3.3. Il caso del confezionamento

In pratica, questa scelta è dove si svolge la maggior parte del lavoro.

“Wrapping” qui significa confinare ActiveX / OCX all’interno di un confine ristretto e presentarlo all’ambiente circostante come una nuova API o un nuovo componente dell’UI.

Questo è abbastanza efficace. La ragione è che entrare in una reimplementazione completa mentre il comportamento del vecchio componente non può essere completamente letto tende a diventare una doppia agonia di archeologia delle specifiche e riproduzione dei difetti. È più sicuro isolare prima il vecchio componente e sistemare solo il confine.

Esistono diverse forme consolidate per il confezionamento.

Una volta scelta la direzione, ecco il primo passo concreto per ciascun approccio.

aximp si esegue dal Developer Command Prompt di Visual Studio.

aximp C:\path\to\MyControl.ocx

Questo genera due wrapper: uno runtime callable wrapper per i tipi COM e uno derivato da AxHost per Windows Forms. I nomi dei file non dipendono dal nome del file .ocx, ma dal ProgID. Nell’esempio della documentazione Microsoft, da msdxm.ocx si ottengono MediaPlayer.dll e AxMediaPlayer.dll. Si fa riferimento al secondo e si aggiunge il controllo AxMediaPlayer al form.

Nel caso di Reg-Free COM, il manifesto minimo dell’app ha questa forma.

<?xml version="1.0" encoding="utf-8"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <assemblyIdentity type="win32" name="MyApp" version="1.0.0.0" />
  <file name="MyControl.ocx">
    <comClass
      clsid="{01234567-89AB-CDEF-0123-456789ABCDEF}"
      threadingModel="Apartment"
      progid="MyCompany.MyControl.1" />
  </file>
</assembly>

Nel caso di LocalServer, nel registro deve esserci il percorso dell’EXE sotto HKEY_CLASSES_ROOT\CLSID\{CLSID}\LocalServer32. Se il server EXE è scritto in ATL o MFC, spesso segue la convenzione di auto-registrazione con MyServer.exe /regserver e annullamento con /unregserver. Attenzione però che la vista del registro è separata per bitness: un EXE a 32-bit si registra nella vista a 32-bit del registro.

Ciò che conta di più è non copiare 200 del vecchio API parola per parola durante il confezionamento. In questo modo si importano semplicemente le peculiarità del vecchio componente direttamente nel nuovo codice.

Quando si avvolge, tenere a mente questi aspetti migliora notevolmente le cose.

• Utilizzare metodi a grana grossa
• Non lasciare che il codice dello schermo tocchi direttamente OCX
• Cattura i registri necessari in caso di guasto al confine
• Decidere le responsabilità per timeout, tentativi e traduzione delle eccezioni al confine
• Rendi intercambiabile la futura sostituzione dietro la stessa interfaccia

A volte è necessario mantenere solo il punto di ingresso COM sul nuovo lato .NET. In tal caso, la configurazione realistica è “aggiornare gli interni mantenendo solo il contratto COM”. Tuttavia, l’istinto dell’era .NET Framework di “solo RegAsm” non è necessariamente sufficiente. La gestione dei moderni host .NET COM, TLBs, bitness e Registration-Free COM sarà più semplice in seguito se lo progetti in anticipo.

3.4. Il caso della sostituzione

Tute sostitutive nei casi in cui il problema è principalmente età a livello superficiale.

In situazioni come queste, considera la sostituzione come una priorità.

• Quel ActiveX viene utilizzato solo come componente dell’UI
• Il venditore fornisce un successore per .NET / WPF / WebView2
• La dipendenza dal browser o la premessa IE ti trattengono
• La registrazione, la firma, i privilegi di amministratore o le impostazioni di sicurezza ti infastidiscono ogni volta
• Esistono test o scenari aziendali che possono convalidare un’implementazione alternativa

Al contrario, spingersi fino in fondo nello scartare un componente che trasporta il controllo del dispositivo o la logica del report, semplicemente perché sembra vecchio, di solito finisce nel fango.

Se sostituisci, inizia con l’UI.

• Griglie
• Calendari
• Alberi
• Aree di visualizzazione del browser
• Semplici aiutanti di input

Questi sono relativamente facili da sostituire. D’altra parte, alcune cose sembrano un’UI ma sono dense all’interno.

• Controllo del dispositivo fornito dal fornitore ActiveX
• Controlli fusi con la stampa o la generazione di report
• Controlla l’incorporamento di lettura / scrittura di formati di file proprietari
• Controlli che trasportano callback COM o ipotesi di threading

Se si valuta male questa differenza, la stima dello sforzo crolla immediatamente.

3.5. Le dipendenze del browser sono una categoria separata

Questa è davvero una categoria separata.

ActiveX ospitato su browser, a differenza del OCX desktop, ha ragioni piuttosto deboli per continuare a investire.

Il motivo è semplice: le moderne piattaforme browser non fanno più di questo il loro campo di battaglia. Lo stesso Microsoft Edge non supporta ActiveX. IE mode, d’altro canto, utilizza il motore della famiglia IE per i siti configurati e può essere utilizzato come livello di compatibilità per l’esecuzione di alcune funzionalità di IE, incluso ActiveX.

In altre parole:

• Il supporto vitale per mantenerlo in funzione ora è possibile
• Ma come progetto a lungo termine, il futuro non è ampio

Lo stesso vale per il controllo WebBrowser incorporato nelle app Windows. WebBrowser trascina con sé la visione del mondo IE, quindi se vuoi semplicemente visualizzare HTML, è più naturale rendere WebView2 il primo candidato per qualsiasi nuovo lavoro da ora in poi.

Tuttavia, fai attenzione: WebView2 non è un pezzo di ricambio immediato per WebBrowser.

• Script basati su IE DOM
• Dipendenze ActiveX
• Ipotesi intorno a window.external
• Comportamento basato sulle zone di sicurezza e sull’intranet

Questi non vengono trasferiti così come sono. Se sostituisci, devi riprogettare non solo il motore di rendering ma anche la superficie di connessione tra il browser e il codice nativo.

4. Punti che distorcono facilmente la decisione

4.1. È un componente dell’UI o un componente con specifiche?

Questo è il più importante.

Per una vecchia griglia o calendario, il controllo della compatibilità visiva ed eventi porta la conversazione piuttosto lontano. D’altra parte, ActiveX che trasporta il controllo del dispositivo, il reporting o formati proprietari ha una massa di specifiche dietro il suo aspetto.

Anche le cose che sembrano lo stesso “controllo su uno schermo” in realtà coprono questo intervallo.

• Un semplice componente di visualizzazione dell’elenco
• Un componente che spara comanda l’apparecchiatura tramite un protocollo proprietario
• Un componente che gestisce internamente timeout, riconnessione, ritrasmissione e persino l’immissione di eccezioni
• Un componente che garantisce la compatibilità dei formati di stampa ed esportazione

La reimplementazione di quest’ultimo da zero di solito si trasforma in un progetto di specificazione archeologica. Avvolgere prima è più sicuro qui.

4.2. 32-bit / 64-bit e confini del processo

Questo è spesso trascurato, ma è piuttosto fondamentale.

Un OCX in-process deve corrispondere al bit del processo che lo carica. Cioè, non puoi caricare un 32-bit OCX direttamente in un’app 64-bit.

Le opzioni realistiche a quel punto sono più o meno queste tre.

• Per il momento mantieni l’app host 32-bit
• Confinarlo in un processo 32-bit separato, collegato al lato 64-bit tramite IPC o fuori processo COM
• Sostituisci la dipendenza iniziando dal punto in cui OCX può essere rimosso per primo

“È qualsiasi CPU, probabilmente funzionerà” per lo più non aiuta qui. Anche quando costruisci una facciata compatibile con COM sul nuovo lato .NET, l’aspetto del codice gestito e il bit dell’effettivo host COM sono questioni separate. Inizia qui in modo sciatto e ti ritroverai nel brutto caso in cui la build passa ma non viene eseguito nulla presso il sito del cliente.

4.3. Registrazione, distribuzione, privilegi, licenza

Tecnicamente richiamabile, ma morto nella distribuzione. Questo è abbastanza comune con ActiveX / OCX.

I probabili punti problematici sono questi.

• I prerequisiti regsvr32 vivono nella testa di qualcuno
• Il posizionamento del dipendente DLLs è implicito
• I privilegi di amministratore sono richiesti ma non sono mai stati inseriti nelle procedure operative
• Il fornitore controlla la suddivisione delle licenze design-time e runtime
• Funziona sulla macchina di sviluppo ma non in un ambiente pulito

Questi possono interrompere un progetto senza toccare una singola riga di codice.

Le configurazioni senza registrazione e il posizionamento affiancato possono facilitare le cose in alcuni casi, ma non sono polvere magica. Dovrà essere verificata la compatibilità con il lato contenitore e la modalità di distribuzione.

In breve, una migrazione ActiveX / OCX è progettazione della distribuzione, non solo implementazione. Rimanda questa parte e alla fine farai un viaggio spettacolare.

4.4. STA / Loop di messaggi / Richiamate

ActiveX / OCX non è solo una chiamata DLL. Può contenere ipotesi sul modello di threading e sui loop di messaggi di COM.

Casi a cui prestare attenzione in particolare:- Stabile solo se si presume che si trovi nel thread dell’UI

• Presuppone STA, ma viene chiamato con noncuranza da MTA
• Le richiamate ritornano nel mezzo di una chiamata sincrona
• I presupposti del threading per la ricezione di eventi sono vaghi

Questi compaiono per la prima volta sotto l’aspetto di storie di fantasmi: “a volte si blocca”, “a volte gli eventi non arrivano”. Ma la sostanza è solitamente un presupposto violato.

Quindi, che si tratti di avvolgere o sostituire, quale thread lo crea, quale thread lo chiama e dove vengono ricevuti gli eventi dovrebbe essere definito per primo.

4.5. Esistono i test? Puoi osservarlo?

La sostituzione è difficile non solo perché il codice è vecchio. È difficile perché non esiste una definizione di cosa conta come “si è comportato allo stesso modo”.

Avere anche questi fa una differenza sostanziale.

• Prove di fumo per scenario operativo
• Campioni di ingresso / uscita
• Catture di schermate e esempi di report
• Modelli di errore e comportamento previsto
• Registri di timeout e situazioni di dispositivo non connesso

Soprattutto quando sono coinvolti apparecchiature o rapporti, emerge la strana realtà che il comportamento dal vivo è più veritiero dei documenti delle specifiche. Senza mezzi di osservazione qui la sostituzione si trasforma in uno scavo.

5. Raccomandazioni per modello tipico

5.1. Un’app desktop interna che funziona ancora in modo stabile

La raccomandazione: protendersi verso il mantenimento.

In condizioni come queste, non strapparlo con la forza è spesso la mossa migliore.

• Usato solo internamente
• Le macchine target e OS sono ragionevolmente riparate
• Il OCX viene utilizzato solo su pochi schermi
• Le richieste di modifica sono piccole e la durata è prevedibile

Tuttavia, invece di lasciarlo nudo, consolidare solo i siti di chiamata ripaga in seguito.

Quindi la politica va così.

• Tienilo per ora
• Ma riordina solo il confine
• Modellare le cose in modo che, quando la sostituzione si rende necessaria, si possa ripartire da lì

Questa posizione in tre fasi è quella naturale.

5.2. Vuoi portare un 32-bit OCX sul lato 64-bit

La raccomandazione: wrap / modifica la configurazione.

Affrontare questa cosa a testa alta è scacco matto. Un 32-bit OCX non può essere caricato in-proc in un processo 64-bit.

Realisticamente, la configurazione gestibile è confinarlo in un processo di supporto 32-bit o LocalServer, comunicare con l’app 64-bit tramite un’API grossolana.

sequenceDiagram
    participant App as 64-bit .NET app
    participant Bridge as 32-bit helper / LocalServer
    participant Ocx as 32-bit OCX

    App->>Bridge: Request via a coarse API
    Bridge->>Ocx: In-proc call
    Ocx-->>Bridge: Results / events
    Bridge-->>App: Translated results

Il punto qui è non trasmettere ogni metodo a grana fine così com’è. Il confine di un processo diventa rapidamente doloroso quando si fanno passare grandi volumi di chiamate a grana fine attraverso di esso.

• Puntare a una granularità di circa 1 operazione = 1 richiesta
• Modellare i valori restituiti e gli errori in unità significative
• Cattura i registri al confine

Con questa forma in atto, anche la sostituzione successiva degli interni è più semplice.

5.3. Schermi realizzati su IE / WebBrowser

La raccomandazione: dare priorità alla sostituzione.

Si tratta di un’area in cui “funziona subito” e “è facile da manutenere” raramente coincidono. IE mode aiuta molto per la compatibilità, ma la premessa rimane la famiglia IE.

Quindi il modo più chiaro di pensarci è dividerlo in questo modo.

• Mantieni le cose in vita con IE mode in modo che le operazioni interne non si interrompano
• Ma non confondere il supporto vitale con un design permanente
• Scegli la destinazione sostitutiva da WebView2, un’app Web pura, un’UI nativa + ibrido Web e così via

In particolare, se il controllo WebBrowser viene utilizzato semplicemente come visualizzatore HTML, la priorità di sostituzione è alta.

D’altra parte, se il browser interno ActiveX svolge ruoli come file locali, dispositivi, firma o componenti aggiuntivi proprietari, allora non si tratta di uno scambio del motore di rendering ma di una riprogettazione dell’integrazione nativa. Quella conversazione diventa un po’ più pesante.

5.4. ActiveX Controllo del dispositivo di trasporto o specifiche proprietarie

La raccomandazione: avvolgere prima.

Questo tipo è più denso all’interno di quanto sembri. Anche se la documentazione del SDK è scarsa, anni di esperienza sul campo possono significare che comportamenti come questi si sono accumulati implicitamente.

• Come attende dopo errori di connessione
• Riprovare dopo i timeout
• Ordinazione di eventi
• Soluzioni alternative che assorbono le peculiarità dell’hardware reale
• Interpretazione delle eccezioni e dei codici di errore

Ricostruisci questo tipo di componente con la motivazione “è comunque vecchio” e i test sul campo prenderanno fuoco con alta probabilità.

Quindi è più sicuro iniziare da qui.

1. Confinare il componente esistente all’interno di un confine
2. Aggiungi la registrazione in modo da poter vedere cosa sta succedendo
3. Raccogli scenari di test e modelli hardware reali
4. Quindi ritaglia gli intervalli che possono essere sostituiti

Non è appariscente, ma in pratica è ciò che funziona meglio.

6. Anti-pattern comuni

Di questi, tre sono particolarmente comuni nella pratica.

1. Correre verso una riscrittura completa
2. Sottovalutare il muro del morso
3. Distribuzione dell’API nell’intera app

Evitando solo questi tre si riduce già notevolmente il tasso di incidenti.

7. Lista di controllo per avviare una migrazione

I progetti ActiveX / OCX vanno meglio quando si fa prima l’inventario invece di immergersi nell’implementazione. L’ordine funziona più o meno così.

1. Enumerare il OCX / DLLs in uso
   • Nomi file, versioni, ProgIDs, CLSIDs, fornitori, presenza di licenze
2. Enumerare dove vengono utilizzati
   • Schermate, funzionalità, report, apparecchiature, lavori batch, integrazione Office e così via
3. Confermare le condizioni del bitness e dell’host
   • 32-bit / 64-bit, in-process / out-of-proc, ipotesi STA, dipendenza dal browser
4. Confermare le condizioni di distribuzione
   • Metodo di registrazione, dipendente DLLs, privilegi di amministratore, installazione silenziosa, riproduzione dell’ambiente pulito
5. Costruisci test del fumo
   • Includere non solo il percorso felice, ma anche i casi di fallimento, di mancata connessione e di timeout
6. Costruisci il confine
   • Adattatore, servizio, facciata, bridging di processi separati e così via
7. Prova in piccole unità: uno schermo, una funzionalità, un dispositivo
8. Dai limiti che hanno funzionato, espandere mantieni / avvolgi / sostituisci in ordine

Salta questi passaggi e in seguito non sarai nemmeno in grado di spiegare “cosa c’era di difficile in questo”.

8. Una guida decisionale approssimativa

In caso di dubbio, distingui prima il componente dell’UI e le specifiche che trasportano la superficie di confine, e diventa molto più difficile sbagliare.

9. Consulenze adatte

Questo tema tende a fornire valore anche semplicemente dal chiarimento politico prima dell’inizio di qualsiasi sviluppo.

Ad esempio, consultazioni come queste si adattano abbastanza bene.

• Vuoi un inventario di cui OCX dovrebbe davvero essere sostituito
• Prima vuoi che vengano risolti solo i punti critici 32-bit / 64-bit
• Vuoi spostarti a .NET ma mantenere solo il punto di ingresso COM
• Vuoi confrontare le misure di supporto vitale e una strategia di uscita per un ActiveX il cui fornitore non c’è più
• Vuoi vedere prima dove è possibile eliminare la dipendenza IE / WebBrowser
• Vuoi separare in modo sicuro solo una schermata o una funzione per iniziare

Nei progetti ActiveX / OCX, il modo in cui si tagliano i confini spesso decide il risultato prima dell’implementazione. Come preliminare ad una revisione completa, vale la pena iniziare anche da una valutazione dello stato attuale, dal confronto della configurazione e dalla progettazione dell’ordine di migrazione.

10. Riepilogo

Come gestire ActiveX / OCX non è una questione da risolvere “non piacendolo perché è un’eredità”.

Ci sono quattro punti da considerare innanzitutto.

1. Il componente è una mera UI o una superficie di confine con specifiche?
2. È necessario che venga eseguito nello stesso processo?
3. 32-bit / 64-bit, la registrazione, la dipendenza dal browser o la licenza ti bloccheranno?
4. Puoi osservare il comportamento prima della sostituzione?

Una volta che questi quattro sono visibili, le cose per lo più si risolvono in questo modo.

• Funziona stabilmente con una durata di vita prevedibile: mantieni
• Vuoi modernizzare solo l’ambiente circostante: avvolgere
• Componente dell’UI o dipendente dal browser: sostituire
• Un componente che porta una serie di specifiche: prima avvolgerlo, poi sostituirlo gradualmente

La tecnologia legacy non è qualcosa di cui ridere: è un artefatto vivente ricco di storia e contratti. Ma convivere con l’artefatto richiede una progettazione dei confini.

Una volta che riesci a pensare in una miscela di “mantieni, avvolgi, sostituisci”, I progetti ActiveX / OCX si trasformano improvvisamente in problemi risolvibili.

11. Riferimenti

• Microsoft Learn: AxHost Classe (System.Windows.Forms)
  • https://learn.microsoft.com/en-us/dotnet/api/system.windows.forms.axhost
• Microsoft Learn: Aximp.exe (Windows Forms ActiveX Importatore di controlli)
  • https://learn.microsoft.com/en-us/dotnet/framework/tools/aximp-exe-windows-forms-activex-control-importer
• Microsoft Learn: Procedura: aggiungere controlli ActiveX a Windows Forms
  • https://learn.microsoft.com/en-us/dotnet/desktop/winforms/controls/how-to-add-activex-controls-to-windows-forms
• Microsoft Learn: espone i componenti .NET Core a COM
  • https://learn.microsoft.com/en-us/dotnet/core/native-interop/expose-components-to-com
• Microsoft Learn: Registration-Free COM Interoperabilità
  • https://learn.microsoft.com/en-us/dotnet/framework/interop/registration-free-com-interop
• Microsoft Learn: domande frequenti su Microsoft Edge
  • https://learn.microsoft.com/en-us/deployedge/microsoft-edge-frequently-asked-questions
• Microsoft Learn: Cos’è la modalità Internet Explorer (IE)?
  • https://learn.microsoft.com/en-us/deployedge/edge-ie-mode
• Microsoft Learn: WebBrowser Classe (System.Windows.Forms)
  • https://learn.microsoft.com/en-us/dotnet/api/system.windows.forms.webbrowser
• Microsoft Learn: Introduzione a Microsoft Edge WebView2
  • https://learn.microsoft.com/en-us/microsoft-edge/webview2/
• KomuraSoft Blog: nozioni di base per evitare blocchi con COM STA / MTA
  • /it/blog/2026/01/31/000-sta-mta-com-relationship/
• KomuraSoft Blog: perché dovresti creare un wrapper C++/CLI quando utilizzi C++ nativo DLLs da C# nativo
  • /it/blog/2026/03/07/000-cpp-cli-wrapper-for-native-dlls/
• KomuraSoft Blog: un case study su COM - Quando si desidera chiamare un 64-bit DLL da un’app 32-bit
  • /it/blog/2026/01/25/002-com-case-study-32bit-to-64bit/

Articoli correlati

Articoli recenti con gli stessi tag per approfondire argomenti vicini.

Argomenti correlati

Queste pagine collocano l’argomento in un contesto più ampio di servizi e decisioni.

Servizi collegati all’argomento

L’articolo è direttamente collegato ai servizi seguenti.

Domande frequenti

Domande che ricorrono nelle consulenze sull’argomento dell’articolo.

Posso caricare un 32-bit OCX in un'applicazione 64-bit?

No. Un OCX in-process deve corrispondere al bit del processo che lo carica, quindi un 32-bit OCX non può essere caricato direttamente in un'app 64-bit e nessuna impostazione di build risolve questo problema. Le opzioni realistiche sono mantenere l'applicazione host 32-bit per il momento, confinare OCX in un processo di supporto 32-bit separato o COM LocalServer e comunicare con essa dal lato 64-bit tramite IPC o out-of-process COM, oppure sostituire la dipendenza iniziando dal punto in cui OCX può essere rimosso per primo. Quando esegui il bridging tra processi, utilizza un'API a grana grossa anziché inoltrare ogni chiamata al metodo a grana fine.

Dovrei sostituire un controllo ActiveX solo perché è vecchio?

Non automaticamente. La prima cosa da giudicare non è se il componente è vecchio ma cosa ha assunto. Se si tratta di un semplice componente dell'UI come una griglia o un calendario ed esiste un'alternativa, la sostituzione è relativamente semplice. Se comporta il controllo del dispositivo, la generazione di report, formati di file proprietari o anni di comportamento operativo, racchiuderlo prima entro un confine ristretto è più sicuro che lanciarsi in una reimplementazione completa e si può ragionevolmente mantenere un controllo desktop stabile con un piccolo ambito di modifica.

Cosa devo fare per ActiveX e IE mode ospitati su browser?

Considera la sostituzione come una priorità. Lo stesso Microsoft Edge non supporta ActiveX e IE mode è posizionato come livello di compatibilità, quindi può far funzionare le cose ora ma ha poco futuro come progettazione a lungo termine. Per le app che incorporano il controllo WebBrowser semplicemente come visualizzatore HTML, WebView2 è il primo candidato naturale, ma non è un sostituto immediato: gli script basati sulle dipendenze IE DOM, ActiveX, i presupposti window.external e il comportamento della zona di sicurezza non vengono trasferiti, quindi la superficie di integrazione nativa deve essere riprogettata.

Cosa comporta effettivamente il confezionamento di un OCX?

Il wrapper significa confinare ActiveX / OCX all'interno di un confine ristretto e presentarlo al resto dell'app come una nuova API o componente dell'UI. Le forme consolidate includono un host WinForms con AxHost / Aximp, un helper 32-bit EXE o COM LocalServer per il bridging di processi separati e una facciata compatibile con COM sul lato .NET. La regola più importante è non copiare alla lettera l'API del vecchio componente: utilizzare metodi a grana grossa, evitare che il codice dello schermo tocchi direttamente OCX, acquisire log e traduzione degli errori al limite e rendere una futura sostituzione scambiabile dietro la stessa interfaccia.

Profilo dell’autore

Pagina di presentazione dell’autore dell’articolo.

Go Komura

Rappresentante di KomuraSoft LLC

Specializzato nello sviluppo di software Windows, nella consulenza tecnica e nell’analisi dei malfunzionamenti, soprattutto nei progetti con sistemi esistenti e guasti difficili da riprodurre.