Meetup Azure DevOps
Introduzione ad Azure DevOps e panoramica sulle principali funzionalità per il CI ed il CD del proprio software
Speaker: Simone Natalini
Gestire l’infrastruttura come se fosse codice, ha degli indubbi vantaggi, soprattutto in un team agile che ha più esperienze Dev piuttosto che Ops.
In questa sessione vi racconteremo la nostra esperienza, problemi, vantaggi e cosa abbiamo imparato.
Lo unified tooling è l’area di interesse DevOps che fonde pratiche di software development a quelle di system administration, con lo scopo di semplificare il processo di deployment di ambienti complessi. In questo talk vengono esposte le esperienze di un team di dev che è riuscito a gestire e replicare ambienti complessi, ricorrendo a strumenti e pratiche delle metodologie agili. Saranno evidenziati i vantaggi ottenuti e le problematiche riscontrate.
Grazie a Team Foundation Build è possibile adottare pratiche di integrazione continua nel proprio progetto. In questa presentazione viene introdotta la struttura di tfs build assieme alle tecniche base per effettuare una customizzazione della build.
Sviluppare un'applicazione web basata su ASP.NET Core nel mondo reale con Visual Studio Code
Codice della demo:
https://github.com/robymes/JoinTheExpert-WebDay
Livin' with Docker - dallo sviluppo alla produzionegiacomos
Presentiamo un caso di studio di un progetto web nato e cresciuto con Docker al centro della scena. Vedremo le soluzioni scelte durante tutto il percorso, partendo da docker-compose in locale, per arrivare a CoreOS e systemd in produzione, passando per la fase di continuous integration/build e il deploy.
Talk DockerOps 13-02-2016, Ferrara
DbUp è una libreria .NET che facilita il deploy delle modifiche allo schema del database di una applicazione. Tiene traccia degli scripts SQL che sono già stati applicati ed esegue gli script di modifica, necessari ad effettuare la migrazione del database.
Apache Maven - Gestione di progetti Java e build automationTiziano Serritella
Apache Maven è un tool per la gestione di progetti e build automation, utilizzato principalmente per progetti Java, il cui obiettivo è: semplificare, uniformare e automatizzare il processo di build di sistemi complessi.
In questa presentazione / guida verranno illustrati i problemi e le criticità dei tool di build automation tradizionali: make e Apache Ant, vedremo poi come installare e configurare Maven, le caratteristiche, gli obiettivi e i punti di forza del tool, le fasi del ciclo di vita, i plugin e i goal, le dipendenze, gli scope e la risoluzione di eventuali conflitti, i repository, i plugin "esterni" e i progetti multi-modulo.
La presentazione è ricca di esempi pratici.
Distribuire una libreria Java per usarla come dipendenza gradlePaolo Montalto
L'utilizzo di dipendenze software è una tecnica entrata già da tempo nella pratica quotidiana di ciascun buon programmatore. I suoi vantaggi sono indubbi ma non tutti sanno come funzionano le dipendenze e come sia possibile rendere disponibile pubblicamente la propria libreria.
In questo talk cerco di spiegare per quale motivo è importante utilizzare dipendenze software, come funzionano, perché può essere utile pubblicare le proprie librerie e come è possibile farlo, mostrando un caso reale basato su Gradle.
Welcome to the (state) machine @ ExploreDDD 2019Mauro Servienti
Stateless all the thing, they say. In the last few years we’ve been brainwashed: design stateless systems, otherwise they cannot scale, they cannot be highly available, and they are hard to maintain and evolve. In a nutshell stateful is bad. However complex software systems need to do collaborative processing, that is stateful by definition. Stateless myth busted! Collaborative domains deal with long running business transactions and need to interact with distributed resources. The traditional distributed transactions approach, even if tempting, is a time bomb.
This is when Sagas come into play. Sagas allow to model complex collaborative domains without the need for distributed transactions and/or orchestration across multiple resources. Join Mauro on a journey that aims to disclose what sagas are, how they can be used to model a complex collaborative domain, and what role they play when it comes to designing systems with failure and eventual consistency in mind.
(It’s all right, I know where you’ve been)
Designing a ui for microservices @ .NET Day Switzerland 2019Mauro Servienti
How do we design a UI when the back-end system consists of dozens (or more) microservices? We have separation and autonomy on the back end, but on the front end this all needs to come back together. How do we stop it from turning into a mess of spaghetti code? How do we prevent simple actions from causing an inefficient torrent of web requests? Join Mauro in building a Composite UI for Microservices from scratch, using .NET Core. Walk away with a clear understanding of what Services UI Composition is and how you can architect front end to be Microservices ready.
Meetup Azure DevOps
Introduzione ad Azure DevOps e panoramica sulle principali funzionalità per il CI ed il CD del proprio software
Speaker: Simone Natalini
Gestire l’infrastruttura come se fosse codice, ha degli indubbi vantaggi, soprattutto in un team agile che ha più esperienze Dev piuttosto che Ops.
In questa sessione vi racconteremo la nostra esperienza, problemi, vantaggi e cosa abbiamo imparato.
Lo unified tooling è l’area di interesse DevOps che fonde pratiche di software development a quelle di system administration, con lo scopo di semplificare il processo di deployment di ambienti complessi. In questo talk vengono esposte le esperienze di un team di dev che è riuscito a gestire e replicare ambienti complessi, ricorrendo a strumenti e pratiche delle metodologie agili. Saranno evidenziati i vantaggi ottenuti e le problematiche riscontrate.
Grazie a Team Foundation Build è possibile adottare pratiche di integrazione continua nel proprio progetto. In questa presentazione viene introdotta la struttura di tfs build assieme alle tecniche base per effettuare una customizzazione della build.
Sviluppare un'applicazione web basata su ASP.NET Core nel mondo reale con Visual Studio Code
Codice della demo:
https://github.com/robymes/JoinTheExpert-WebDay
Livin' with Docker - dallo sviluppo alla produzionegiacomos
Presentiamo un caso di studio di un progetto web nato e cresciuto con Docker al centro della scena. Vedremo le soluzioni scelte durante tutto il percorso, partendo da docker-compose in locale, per arrivare a CoreOS e systemd in produzione, passando per la fase di continuous integration/build e il deploy.
Talk DockerOps 13-02-2016, Ferrara
DbUp è una libreria .NET che facilita il deploy delle modifiche allo schema del database di una applicazione. Tiene traccia degli scripts SQL che sono già stati applicati ed esegue gli script di modifica, necessari ad effettuare la migrazione del database.
Apache Maven - Gestione di progetti Java e build automationTiziano Serritella
Apache Maven è un tool per la gestione di progetti e build automation, utilizzato principalmente per progetti Java, il cui obiettivo è: semplificare, uniformare e automatizzare il processo di build di sistemi complessi.
In questa presentazione / guida verranno illustrati i problemi e le criticità dei tool di build automation tradizionali: make e Apache Ant, vedremo poi come installare e configurare Maven, le caratteristiche, gli obiettivi e i punti di forza del tool, le fasi del ciclo di vita, i plugin e i goal, le dipendenze, gli scope e la risoluzione di eventuali conflitti, i repository, i plugin "esterni" e i progetti multi-modulo.
La presentazione è ricca di esempi pratici.
Distribuire una libreria Java per usarla come dipendenza gradlePaolo Montalto
L'utilizzo di dipendenze software è una tecnica entrata già da tempo nella pratica quotidiana di ciascun buon programmatore. I suoi vantaggi sono indubbi ma non tutti sanno come funzionano le dipendenze e come sia possibile rendere disponibile pubblicamente la propria libreria.
In questo talk cerco di spiegare per quale motivo è importante utilizzare dipendenze software, come funzionano, perché può essere utile pubblicare le proprie librerie e come è possibile farlo, mostrando un caso reale basato su Gradle.
Welcome to the (state) machine @ ExploreDDD 2019Mauro Servienti
Stateless all the thing, they say. In the last few years we’ve been brainwashed: design stateless systems, otherwise they cannot scale, they cannot be highly available, and they are hard to maintain and evolve. In a nutshell stateful is bad. However complex software systems need to do collaborative processing, that is stateful by definition. Stateless myth busted! Collaborative domains deal with long running business transactions and need to interact with distributed resources. The traditional distributed transactions approach, even if tempting, is a time bomb.
This is when Sagas come into play. Sagas allow to model complex collaborative domains without the need for distributed transactions and/or orchestration across multiple resources. Join Mauro on a journey that aims to disclose what sagas are, how they can be used to model a complex collaborative domain, and what role they play when it comes to designing systems with failure and eventual consistency in mind.
(It’s all right, I know where you’ve been)
Designing a ui for microservices @ .NET Day Switzerland 2019Mauro Servienti
How do we design a UI when the back-end system consists of dozens (or more) microservices? We have separation and autonomy on the back end, but on the front end this all needs to come back together. How do we stop it from turning into a mess of spaghetti code? How do we prevent simple actions from causing an inefficient torrent of web requests? Join Mauro in building a Composite UI for Microservices from scratch, using .NET Core. Walk away with a clear understanding of what Services UI Composition is and how you can architect front end to be Microservices ready.
Welcome to the (state) machine @ Xe One Day Enterprise ApplicationsMauro Servienti
Ultimamente ci hanno stressato come non mai che stateful è il male. Tutto deve essere stateless, altrimenti non scala, non può essere altamente disponibile, ed è complesso da manutenere ed evolvere. Nonostante questo i sistemi software complessi, essendo basati su processi collaborativi, sono per natura stateful. I processi collaborativi, noti anche come long running business transactions, necessitano di interagiscono con risorse distribuite. L’approccio tradizionale basato su transazioni distribuite, anche se allettante, è una bomba pronta ad esplodere.
Pane quotidiano per le Saghe. Le Saghe consentono di modellare sistemi complessi senza la necessità di transazioni distribuite e coordinamento esterno. Vedremo cosa sono le Saghe, come possono essere usate per modellare domini complessi, e che ruolo giocano quando progettiamo sistemi basati sui concetti di “design for failures” e “eventual consistency”
(It’s all right, I know where you’ve been)
All our aggregates are wrong @ NDC Copenhagen 2019Mauro Servienti
It always starts well. At first glance the requirements seem straightforward, and implementation proceeds without hiccups. Then the requirements start to get more complex, and you find yourself in a predicament, introducing technical shortcuts that smell for the sake of delivering the new feature on schedule.
In this talk, we’ll analyze what appears to be a straightforward e-commerce shopping cart. We’ll then go ahead and add a few more use-cases that make it more complex and see how it can negatively impact the overall design. Finally, we’ll focus our attention to the business needs of these requirements and see how it can shed light on the correct approach to designing the feature. Walk away with a new understanding on how to take requirements apart to build the right software.
Be like water, my friend @ Agile for Innovation 2019Mauro Servienti
L’acqua è quasi inarrestabile, basta un pertugio e si propaga. Basta un po’ di pressione e con facilità il pertugio diventa una voragine e lascia spazio ad una piena. La conoscenza e l’esperienza in un team possono essere come l’acqua. Il sapere deve poter scorrere senza freni, con solo degli argini che lo guidino al fine di evitare un’inondazione.
È possibile strutturare un’organizzazione al fine di garantire la diffusione del sapere? Quali sono i processi e gli strumenti che possiamo mettere in campo per essere certi che conoscenza ed esperienza siano diffuse, ma anche che non vi sia un’inondazione?
Lasciatevi trasportare da Mauro nei meandri di Particular Software, per scoprire come una realtà “dispersa” su 17 time zone gestisce collaborazione e condivisione del sapere. Analizzeremo sia i processi, che ci siamo creati, che gli strumenti digitali che usiamo quotidianamente.
Microservices architecture is it the right choice to design long-living syste...Mauro Servienti
Microservices all the thing! they say. Nowadays it seems that if architectures are not microservices based they are not worth the name. Is it really true? Do we really need a (micro)services based architecture?
We should design our systems with longevity, manutenability, and evolution simplicity in mind. Not hype. Long living systems are our primary goal. We'll analyze most common errors and we'll see how architecture can be a game changer in systems design.
Join Mauro in a journey that aims to disclose what it means to build a distributed system based on a (micro)services oriented architecture.
Titles, abstracts, and bio matter... oh my! @ Global Diversity CFP Day 2019Mauro Servienti
Sei uno studente che deve presentare una tesi? Un manager che deve presentare un report ai colleghi? Un esperto che deve presentare i risultati di uno studio ad una conferenza? O semplicemente avresti voglia di parlare al mondo di ciò che ti appassiona ma non sai da dove cominciare?
Living organizations, particular software @ do IT Better ParmaMauro Servienti
Siamo così abituati ad organizzazioni basate sul tradizionale organigramma che diamo per scontato che sia l'unica opzione.
Un approccio differente è possibile?
Quando sono entrato in Particular, era un'organizzazione tradizionale, sebbene distribuita. Avevamo manager e una gerarchia. Un anno dopo la decisione di rivoluzionare tutto. La miglior decisione di sempre. Intraprenderemo un viaggio che ci permetterà di scoprire che un modello organizzativo diverso è possibile, che un processo decisionale dall'alto verso il basso non è l'unica opzione e che possiamo organizzare la vita lavorativa intorno a quella privata in funzione di un ottimo life-work balance.
Welcome to the (state) machine @ Crafted SoftwareMauro Servienti
Stateless all the thing, they say. In the last few years we’ve been brainwashed: design stateless systems, otherwise they cannot scale, they cannot be highly available, and they are hard to maintain and evolve. In a nutshell stateful is bad. However complex software systems need to do collaborative processing, that is stateful by definition. Stateless myth busted! Collaborative domains deal with long business transactions and need to interact with distributed resources. The traditional distributed transactions approach, even if tempting, is a time bomb. This is when Sagas come into play. Sagas allow to model complex collaborative domains without the need for distributed transactions and/or orchestration across multiple resources. Join Mauro on a journey that aims to disclose what sagas are, how they can be used to model a complex collaborative domain, and what role they play when it comes to designing systems with failure and eventual consistency in mind. (It’s all right, I know we’re you’ve been)
PO is dead, long live the PO - Italian Agile Day 2018Mauro Servienti
Cosa succederebbe se i prodotti non fossero gestiti dai manager? O addirittura, cosa se i manager non ci fossero proprio? Chi si prenderebbe la responsabilità di definire la priorità nel backlog? In Particular Software non c’è una struttura gerarchica. La gestione dei prodotti, intesa come vera e propria product ownership, è responsabilità di tutti. Sembra quasi che gli internati siano anche i gestori del manicomio. Non è proprio distante dalla realtà. Oggigiorno sempre più aziende si stanno orientando verso strutture organizzative fluide. Che cosa si può fare per abilitare chiunque a prendere decisioni a qualsiasi livello? C’è un modo per condividere il processo decisionale? Guarderemo come è strutturata Particular Software al fine di abilitare tutto ciò. Analizzeremo come vengono risolti i problemi e quali processi e strumenti utilizziamo per prendere decisioni. Tutto senza infermieri, ooops, senza manager.
Design a UI for your Microservices @ Do IT BetterMauro Servienti
How do we design a UI when the back-end system consists of dozens (or more) microservices? We have separation and autonomy on the back end, but on the front end this all needs to come back together. How do we stop it from turning into a mess of spaghetti code? How do we prevent simple actions from causing an inefficient torrent of web requests? Join Mauro in building a Composite UI for Microservices from scratch, using .NET Core. Walk away with a clear understanding of what Services UI Composition is and how you can architect front end to be Microservices ready.
Microservices and pineapple on pizza what do they have in common - dos and ...Mauro Servienti
Microservices è una delle buzzword del momento. Sembra quasi che un'architettura a microservices sia fondamentale. È veramente così? Faremo un tortuoso viaggio tra le buzzword del momento cercando di districarci tra cosa è bene e cosa è meno bene, ma soprattutto perché. Obiettivo è quello di comprendere quali sono i limiti di certe scelte architetturali e quali gli errori da non commettere. Il tutto nell'ottica di garantire ai nostri sistemi 'lunga vita e prosperità' (cit.)
All our aggregates are wrong (ExploreDDD 2018)Mauro Servienti
It always starts well. At first glance the requirements seem straightforward, and implementation proceeds without hiccups. Then the requirements start to get more complex, and you find yourself in a predicament, introducing technical shortcuts that smell for the sake of delivering the new feature on schedule. In this talk, we'll analyze what appears to be a straightforward e-commerce shopping cart. We'll then go ahead and add a few more use-cases that make it more complex and see how it can negatively impact the overall design. Finally, we'll focus our attention to the business needs of these requirements and see how it can shed light on the correct approach to designing the feature. Walk away with a new understanding on how to take requirements apart to build the right software.
How do we design a UI when the back-end system consists of dozens (or more) microservices? We have separation and autonomy on the back end, but on the front end this all needs to come back together. How do we stop it from turning into a mess of spaghetti code? How do we prevent simple actions from causing an inefficient torrent of web requests? Join Mauro in building a Composite UI for Microservices from scratch, using .NET Core. Walk away with a clear understanding of what Services UI Composition is and how you can architect front end to be Microservices ready.
Cosa succederebbe se i prodotti non fossero gestiti dai manager? O addirittura, cosa se i manager non ci fossero proprio? Chi si prenderebbe la responsabilità di definire la priorità nel backlog? In Particular Software non c’è una struttura gerarchica. La gestione dei prodotti, intesa come vera e propria product ownership, è responsabilità di tutti. Sembra quasi che gli internati siano anche i gestori del manicomio. Non è proprio distante dalla realtà. Oggigiorno sempre più aziende si stanno orientando verso strutture organizzative fluide. Che cosa si può fare per abilitare chiunque a prendere decisioni a qualsiasi livello? C’è un modo per condividere il processo decisionale? Guarderemo come è strutturata Particular Software al fine di abilitare tutto ciò. Analizzeremo come vengono risolti i problemi e quali processi e strumenti utilizziamo per prendere decisioni. Tutto senza infermieri, ooops, senza manager.
Shipping code is not the problem, deciding what to ship it is!Mauro Servienti
This document discusses an organization's approach to prioritizing work and developing software. It emphasizes focusing on solving clear problems rather than executing on estimates or deadlines. Work is organized into buckets or strategies, each with a dedicated squad prioritizing issues. Issues go through an intake process to clearly define the problem before being selected for a cross-functional task force to implement a solution. The goal is for squads to proactively address problems rather than reactively execute work.
GraphQL - Where are you from? Where are you going?Mauro Servienti
GraphQL, inventato da Facebook per risolvere un problema molto specifico, è diventato uno standard. Le applicazioni client lo utilizzano per leggere e manipolare i dati esposti dai server back-end. È così flessibile che recentemente GitHub l'ha adottata per tutte le sue API. Il paradigma è semplice e tuttavia potente tale da consentire la manipolazione flessibile e la loro composizione da molte fonti diverse. Mauro offre in questo intervento un'introduzione a GraphQL, partendo da una breve storia e poi analizzando come GraphQL risolva i tipici problemi in cui i progettisti API e i loro consumer si possono imbattere.
Dall'idea al deploy un lungo viaggio che passa per git flow e semverMauro Servienti
Parliamo tanto di DevOps e ci concentriamo sui tool senza soffermarci a pensare che DevOps è principalmente una metodologia. Lo scopo è rendere l'intera filiera il più fluida e lineare possibile, rimuovendo impedimenti e cercando di prevenire e anticipare problemi.
Possiamo costruire tutto il processo di sviluppo, partendo dai vagiti iniziali del backlog per finire che il deploy fisico in ottica DevOps? Il processo ha impatto sulle scelte tecniche? Pratiche come SemVer e GitFlow hanno invece un impatto sul backlog?
Analizzeremo l'intero processo di sviluppo di Particular Software, dalla gestione del backlog al deploy automatico in produzione, con lo scopo di evidenziare come pratiche che sembrano disconnesse abbiano invece impatto su tutta la filiera.
This document discusses different approaches to designing a user interface for a microservices architecture. It begins by proposing a domain model decomposition with individual services owning pieces of product data. However, this poses issues for users who need an aggregated view. An alternative presented is to have individual services cache normalized data and compose a view model at the edge. Later approaches incorporate client-side messaging, hosting the composition engine in MVC, and using view components to give services more ownership over vertical slices of the UI. The key takeaways are that the UI structure can be defined at the edge while still keeping domain responsibilities clear across services.
The road to a Service Oriented Architecture is paved with messagesMauro Servienti
One of the options on the table when implementing a Service Oriented Architecture (SOA), or the communication style across multiple microservices, is based on messages and a service bus. This talk will drive you through the basic SOA building blocks, introduce message based architectures, and will connect the dots between technology and architectural principles through some samples using NServiceBus.
The road to a Service Oriented Architecture is paved with messages
VS Package @ CD2008
1. VSX Tales: Estendere Visual
Studio
VSPackage
dalla A alla VS
Mauro Servienti
Microsoft MVP - Visual C#
Software Mason @ Managed Designs S.r.l.
mauro.servienti@manageddesigns.it
3. Perchè estendere Visual Studio
• Compiti ripetitivi;
• Siamo pigri e usare sw diverso ci
pesa;
• Integrare “new stuff” nella solution
su cui stiamo lavorando;
4. Alcuni esempi di estensioni
• Domain Specific Language(s)
• Database Project
• Visual C#
5. Il “guscio”
Con l’uscita di Visual Studio 2008 viene introdotto il
concetto di Shell:
Integrated Isolated
• Integrazione con • Esecuzione Side by Side;
l’edizione di VS presente; • Custom look & feel;
• Installazione di un “VS • Pieno accesso ai servizi
Redist”; di VS;
• Ideale per lo sviluppo di • Possibilità di nascondere
language service e/o tool funzionalità;
di supporto;
6. Gli Entry Point
• Macro
• AddIn
• Visual Studio Package;
• Language Service/System;
10. Visual Studio 2008 SDK: Docs
• “documentazione” (lower d):
– “...spiega nel dettaglio cosa sia un
mattone dando per scontato che questo
sia sufficiente per costruire una casa...”;
– Disallineata dalla versione di VS;
– Esempi lasciano molto a desiderare;
11. Visual Studio SDK: MPF
• MPF: Managed Package Framework:
– Un set di API sopra gli Interop
Assemblies;
– Semplifica di molto lo sviluppo:
• da 5k a poche decine di linee di codice;
– Non è un set di assembly...;
12. Visual Studio SDK: Experimental Hive
• Pargonabile ad un ambiente virtuale;
– SoftwareMicrosoftVisualStudio9.0Exp;
– Protegge la nostra installazione di VS;
• Reset tool;
– Tip: se cambiate profilo utente è
necessario eseguire un reset;
• /RANU: Run As Normal User
13. VSSDK Assist
• Progetto di supporto open source:
– http://www.codeplex.com/vssdkassist
• Aggiunge “funzionalità” ai progetti
esistenti
– Gli scheletri creati sono decisamente più
ricchi;
– Aggiunge tool per il debug;
15. VSPackage: the basics
• È un contenitore di servizi;
– Può essere un Project System;
– Può essere un Language System;
• Offre supporto per:
– Branding: eg. l’about box di VS;
– Persistenza dello stato del progetto;
– Intergrazione nelle Opzioni di VS
– Supporto per “custom properties”;
16. DLK & PLK
• DLK: Dev Licence Key
– Installata insieme all’SDK;
– Consente di eseguire tutte le operazioni di
sviluppo;
– Non consente il deploy;
• PLK: Package Load Key (sparirà?)
– Da richiedere on line (free);
– Univoca per VSPackage;
• Company, Version, PkgName, TargetVersion
– Firma i VSPackage;
• VS non carica il package se non valida;
18. Anatomia: gli attributi
• [Guid]:
– univoco per VSPackage;
– È COM: ogni cosa è un Guid/CLSID;
• [InstalledProductRegistration]:
– Fornisce le informazioni di supporto per
la registrazione;
• [ProvideLoadKey]:
– Fornisce le informazioni per il
caricamento del package: tra cui la PLK;
19. Anatomia: i Guid
• Siamo nel regno di COM:
– Identifichiamo tutto con un Guid/CLSID;
• Cerchiamo di cavarcela:
– const string gVSPkgString = “...";
– const string gVSPkgCmdSetString =
“…";
– static readonly Guid gVSPkgCmdSet =
new Guid(gVSPkgCmdSetString);
20. Anatomia: le risorse
• Pro:
– Supporto per la localizzazione;
• Contro:
– Opzionali, ma non per tutto...;
– Formati “diversi” per cose “uguali”;
21. Anatomia: Build
• Compila il package:
– csc.exe EmptyVSPackage ->
EmptyVSPackage.dll
• Installa le informazioni di configurazione del
package nell’Experimental Hive:
– RegPkg.exe
/root:SoftwareMicrosoftVisualStudio9.0Exp
"/pkgdeffile:EmptyVSPackage.pkgdef"
"EmptyVSPackage.dll"
• Esegue il deploy nell’Experimental Hive
– RegPkg.exe
/root:SoftwareMicrosoftVisualStudio9.0Exp
/ranu /codebase "EmptyVSPackage.dll"
24. ProjectSystem: Agenda
• I Template;
• Il Package;
• La ProjectFactory;
• Il ProjectNode;
• Il FileNode;
• Le FileNodeProperties;
25. ProjectSystem: I Template
• Definiscono la struttura iniziale:
– di un progetto (ProjectTemplate)
– di un elemento (ProjectItem);
• Sono file zip:
– %ProgramFiles%Microsoft Visual Studio 9.0Common7IDE
• Nuove “Build Action”:
– ZipProject e ZipItem;
• vstemplate:
– Il tag <ProjectType>: fondamentale;
– Il <TemplateContent>;
– Le “sostituzioni”;
26. ProjectSystem: Il Package
• L’attributo: ProvideProjectFactory
– Informa VS di quale sia il System.Type
deputato a creare il progetto;
• La registrazione delle factory;
27. ProjectSystem: La ProjectFactory
• Una classe che deriva da ProjectFactory
• Definizione di un Guid;
• Eseguire l’override di CreateProject;
– Creazione della propria istanza di project;
– Impostazione del service container:
• senza il quale non saremmo in grado di
comunicare con l’ambiente;
• Qui è anche possibile definire le
proprietà custom del progetto;
28. ProjectSystem: Il ProjectNode
• Una classe che deriva da ProjectNode
– Rappresenta un nodo nel Solution Explorer;
• Override(s) sine qua non:
– CreateFileNode;
– AddFileFromTemplate;
– ProjectGuid;
– ProjectType:
• Vi ricordate il tag <ProjectType> nel file .vstemplate?
• Tip:
– CanProjectDeleteItems = true
– Le icone...;
– Le custom properties;
29. ProjectSystem: Il FileNode
• Una classe che deriva da FileNode
• Override(s) sine qua non:
– CreatePropertiesObject;
• Tip:
– Le icone...;
30. ProjectSystem: Le FileNodeProperties
• Una classe che deriva da
NodeProperties;
• Espone proprietà pubbliche che VS
visualizza nella property grid;
• È possibile inserire tutte le proprietà
che vogliamo associare al nostro
documento;
– Tip: sono persistite nel file di
progetto, avete quindi bisogno di
mappare tag/attributi custom;
33. Editor: LogicalView & PhysicalView
• Un singolo documento/file può avere più
modalità di visualizzazione: LogicalView
• Le modalità di visualizzazione hanno uno o
più editor collegati: PhisycalView
• Alcuni esempi:
– Windows Form:
• Design View
• Code View;
– Web Designer:
• Design View;
• HTML View;
• Code View
34. Editor: EditorFactory
• Mappa Logical e Physical views:
– Distingue la tipologia (Type) di editor in
base alla logical/physical view;
• Gli attributi:
– ProvideEditorFactory;
– ProvideEditorLogicalView;
– ProvideEditorExtension;
35. Editor: EditorPane
• E’ il prodotto di una EditorFactory;
• IWin32Window property;
• Può implementare IVsToolboxUser
– IsSupported: determina se un
determinato “tool” sia supportato o
meno d’editor corrente;
– ItemPicked: l’IDE ci informa che un
“tool” è stato scelto: DblClick / enter;
39. Toolbox: Agenda
• Gli attributi;
• Gli eventi;
• System.Reflection;
• CustomToolboxItem;
40. Toolbox: attributi
• ProvideToolboxItems:
– Version:
• Determina il comportamento della cache
– NeedsCallBackAfterReset:
• Dovrebbe scatenare l’evento
ToolboxUpgraded...io non ci sono riuscito;
41. Toolbox: Gli Eventi
• ProjectPackage.ToolboxInitialized:
– Invocato durante il processo di
inizializzazione della toolbox;
– E’ qui che dobbiamo inserire i nostri
ToolboxItem/Category
• ProjectPackage.ToolboxUpgraded:
– Invocato al cambio di “versione”;
– Rimuoviamo e reinseriamo i
ToolboxItem/Category
42. Toolbox: System.Reflection
• Caricamento degli elementi:
– Fx2.0:ToolboxService
(System.Drawing.Design);
• ToolboxItemAttribute;
• ToolboxBitmapAttribute;
• ToolboxItemFilter
• DisplayName: brutalmente ignorato;
• Tip:
– Siete in un AppDomain diverso da quello
dell’IDE AssemblyResolve issue(s);
43. Toolbox: CustomToolboxItem
• Essenziale per identificare i nostri
elementi;
• Possibilità di estendere le
informazioni inserite nella Toolbox;
• Tip:
– Deriva da ToolboxItem;
– Deve essere serializzabile;
– ToolboxItem implementa a “modo suo”
ISerilizable
46. Visual Studio è COM
• Marshaling;
• Rilascio delle risorse;
• HRESULT vs. Exception;
• La gestione dei Guid;
47. ...ma non è solo COM
• Trapping/Masking delle Exception;
• Il Discovery dei servizi;
• La documentazione;
• Le discrepanze:
– Task ripetuti;
– Linking dei template;
– Duplicazione delle risorse;