** Updated: http://kwizcom.blogspot.com/2010/08/upgrading-customized-solutions-in.html **
This morning KWizCom’s VP R&D, Shai Petel, hosted an extremely well received session at Microsoft’s SharePoint 2009 conference in Vegas.
The session covered three topics: building a new solution, upgrading an existing solution and version management. Rather than speak about theory, Shai’s presentation gave attendees a firsthand perspective, based on an actual migration he did himself.
Read more and/or see the presentation Shai gave at SPC ‘09 here.
Tuesday, October 20, 2009
Monday, October 19, 2009
News on SharePoint 2010 from SPC09
Here are some things i picked up at the SharePoint conference 09 (announcing SharePoint 2010):
* No more SharePoint "hive" (12 folder)... from now on say SharePoint Root! VSeWSS2010 will redirect it to 12 folder or 14 folder or any other folder used based on your current running version of SharePoint.
* VSeWSS (Visual Stuio extensions for WSS) 2001 supports 1 and only 1 package per project. But in each project you can have as many features as you like.
The cool thing is that the features are shared between projects in the same solution! So you can include a feature from 1 project in several other deployment packages with all of its resources.
* Sandbox solutions
Now you can deploy solutions in a site collection, and not on the farm.
This means that the solution will be deployed and installed on that specific site collection.
Code in sandboxed solution runs inside a seperate process - not on W3WP, and has no direct access to SharePoint API. Instead it uses another proxy process that provide it with limited access to the SharePoint API. You will be able to do almost anything within your site collection, while you will have no access to remote site collections and read only acccess on your current web application and farm.
Some customizations are not supported within a sandbox solution, like code based workflow, site definitions etc.
Installing a sandbox solution is very simple - i will publish a how to with images soon but for general idea, you just need to upload it to your site collection solutions gallery (library) and activate it!
Sandbox solutions do not deploy any files anywhere! On first access to the solution code the SharePoint will load its code and resources into memory and will run it from memory.
* VSeWSS allows you to select if you want to allow the solution to be sandboxed. Choosing so will make visual studio validate that all my elements are supported within a sandbox solution - and promt me if I add something that is not supported.
* Visual web part - or is it?
The good: This is a new VSeWSS 2010 project template that allows you to create a user control as a web part. Simple, easy and long overdue.
The bad: This is not really a visual web part, its just a good old web part that loads a user control as its only child. At least all files (web part, user control files) are created, grouped and deployed for you.
The ugly: our old web parts we designed without a UI editor... we did our best though :)
I will post more as the SPC09 continues,
Shai Petel.
* No more SharePoint "hive" (12 folder)... from now on say SharePoint Root! VSeWSS2010 will redirect it to 12 folder or 14 folder or any other folder used based on your current running version of SharePoint.
* VSeWSS (Visual Stuio extensions for WSS) 2001 supports 1 and only 1 package per project. But in each project you can have as many features as you like.
The cool thing is that the features are shared between projects in the same solution! So you can include a feature from 1 project in several other deployment packages with all of its resources.
* Sandbox solutions
Now you can deploy solutions in a site collection, and not on the farm.
This means that the solution will be deployed and installed on that specific site collection.
Code in sandboxed solution runs inside a seperate process - not on W3WP, and has no direct access to SharePoint API. Instead it uses another proxy process that provide it with limited access to the SharePoint API. You will be able to do almost anything within your site collection, while you will have no access to remote site collections and read only acccess on your current web application and farm.
Some customizations are not supported within a sandbox solution, like code based workflow, site definitions etc.
Installing a sandbox solution is very simple - i will publish a how to with images soon but for general idea, you just need to upload it to your site collection solutions gallery (library) and activate it!
Sandbox solutions do not deploy any files anywhere! On first access to the solution code the SharePoint will load its code and resources into memory and will run it from memory.
* VSeWSS allows you to select if you want to allow the solution to be sandboxed. Choosing so will make visual studio validate that all my elements are supported within a sandbox solution - and promt me if I add something that is not supported.
* Visual web part - or is it?
The good: This is a new VSeWSS 2010 project template that allows you to create a user control as a web part. Simple, easy and long overdue.
The bad: This is not really a visual web part, its just a good old web part that loads a user control as its only child. At least all files (web part, user control files) are created, grouped and deployed for you.
The ugly: our old web parts we designed without a UI editor... we did our best though :)
I will post more as the SPC09 continues,
Shai Petel.
Client API in SharePoint 2010
With REST, ASP.NET Ajax, Microsoft.SharePoint.Client.dll new API - and of course silverlight all built into the new platform, our next generation of applications will have to have a major UI facelift.
You can expect much less page refreshes, more responsiveness and easier development proceess for more complex UI scenarios.
You have to keep in mind that SP2010 wiki pages do support web parts, but do not support postbacks!
So using these client-side calls will be almost mandatory if you wish to provide advanced controls and feature rich compoents in your pages.
You can expect much less page refreshes, more responsiveness and easier development proceess for more complex UI scenarios.
You have to keep in mind that SP2010 wiki pages do support web parts, but do not support postbacks!
So using these client-side calls will be almost mandatory if you wish to provide advanced controls and feature rich compoents in your pages.
Subscribe to:
Posts (Atom)