Kleidemos
10-01-2003, 12:01
A cosa servono i files manifest in C#????
Tnk
Tnk
View Full Version : [C#]Files Manifest
atragon
10-01-2003, 13:47
Un "manifesto" in c# ma più in generale nell'ambito .Net è l'area descrittiva di un assembly o di una applicazione e ne espone la versione le opzioni di sicurezza, i riferimenti esterni, i componenti ed altre caratteristiche ancora, detto molto in breve. Il tutto è basato su xml. Esiste una schematizzazione precisa di costruzione di un file manifesto.
Kleidemos
10-01-2003, 14:01
Originally posted by "atragon"
Un "manifesto" in c# ma più in generale nell'ambito .Net è l'area descrittiva di un assembly o di una applicazione e ne espone la versione le opzioni di sicurezza, i riferimenti esterni, i componenti ed altre caratteristiche ancora, detto molto in breve. Il tutto è basato su xml. Esiste una schematizzazione precisa di costruzione di un file manifesto.
hai qualche link in proposito?
Un "manifesto" in c# ma più in generale nell'ambito .Net è l'area descrittiva di un assembly o di una applicazione e ne espone la versione le opzioni di sicurezza, i riferimenti esterni, i componenti ed altre caratteristiche ancora, detto molto in breve. Il tutto è basato su xml. Esiste una schematizzazione precisa di costruzione di un file manifesto.
hai qualche link in proposito?
atragon
10-01-2003, 14:16
Ad esempio guarda qui:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sbscs/setup/assembly_manifests.asp , poi sempre in quella zona sulla sinistra trovi altri riferimenti. Io ho studiato lì sopra, per lo meno....magari in giro si trova qualche cosa più chiaro, ma secondo me lì è la Bibbia sull'argomento.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sbscs/setup/assembly_manifests.asp , poi sempre in quella zona sulla sinistra trovi altri riferimenti. Io ho studiato lì sopra, per lo meno....magari in giro si trova qualche cosa più chiaro, ma secondo me lì è la Bibbia sull'argomento.
soalle
10-01-2003, 14:22
Originally posted by "atragon"
Il tutto è basato su xml.
Ne sei sicuro? Sicuramente dentro l'assembly il manifest non è memorizzato in xml (ha un formato standardizzato) e poi per dargli delle direttive credevo bisognasse usare gli attributi.
L'unica cosa che mi viene in mente in xml è il file config (che usa il framework per varie cose) ma non c'entra con il manifest direttamente...
Il tutto è basato su xml.
Ne sei sicuro? Sicuramente dentro l'assembly il manifest non è memorizzato in xml (ha un formato standardizzato) e poi per dargli delle direttive credevo bisognasse usare gli attributi.
L'unica cosa che mi viene in mente in xml è il file config (che usa il framework per varie cose) ma non c'entra con il manifest direttamente...
atragon
10-01-2003, 14:30
Se si parla di "Application manifest file" e di "assembly manifest file" parliamo di files xml sicuramente, vedi il riferimento che ho dato a Kleidemos che parla esplicitamente di manifest files. Se poi vogliamo parlare di struttura di un assembly è un altro discorso...può darsi abbia inteso male io, mi pareva che Kleidemos si riferisse a quanto ho indicato.
soalle
10-01-2003, 14:54
Originally posted by "atragon"
Ad esempio guarda qui:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sbscs/setup/assembly_manifests.asp , poi sempre in quella zona sulla sinistra trovi altri riferimenti. Io ho studiato lì sopra, per lo meno....magari in giro si trova qualche cosa più chiaro, ma secondo me lì è la Bibbia sull'argomento.
Scusa letto adesso.... mi hai convinto...
Ma adesso ho un gran casino in testa il "file manifest" contiene le informazioni del "manifest" che è dentro ad ogni assembly?
Se sì.... :confused: :confused: :confused: allora è un gran casino... cioé se contiene le stesse informazioni il framework usa quelle nel file manifest o quelle all'interno dell'assembly? Eppoi perché fare un file separato se le informazioni le genera direttamente il compilatore? E l'autodescrittività...? Bah... illuminami....
Ciaociao
Soalle
PS: perché se esiste uno standard la Microsoft deve prenderlo e farne uno suo? Ho visto gli schemi per definire il manifest.... :muro:
Ad esempio guarda qui:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sbscs/setup/assembly_manifests.asp , poi sempre in quella zona sulla sinistra trovi altri riferimenti. Io ho studiato lì sopra, per lo meno....magari in giro si trova qualche cosa più chiaro, ma secondo me lì è la Bibbia sull'argomento.
Scusa letto adesso.... mi hai convinto...
Ma adesso ho un gran casino in testa il "file manifest" contiene le informazioni del "manifest" che è dentro ad ogni assembly?
Se sì.... :confused: :confused: :confused: allora è un gran casino... cioé se contiene le stesse informazioni il framework usa quelle nel file manifest o quelle all'interno dell'assembly? Eppoi perché fare un file separato se le informazioni le genera direttamente il compilatore? E l'autodescrittività...? Bah... illuminami....
Ciaociao
Soalle
PS: perché se esiste uno standard la Microsoft deve prenderlo e farne uno suo? Ho visto gli schemi per definire il manifest.... :muro:
Kleidemos
10-01-2003, 14:57
Originally posted by "atragon"
Se si parla di "Application manifest file" e di "assembly manifest file" parliamo di files xml sicuramente, vedi il riferimento che ho dato a Kleidemos che parla esplicitamente di manifest files. Se poi vogliamo parlare di struttura di un assembly è un altro discorso...può darsi abbia inteso male io, mi pareva che Kleidemos si riferisse a quanto ho indicato.
giusto!
Se si parla di "Application manifest file" e di "assembly manifest file" parliamo di files xml sicuramente, vedi il riferimento che ho dato a Kleidemos che parla esplicitamente di manifest files. Se poi vogliamo parlare di struttura di un assembly è un altro discorso...può darsi abbia inteso male io, mi pareva che Kleidemos si riferisse a quanto ho indicato.
giusto!
Kleidemos
10-01-2003, 15:06
atragon, ottimo sito!
Sto leggendo i tuttorial!
Su che libro hai imparato?
Sto leggendo i tuttorial!
Su che libro hai imparato?
atragon
10-01-2003, 19:17
-- Eppoi perché fare un file separato se le informazioni le genera direttamente il compilatore? E l'autodescrittività...? Bah... illuminami.... >>
Direi che la spiegazione migliore la offre ancora il sito di MS:
Assembly manifests describe side-by-side assemblies. They are used to manage the names, versions, resources, and dependent assemblies of side-by-side assemblies. The manifests of shared assemblies are stored in the WinSxS folder of the system. Private assembly manifests are stored either as a resource in the DLL or in the application folder
Application manifests describe isolated applications. They are used to manage the names and versions of shared side-by-side assemblies that the application should bind to at run time. Application manifests are copied into the same folder as the application executable file or included as a resource in the application's executable file.
C'è un po' da ravanare sul sito ma si trova parecchia altra roba in proposito. Personalmente ho cercato di capire come utilizzare detti files in via programmatica ma, per le applicazioni che posso sviluppare io, non mi serve gran che....e non è facile (per me) :muro:
-- perché se esiste uno standard la Microsoft deve prenderlo e farne uno suo?
Eh...ipotesi 1) perchè voglio il meglio per gli sviluppatori e gli utenti. ipotesi 2) perchè se ho uno "standard proprietario" (che bella contraddizione in termini) lo controllo meglio...l'importante è che almeno una parte della ipotesi 1 sia comunque soddisfatta.....
--Su che libro hai imparato?
Ho iniziato nel 2000 con il primo libro uscito su C# "Presenting C#" un volumetto di 200 pg, ma il vero salto verso il mondo .NET l'ho spiccato grazie al testo di Gunnersonn "A programmers introduction to C#", di cui è uscita una ottima edizione aggiornata. Molto valido ho trovato anche "C# and the NET platform" di Troelsen mentre "Professional ASP.NET" è stato il primo testo che ho letto dedicato al mondo "pure web". Poi ne ho letti altri, alcuni incompleti...e ogni volta capisco quanto sono ignorante in materia :rolleyes: Questo framework è davvero molto ampio ed estremamente flessibile; se sopravviverà alle mire affaristiche di MS che è capace di rovinare tutto potrebbe essere davvero un gioiello, con qualche aggiustamento...d'altronde non bisogna lasciarsi prendere dall'entusiasmo...più aumenteranno le applicazioni più si vedrà quali sono i limiti di questa architettura e d'altronde anche DNA sembrava la panacea di tutti i mali. Cmq insisto a dire che è uno strumento molto promettente, chi ha un po' di tempo per il looking forward secondo me "deve" dargli un'occhiata senza pregiudizi.
Direi che la spiegazione migliore la offre ancora il sito di MS:
Assembly manifests describe side-by-side assemblies. They are used to manage the names, versions, resources, and dependent assemblies of side-by-side assemblies. The manifests of shared assemblies are stored in the WinSxS folder of the system. Private assembly manifests are stored either as a resource in the DLL or in the application folder
Application manifests describe isolated applications. They are used to manage the names and versions of shared side-by-side assemblies that the application should bind to at run time. Application manifests are copied into the same folder as the application executable file or included as a resource in the application's executable file.
C'è un po' da ravanare sul sito ma si trova parecchia altra roba in proposito. Personalmente ho cercato di capire come utilizzare detti files in via programmatica ma, per le applicazioni che posso sviluppare io, non mi serve gran che....e non è facile (per me) :muro:
-- perché se esiste uno standard la Microsoft deve prenderlo e farne uno suo?
Eh...ipotesi 1) perchè voglio il meglio per gli sviluppatori e gli utenti. ipotesi 2) perchè se ho uno "standard proprietario" (che bella contraddizione in termini) lo controllo meglio...l'importante è che almeno una parte della ipotesi 1 sia comunque soddisfatta.....
--Su che libro hai imparato?
Ho iniziato nel 2000 con il primo libro uscito su C# "Presenting C#" un volumetto di 200 pg, ma il vero salto verso il mondo .NET l'ho spiccato grazie al testo di Gunnersonn "A programmers introduction to C#", di cui è uscita una ottima edizione aggiornata. Molto valido ho trovato anche "C# and the NET platform" di Troelsen mentre "Professional ASP.NET" è stato il primo testo che ho letto dedicato al mondo "pure web". Poi ne ho letti altri, alcuni incompleti...e ogni volta capisco quanto sono ignorante in materia :rolleyes: Questo framework è davvero molto ampio ed estremamente flessibile; se sopravviverà alle mire affaristiche di MS che è capace di rovinare tutto potrebbe essere davvero un gioiello, con qualche aggiustamento...d'altronde non bisogna lasciarsi prendere dall'entusiasmo...più aumenteranno le applicazioni più si vedrà quali sono i limiti di questa architettura e d'altronde anche DNA sembrava la panacea di tutti i mali. Cmq insisto a dire che è uno strumento molto promettente, chi ha un po' di tempo per il looking forward secondo me "deve" dargli un'occhiata senza pregiudizi.
Kleidemos
10-01-2003, 19:20
che ne dici di C# Tutto&Oltre della Apegeo??????
atragon
10-01-2003, 19:48
Non lo conosco :mc: però, se non altro, è in italiano...la Apogeo non gode di cattiva fama quindi...ti direi comunque di integrare quello che studi con ciò che si trova sui vari siti, www.asp.net tanto per citarne uno che frequento e che ha un forum ben popolato...ma ce ne sono una marea ...se avessi tempo lo farei anche io più spesso :(
soalle
11-01-2003, 09:15
Originally posted by "atragon"
-- Eppoi perché fare un file separato se le informazioni le genera direttamente il compilatore? E l'autodescrittività...? Bah... illuminami.... >>
Direi che la spiegazione migliore la offre ancora il sito di MS:
Assembly manifests describe side-by-side assemblies. They are used to manage the names, versions, resources, and dependent assemblies of side-by-side assemblies. The manifests of shared assemblies are stored in the WinSxS folder of the system. Private assembly manifests are stored either as a resource in the DLL or in the application folder
Application manifests describe isolated applications. They are used to manage the names and versions of shared side-by-side assemblies that the application should bind to at run time. Application manifests are copied into the same folder as the application executable file or included as a resource in the application's executable file.
Un'ennesima porcata? Hanno fatto di tutto per rendere un file autodescrittivo facendogli contenere tutte le informazioni al suo interno (per non appoggiarsi al registro...) eppoi mettono un file che si può abbinare ad un assembly? Voglio andare a fondo a questa cosa...
Cioé se io compilo un file assembly dando delle direttive al compilatore tramite attributi (direttamente nel .cs) e descrivendo le sue proprietà (nome, versione, cultura, coppia di chiavi) eppoi ci metto un "manifest xml file" con informazioni diverse... il framework cosa fa??? Si impicca???
:muro:
Appena ho un po' di tempo mi ci dedico....
Per Atragon
Grazie per le informazioni se ne hai altre per illuminarmi sono ben lieto di ascoltarti....
Libro....
Ho usato "Programmazione avanzata" del già conosciuto Jeffrey Richter ed. MS Press; mi è sembrato ben fatto ma ti spiega non tanto come si usa il framework ma più come funziona al suo interno
Mie impressioni sul framework...
Già detto che per me il modello è ben fatto l'implementazione Microsoft mi lascia un po' perplesso su alcune cose...
Ciaociao
Soalle
-- Eppoi perché fare un file separato se le informazioni le genera direttamente il compilatore? E l'autodescrittività...? Bah... illuminami.... >>
Direi che la spiegazione migliore la offre ancora il sito di MS:
Assembly manifests describe side-by-side assemblies. They are used to manage the names, versions, resources, and dependent assemblies of side-by-side assemblies. The manifests of shared assemblies are stored in the WinSxS folder of the system. Private assembly manifests are stored either as a resource in the DLL or in the application folder
Application manifests describe isolated applications. They are used to manage the names and versions of shared side-by-side assemblies that the application should bind to at run time. Application manifests are copied into the same folder as the application executable file or included as a resource in the application's executable file.
Un'ennesima porcata? Hanno fatto di tutto per rendere un file autodescrittivo facendogli contenere tutte le informazioni al suo interno (per non appoggiarsi al registro...) eppoi mettono un file che si può abbinare ad un assembly? Voglio andare a fondo a questa cosa...
Cioé se io compilo un file assembly dando delle direttive al compilatore tramite attributi (direttamente nel .cs) e descrivendo le sue proprietà (nome, versione, cultura, coppia di chiavi) eppoi ci metto un "manifest xml file" con informazioni diverse... il framework cosa fa??? Si impicca???
:muro:
Appena ho un po' di tempo mi ci dedico....
Per Atragon
Grazie per le informazioni se ne hai altre per illuminarmi sono ben lieto di ascoltarti....
Libro....
Ho usato "Programmazione avanzata" del già conosciuto Jeffrey Richter ed. MS Press; mi è sembrato ben fatto ma ti spiega non tanto come si usa il framework ma più come funziona al suo interno
Mie impressioni sul framework...
Già detto che per me il modello è ben fatto l'implementazione Microsoft mi lascia un po' perplesso su alcune cose...
Ciaociao
Soalle
atragon
11-01-2003, 10:00
--Cioé se io compilo un file assembly dando delle direttive al compilatore tramite attributi (direttamente nel .cs) e descrivendo le sue proprietà (nome, versione, cultura, coppia di chiavi) eppoi ci metto un "manifest xml file" con informazioni diverse... il framework cosa fa??? Si impicca???
Bisognerebbe provare ....ritengo che MS abbia voluto proporre una soluzione registry indipendent, come hai detto tu ma, nel contempo, non volesse forzare la mano agli sviluppatori costringendoli ad abbandonare certi automatismi in fase di programmazione specialmente laddove non devi sharare gli assembly o remotizzare parti del progetto. A me non dispiace questa visione a 2 livelli....il punto, secondo me, lo hai imbroccato tu: come ci si comporta in situazioni ambigue? Bisognerebbe testare un po' la cosa, anche perchè la versione 1.1 del framework mi pare non ponga una risposta a questo dubbio, a meno che questo non ci sia già e noi non la vediamo. :)
Bisognerebbe provare ....ritengo che MS abbia voluto proporre una soluzione registry indipendent, come hai detto tu ma, nel contempo, non volesse forzare la mano agli sviluppatori costringendoli ad abbandonare certi automatismi in fase di programmazione specialmente laddove non devi sharare gli assembly o remotizzare parti del progetto. A me non dispiace questa visione a 2 livelli....il punto, secondo me, lo hai imbroccato tu: come ci si comporta in situazioni ambigue? Bisognerebbe testare un po' la cosa, anche perchè la versione 1.1 del framework mi pare non ponga una risposta a questo dubbio, a meno che questo non ci sia già e noi non la vediamo. :)
soalle
11-01-2003, 11:26
Originally posted by "atragon"
ritengo che MS abbia voluto proporre una soluzione registry indipendent, come hai detto tu ma, nel contempo, non volesse forzare la mano agli sviluppatori costringendoli ad abbandonare certi automatismi in fase di programmazione specialmente laddove non devi sharare gli assembly o remotizzare parti del progetto. A me non dispiace questa visione a 2 livelli....
E tutto il lavoro (che per me era una delle parti più interessanti del framework) per rendere gli assembly autodescrittivi va a farsi friggere???
Per me il volere prendere in considerazione tutte le casistiche dando ai programmatori cento strade diverse per ogni cosa (es: C# ha detto addio ai puntatori.... ma in reatà si possono usare...) può portare caos... non tanto per i tuoi progetti ma per quando devi analizzare progetti di altre persone...
In Java il modello è più rigido (e questo implica magari una maggiore difficoltà per realizzare qualcosa...) ma in compenso è omogeneo...
Potenzialmente il framework è molto bello maaaa.... voglio andare a fondo in questa cosa...
grazie per il confronto
Soalle
ritengo che MS abbia voluto proporre una soluzione registry indipendent, come hai detto tu ma, nel contempo, non volesse forzare la mano agli sviluppatori costringendoli ad abbandonare certi automatismi in fase di programmazione specialmente laddove non devi sharare gli assembly o remotizzare parti del progetto. A me non dispiace questa visione a 2 livelli....
E tutto il lavoro (che per me era una delle parti più interessanti del framework) per rendere gli assembly autodescrittivi va a farsi friggere???
Per me il volere prendere in considerazione tutte le casistiche dando ai programmatori cento strade diverse per ogni cosa (es: C# ha detto addio ai puntatori.... ma in reatà si possono usare...) può portare caos... non tanto per i tuoi progetti ma per quando devi analizzare progetti di altre persone...
In Java il modello è più rigido (e questo implica magari una maggiore difficoltà per realizzare qualcosa...) ma in compenso è omogeneo...
Potenzialmente il framework è molto bello maaaa.... voglio andare a fondo in questa cosa...
grazie per il confronto
Soalle
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.