Da pochi giorni è online la nuova versione del sito “di marketing” di SharePoint (cito testualmente dal post del blog del team di prodotto).
E’ realizzato su MOSS (sfrutta quindi le publishing feature per agevolare il lavoro degli editori) e fa ampio uso di Silverlight.
Eccolo qui :-)
Altri due link (grazie Betta!!)
http://technet.microsoft.com/en-us/library/cc263526.aspx
http://technet.microsoft.com/en-us/library/cc262506.aspx
Da notare le differenze, a parità di versione del browser, tra client a 32 e 64 bit (dovute nella maggior parte dei casi ai componenti ActiveX)
Segnalo questo articolo su Technet che illustra un percorso di migrazione per una farm SharePoint che si vuole “aggiornare” ai 64 bit.
Iniziare a valutare questi scenari è etremamente utile anche in vista di un futuro upgrade a SharePoint 2010, che come noto richiede host a 64 bit (qui per dettagli).
Varrebbe la pena solo per guardare il film (http://www.office2010themovie.com/).
La preview, disponibile a luglio, si riferisce alla versione client di Office 2010.
The Microsoft Office 2010 Technical Preview is a limited, invitation only program which will provide you with the opportunity to experience early, pre-release versions of Office 2010 which will include the following applications: Word 2010, Excel 2010, Outlook 2010, PowerPoint 2010, OneNote 2010, Access 2010, InfoPath 2010 and Publisher 2010.
Per chi è interessato… seguite il link (https://microsoft.crgevents.com/Office2010TheMovie/Content/Home.aspx)
L'annuncio è pubblico e contestuale al lancio della beta pubblica di Exchange 2010.
Dal post sul blog del team di SharePoint:
What happened to the Office piece of the name? We love MOSS. . . .
The first thing you’ll notice is that the MOSS acronym goes away with the new name since Office is no longer in the SharePoint official name. No one should worry that SharePoint doesn’t work great with Office 2010 since we removed Office from the name, just like people didn’t worry whether SharePoint was a great portal product when we removed Portal from the 2007 name.
The primary reason why we took Office out of the name - lots of folks associate the name Office with the Office client. We wanted to take the opportunity to reestablish the Office name and brand to be synonymous with the client suite. I say “Give the people what they Want” so everyone should immediately think of Microsoft Office = Office apps.
Don’t try to acronym Microsoft SharePoint Server to MSS since MSS is already taken by Microsoft Search Server. Just remember, SharePoint is SharePoint is SharePoint.
What about Windows SharePoint Services?
When you read through the announcement, you may be wondering what happened to Windows SharePoint Services. While we didn’t announcement anything new for WSS, and I want to assure you that we’re definitely working on a new v4 version of the product. It’s too early to drill into any of the details but WSS is getting a lot of new features and will be a great release. We’ll talk more about WSS at a later date.
So, what was announced?
Here are my key takeaways from the interview with Chris Capossela:
• Exchange 2010 will lead the way for the 2010 (previously referred by its codename “14”) wave of technologies and it will be available in the second half of 2009. You can download a beta today.
• Using Office Web applications, customers will be able to create, edit and collaborate on Office documents through a browser.
• IT professionals will be able to choose to either deploy and manage on-premises or hosted as a service.
• For developers, we are working on Open APIs, deep support for industry standards and developer tool support with Visual Studio 2010.
Degna di considerazione, dal mio punto di vista, la mancanza (ad oggi) di un acronimo per SharePoint Server (ex MOSS2007).
SharePoint is SharePoint?
Mmmhhh... senza dubbio.
Proviamo però a vedere cosa succede quando nei forum/NG/whatever quando arrivano domande tipo "Ho installato SharePoint 2010".
Non tutti scriveranno "SharePoint Services" e/o "SharePoint Server".
Vero, oggi non tutti scrivono "MOSS" e la domanda di precisazione sulla versione del prodotto segue a ruota... però non tutti non significa nessuno, e non significa "la maggior parte" :-)
Sinceramente credo che un "nickname" serva, eccome, e che se fosse pronunciabile sarebbe anche meglio.
... e a non cascare sempre negli stessi errori :-)
I file wsp sono gli archivi (provate a rinominarli in cab) che vengono utilizzati come formato di packaging per le solution SharePoint.
Non sempre vengono utilizzati (ed è un male!!), ma a volte usarli porta un bel po' di grattacapi.
Il sottotiolo di questo post è quindi: "come evitarsi mal di testa durante i deploy delle solution sharepoint".
La prima, semplice aspirina è una verifica sui nomi dei file inclusi nel package.
In fase di estrazione del package, infatti, i caratteri "speciali" non sono digeriti bene dal sistema e provocano l'errore parlante che segue: "failed to extract the cab file in the solution".
Errore che non viene intercettato in fase di creazione del wsp (e qui una funzionalità aggiuntiva al tool non ci starebbe male!) e che non viene dettagliato più di tanto in fase di deploy.
E... se passate mezz'ora a cercare il file incriminato, fate attenzione a non aver lasciato qualche "Copia di ItemDetails(1).gif" in giro sul vostro file system.
Argh :-)
Excel Services è un servizio estremamente interessante, anche per la rapidità di implementazione che mette a disposizione, ma ha diversi "inconvenienti" legati al rendering statico.
Il contenuto html restituito da ExcelRenderer.aspx (la pagina che, per intenderci, viene visualizzata scegliendo di aprire un file xlsx via browser) è caricato all'interno di un iframe, il che rende il resizing abbastanza problematico (*).
Esistono, comunque, soluzioni interessanti al problema.
Una di queste (che ho intenzione di applicare su un progetto in corso, prendendo l'occasione anche per introdurre l'utilizzo di JQuery in altri contesti) è presentata da Paul Grenier qui.
(*) Update... sorry, credo si capisse dal titolo, intendo comunque dire "...caricato all'interno di un iframe dalla Excel Web Access web part" :-P
Leggo con grande interesse sul blog di Matteo Emili un riferimento ad una serie di post di Brian Wilson (Microsoft Consulting UK) relativi alla virtualizzazione di infrastrutture SharePoint.
Inutile che dica io - di fatto ne sono un semplicissimo utilizzatore(*) - che l'utilizzo di ambienti virtuali porta enormi vantaggi, sia per il consulente-fornitore che ha modo di "portarsi dietro" ambienti server complessi, che per l'azienda che può consolidare stanze intere di rack-ventole-condizionatori in pochi moduli.
E' altrettanto chiaro, però, che un processo di virtualizzazione corretto deve essere studiato, valutato e contestualizzato sulla base dei servizi che si vogliono toccare.
Può essere d'aiuto, limitandosi a SharePoint, anche questo whitepaper pubblicato da Mircosoft.
-
(*) Utilizzatore al quale oggi si è quasi schiantata una macchina virtuale a 1 ora da una demo importante... che poi per la cronaca è andata bene ma che si è fatta, decisamente, sudare :-P
E' stata appena rilasciata la versione di marzo delle Visual Studio Extension per SharePoint. (come annuncia Paul Andrew).
Ecco la lista delle nuove caratteristiche (molte introdotte già con la precedente release):
- Can be installed on x64 Server OS machines running SharePoint x64. Previously only x86 Server OS could be used
- Separate build commands for package, deploy and retract are added as Visual Studio menu items
- WSP View improvements for consistency of deleting feature elements, merging features and adding event receivers to features
- Command line build, package and retract commands are included enabling continuous integration and build servers. Previously command line build of SharePoint projects was very difficult
- Refactoring support for renaming of Web Parts. Previously renaming a web part required changes in several files in the project
- Solution Generator can now generate solutions from publishing sites. Previously only regular sites could be generated
- Allowing partial trust BIN deployments of web parts
- New project item template for SharePoint RootFiles items
- Deployment will now optionally remove conflicting existing features on the development server prior to redeployment. Previously any feature name conflicts would result in an error
- Ancillary assemblies such as for business logic can now be added to the SharePoint Solution WSP
- Hidden features related to Site Definition projects are now shown in WSP View. They are no longer hidden
- For advanced users a fast deploy is included to update only the compiled assembly on the SharePoint development installation
- Deployment step logging is included
- The List Definition from Content Type template now allows for the creation of a List Definition Event Receiver
- The User Guide is now installed with the extensions instead of being a separate download
Todd Bleeker ha lanciato un sondaggio sul suo blog, chiedendo quale(i) tools gli sviluppatori SharePoint utilizzano di preferenza.
E voi?
Source: Preferred SharePoint Development Tool
E’ appena terminato l’MVP Global Summit 2009, che si è tenuto a Seattle (con una doppia puntata a Redmond in casa Microsoft).
Evento ricco di contenuto e di “contorno”, di sicuro una bella esperienza sotto tanti punti di vista.
Avrei voglia di raccontare un sacco di cose, ma purtroppo l’NDA dice no…
Steve Ballmer, come forse alcuni di voi hanno letto, ha annunciato che la vNext di SharePoint (quella che ad oggi molti chiamano Office 14) sarà “globally available” nel 2010.
Microsoft released an alpha version of Office 14 — which includes a new Office for Sales SKU — in January to selected customers. A first beta is looking like this summer, according to sources with whom I’m spoken recently. Microsoft is aiming to release Office 14 client and SharePoint Server 14 together. It also is aiming to ship the next version of Office Communications Server, tentatively known as OCS 2010, next year, as well.
Fonte: Mary Jo Foley @ ZDNet
Il futuro, più o meno immediato, si prospetta davvero denso di studio… il che in fondo è una delle cose che rendono entusiasmante il lavoro che faccio…
…oltre a certe foto :-)
Ho già parlato in passato delle problematiche di Application Lifecycle Management applicate a progetti SharePoint.
Il tema è “caldo”.
Su piattaforma SharePoint si sviluppano applicazioni a volte estremamente complesse dal punto di vista architetturale, e questa complessità si ripercuote necessariamente anche sul processo di sviluppo (team numerosi e da coordinare, tecnologie e tecniche disparate da integrare, ecc…).
A questo dobbiamo aggiungere che SharePoint si appoggia su un intero stack di componenti, e spesso gli interventi di personalizzazione coinvolgono modifiche a livelli differenti (quindi differenti sono le competenze e gli approcci necessari).
La landing page su MSDN relativa all’ALM su SharePoint si arricchisce pian piano di nuovi documenti e di nuovi contenuti:
- General Information
- Guidance
- Unit Testing P&P
- Team Foundation Build Guidance
- Coding Practices: Disposable Objects
Come spesso accade, la documentazione prodotta dalla “SharePoint Community Worldwide” (sotto diverse forme) è molto più nutrita (e, davvero, evviva aggregazioni e tagging :-)).
Gli argomenti trattati, per loro stessa natura, non sono sempre “univoci” nelle conclusioni (e se è per questo nemmeno negli approcci).
Più in generale è necessario considerare le guideline per quello che sono: non prescrittive in maniera assoluta… da contestualizzare, quindi, sulla base dei requisiti del progetto e del team.
Da qualche mese è stato annunciata l’iniziativa CMIS, con una bozza delle specifiche disponibile per il download:
The CMIS specification defines a standard "domain model" for an ECM system - a set of core concepts that all modern ECM systems have, like Object Types (which in SharePoint we call "Content Types"), properties, folders, documents, versions, and relationships - and the set of operations that can be performed on those concepts, like navigating through a folder hierarchy, updating a document, etc.
The specification does NOT try to include all the capabilities of an ECM system - because many of these are simply too different between ECM systems. But the specification does attempt to include the fundamental concepts that are (a) relatively common across current ECM systems, and (b) enable the common integration scenarios that we've heard from customers to date.
The specification then defines how to bind the CMIS "domain model" to two different web service protocols: SOAP (Simple Object Access Protocol), the web services protocol used by many ECM systems (including SharePoint), and Atom, a newer web services model used in many "Web 2.0" applications.
Dietro CMIS ci sono *piccole* realtà quali Microsoft, IBM ed EMC… :-)
Dal mio punto di vista, la validità e la maturità di uno strumento si notano in maniera particolare nel momento in cui vengono affrontate e risolte problematiche di integrazione con altri prodotti.
L’approccio può esere di varia natura: si va dalla definizione di uno standard (come in questo caso, almeno nelle prospettive) alla realizzazione e alla distribuzione di veri e propri componenti o estensioni applicative.
Scot Hillier, ad esempio, ha appena pubblicato un articolo su MSDN che illustra un’architettura estremamente interessante
Ecco i link all’articolo e al codice sorgente.
Da http://www.mssharepointconference.com/Pages/spc2009.aspx:
Microsoft is delighted to announce the SharePoint Conference 2009 - the premier worldwide conference dedicated to SharePoint and related technologies.
There’s an exciting mix in the plans for this year. This year’s conference will be looking towards the future with a broad array of deep content centered on the next version of SharePoint, codenamed SharePoint “14” and at the same time be firmly planted in the present, sharing real world experience and guidance to help you maximize your investment in SharePoint Server 2007.
p.s. E’ a Las Vegas… ci sono stato oltre 10 anni fa dicendo, di rientro: “Non credo ci tornerò mai”… he he, strana la vita :-)
Come noto, SharePoint Designer, nel momento in cui lavora “live” su un sito SharePoint, memorizza i file che l’utente produce (css, aspx, js,…) all’interno del content database.
Michael Washam segnala una Custom STSADM Extension(*) che estrae tali file, rimuove alcune “particolarità” inserite da SPD e li memorizza sul file system.
La cosa viene presentata come strumento di source control applicato agli artefatti realizzati con SPD.
Ehm… sinceramente mi sembra più una soluzione di “backup”… ma il discorso diventa davvero troppo complesso, soprattutto per la domenica mattina presto :-)
(*) Se non avete mai sentito parlare di custom stsadm extensions - ma allora non siete venuti a sentirci :-((( - non posso che rimandarvi al blog di Mr STSADM Extensions, aka Gary LaPointe. Sbizzarritevi pure!
More Posts
Next page »