Active document server & container C#

domenica 08 giugno 2003 - 12.47

Elenco Threads

Stanze Forum

Aggiungi ai Preferiti

Cerca nel forum

marco Profilo | Newbie

6 messaggi | Data Invio: dom 8 giu 2003 - 12:47

Abbiamo un software (abbastanza impegnativo) scritto in c++ 6 che fa ampio uso dellarchitettura Active document server. ( la vecchia classe MFC COleServerDoc).
Dobbiamo convertire questo software (tutto o in parte) in c#.

Nel valutare i problemi di conversione ci siamo bloccati già alla prima domanda :

E possibile creare in c# documenti server e container OLE ?

Sono oramai alcuni mesi che cerchiamo una soluzione

Sapete dove trovare documentazione e/o esempi a riguardo?

Grazie
Marco

Brainkiller Profilo | Guru

7.999 messaggi | Data Invio: dom 8 giu 2003 - 15:49

Ciao Marco e Benvenuto,
io non ho molta esperienza in questo campo però a volte usando l'architettura di .NET sento che comunque mi manca qualcosa.
Purtroppo le "vecchie" MFC, ATL e COM non sono definitivamente morti e sono ancora tutt'ora in uso, anzi che io sappia non ho ancora visto un prodotto commerciale ad alto livello scritto con .NET :)
Non tutte le API Win32 sono state migrate infatti alcune sono utilizzabili solo con C++ come le TAPI o altre simili.
Non dimentichiamo che il .NET Framework è solo alla versione 1.0, ora c'è anche la più recente 1.1 quindi immagino in futuro Microsoft farà dei passi avanti per supportare, si spera, tutto ciò che era disponibile in passato.
Da ciò che ho letto in giro, sembra che C# e comunque di base il .NET Framework non supporti quello che tu vuoi fare, anche perchè concetti come OLE e quindi ActiveX siano spariti lasciando il posto a User Controls, Custom Controls, e così via, che alla fine sono la stessa cosa ma lavorano in modo completamente diverso.
Leggo però che a te piacerebbe convertire il progetto totalmente o in parte in C#. Sicuramente convertirlo totalmente richiederebbe quasi una riscrittura completa del codice e quindi alti costi e tempo. Ti consiglio anche di prendere in esame un leggero decremento di performance e un maggior consumo di memoria RAM nel caso fosse riscritto tutto in C# ed è cosa da non sottovalutare.
Altra cosa che ti faccio notare è che comunque un applicazione basata su .NET necessita sempre del Framework per funzionare a differenza di quella in VC++ che ormai gira su tutti i sistemi Windows visto che le librerie sono quelle.
Personalmente credo che la migliore soluzione sia migrare innazitutto l'applicazione a VS .NET e quindi a VC++ .NET appoggiandoti alle ultime MFC e da lì hai la possibilità di cominciare a scrivere ed utilizzare codice C# e quindi .NET managed procedendo con una migrazione ibrida e graduale.
Forse questo è un buon compromesso.

Un saluto.
David De Giacomi

marco Profilo | Newbie

6 messaggi | Data Invio: lun 9 giu 2003 - 15:19

Grazie del benvenuto e di avermi risposto.
Siamo arrivati alle tue stesse conclusioni, il problema è che il nostro software è formato da due componenti base : Un software contenitore ( che linka a run_time oggetti ocx e server di documenti.) e una serie di componenti COM e server di documenti che svolgono le varie funzioni.
I server di documenti vengono incorporati nel contenitore sotto forma di finestra MDI , i componenti COM vengono richiamati generando dei dialoghi (Che servono per le varie opzioni)

Con questa architettura siamo riusciti a personalizzare il software in maniera pressoché illimitata. Infatti in fase di installazione vengono scelti i vari componenti costruendo lapplicativo finale come se si trattasse di un assemblaggio di mattoncini lego. I vari mattoncini con il linguaggio più conveniente per risolvere la problematica. Riusciamo ad agganciare componenti e server di documenti scritti in qualsiasi linguaggio compresi applicativi scritti in VBA e i componenti scritti in .net. Rimaniamo scoperti per quanto i server di documenti scritti in .net, che come hai detto tu non sono gestiti dal framework .

La conversione in c++.net (già effettuata per il 70% dei componenti) non credo che ci porti grandi vantaggi perché in ogni caso un nuovo componente con architettura Active Server Document deve essere scritto per forza di cose in c++ .net in quanto c# non lo gestisce.
Ora ti chiedo è possibile implementare un architettura simile a quella descritta sopra in c#?

Brainkiller Profilo | Guru

7.999 messaggi | Data Invio: mar 10 giu 2003 - 15:12

Eh eh, da quanto leggo mi pare proprio che il vostro prodotto/software sia molto potente ed avanzato.
Non saprei che dirti, ti ripeto che non credo che con C# si possa ottenere la cosa di cui hai bisogno, se no non ti spiegheresti perchè Office 11.0 la nuova versione di Office sia stata ancora sviluppata in VC++ e non in C# :)
Evidentemente il linguaggio C++ e in particolare l'ambiente VC++ viene ancora riservato, per ora, ad applicazioni High-End avanzate quindi che hanno bisogno di elevate performance, forte customizzazione, consumo della memoria ridotto all'osso e solo per ciò che è necessario (sprecare memoria non è mai cosa buona, e il Garbage Collector di .NET mi pare che abbia ancora qualche problemino).
Forse te lo dicevo nell'altro messaggio, l'unica soluzione per il momento è il magari costruire delle DLL in .NET per compiti particolari richiamabili dalla vostra applicazione, oppure direttamente (e forse è meglio) mischiare codice managed e unamanaged direttamente dentro la vostra applicazione e usare quando ne avete bisogno le classi del framework, anche se tutto ciò comporta comunque il caricamento del CLR quindi maggior consumo di memoria e la distribuzione assieme alla vostra applicazione del runtime da 20 mega, anche se leggevo da qualche parte ultimamente che è possibile comunque compilare tutto in modo nativo senza allegare il framework, ma su questo non sono sicuro.
Come al solito bisogna mettere sulla bilancia le varie componenti, rapidità di sviluppo con .NET contro consumo memoria, deploy delicato, ecc. oppure VC++ nativo performance elevate, gestione memoria, ma costi più elevati e più tempo richiesto per lo sviluppo.

Un saluto.
David De Giacomi

marco Profilo | Newbie

6 messaggi | Data Invio: mar 10 giu 2003 - 18:15

Sicuramente , costruendo una dll e/o mescolando codice gestito e no si risolverebbe il problema Solo che la cosa verrebbe un po farraginosa da gestire. Seguiremo il tuo consiglio e rimarremo in c++ ..

Una domanda da cosa deduci che il nostro software sia poco potente e avanzato ?

marco Profilo | Newbie

6 messaggi | Data Invio: mar 10 giu 2003 - 18:23

Perché mi ha messo tutti questi punti interrogativi?

Brainkiller Profilo | Guru

7.999 messaggi | Data Invio: mar 10 giu 2003 - 18:27

>Eh eh, da quanto leggo mi pare proprio che il vostro prodotto/software sia molto potente ed avanzato.
Mi pare che ho scritto "molto potente ed avanzato" non "poco potente e avanzato" :)

Infatti, il mischiare codice managed e unmanaged può essere fatto in previsione di una migrazione completa a .NET solo che a tutt'oggi non si sa dove andremo se ci sarà supporto per gli Active Document Server oppure se ci sarà qualche altra cosa simile, quindi se non è un problema per te si potrebbe tranquillamente restare su C++. Senti, ma tu vorresti passare al C# per quali motivi essenzialmente, questo non l'ho ancora capito ?

Ho visto i punti di domanda nel tuo messaggio, sto cercando di capire anche io, probabilmente è a causa del set di caratteri.
Ciao

David

marco Profilo | Newbie

6 messaggi | Data Invio: mar 10 giu 2003 - 19:21

I motivi sono essenzialmente 3 . il primo è di dare la possibilità a chi usa o rivende il nostro software per scrivere le proprie personalizzazioni. in c# o il vs .net. Ho notato che da quando è uscito il .net , sono tutti diventanti bravissimi aprono interfacce si integrano col sistema operativo ecc ( sarà vero? Bho? Mi ricorda quando anni addietro uscì il c++ che soppiantò il buon vecchio C. generò lo stesso fenomeno di MODA nei nuovi e disorientamento nei vecchi sviluppatori. Però prima che il c++ diventasse efficiente e affidabile passarono parecchi anni ) Il secondo motivo è che abbiamo preso degli impegni con MS che dobbiamo tirar fuori qualche cosa che usi il framework.entro dicembre. Il terzo, anche se non sono particolarmente entusiasta del c# (forse sto diventando vecchio e giudico il .net un po acerbo per certe cose) non mi va che i miei prodotti rimangano indietro tecnologicamente. Il nostro software viene installato anche in ambienti eterogenei e in apparecchiature mobili e devo ammette che laccoppiata c# XML si presta bene a questo scopo e che alcune novità introdotte nel linguaggio sono carine.

Tu non parli tanto bene Garbage Collector , di quello che so io dovrebbe funzionare abbastanza bene. In effetti non ho fatto ancora delle prove accurate, ma per quanto ne so cè anche la possibilità di controllarlo manualmente evitando che sprechi eccessiva memoria.

Ciao
Marco

marco Profilo | Newbie

6 messaggi | Data Invio: mar 10 giu 2003 - 19:23

Al posto dei tre puntini mette il punto interrogativo.

Torna su

Stanze Forum

Elenco Threads

Partecipa anche tu! Registrati!

Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !