Sunday, October 12, 2008
This project is all about making SharePoint/MOSS XHTML compliant.
· Get SharePoint 2007 to validate according to W3C XHTML 1.0 Strict.
· Google-optimize SharePoint to gain the best search ranking.
· Enhanced accessibility.
· Makes it possible for SharePoint to follow the American regulation 508 and the Danish regulation based on WCAG AA.
· Better control over the HTML output of SharePoint, to ease the frontend development process.
Friday, October 03, 2008
- Feature collection now uses try catch on invalid features.
- Title used to show names of JobDefinitions.
- SPEventReceiverDefinition implemented. EventReceivers are now browsable.
/Happy SharePoint object model browsing :o)
Saturday, August 30, 2008
WSPBuilder will first look for the general config file, then the local project and last the command line arguments.
Wednesday, August 27, 2008
The previous version of WSPBuilder 0.9.8.0822 was a memory eating monster, now the memory foot print has been greatly reduced to a more acceptable level.
The reason for this was that Mono.Cecil uses a lot of memory to load the assemblies. Therefore when loading reference assemblies and base class assemblies like System.Web the memory consumption exploded. Now every assembly gets unloaded right after it has been used.
Friday, August 22, 2008
In the beginning of 2007 I was tired of writing the wsp manifest.xml file and defining the DDF file by hand. I really needed a tool to auto generate this. I tried one of the first tools on the internet that someone had made (I have forgotten where),however it was written in VBscript and only implemented some very basic functionality. But it made me discover that the structure of the wsp file is simply a reflection of what goes into the 12 hive. Therefore it was clear to me that the next step was to simply make it a full blown C# project. Still I needed to be sure to cover all of the possibilities that wsp schema had to offer. Luckily Microsoft provides a xml schema definition for the manifest.xml file. This made it possible to auto generate a C# class library that would serialize into a manifest.xml file. Then the only thing that I had to do now was to fill in the code and serialize the objects. But I was not home yet, I needed something to create the CAB file (WSP). I was able to choose from the makecab.exe application provided by Microsoft or use the CabLib.dll project created by Elmue. In the spirit of GPL and for full control of the Cab file creation I went for the Elmue project.
Deployment (August 2007)
Here the power of the GPL license really comes into effect. Chris Doty created the deployment part of WSPBuilder and submitted it to me. First it was made as a independent console application WSPDeployer.exe and later on it was merged into the WSPBuilder application.
WSPBuilder Extensions (January 2008)
Tom Clarkson really did a big contribution here. He basically created the WSPBuilder Extensions project with Visual Studio project and item templates and an Visual Studio Addin with a MSI install program with it. After some minor modification the first version of WSPBuilder Extensions was born. In the following versions the Extensions has been improved and the Visual Studio Addin has been rewritten to a more professional look and the functionality extended.
Mono.Cecil (may 2008)
The WSPBuilder was having some issues with reflection on assemblies in order to be able to create the SafeControls tags in the manifest file. If an assembly was located in the Global Assembly Cache, the .NET framework would always pick up this assembly and not the newly build assembly from the project, therefore resulting in a possible incorrect manifest file. Also assembly references was a big problem for many users of WSPBuilder. This was because the users had the tendency to put reference assemblies other places on their system and because of this the .NET framework was not able to find them. With the Mono.Cecil project written by Jb Evain, WSPBuilder is now able to load the assemblies even that a copy existed in GAC and reflect on them without having to load all of the referenced assemblies.
I want to thank all the people that have helped to improve the WSPBuilder product by using, testing and reporting bugs. Microsoft for providing the codeplex.com site that enables you to use team foundation source control with your Visual Studio Environment and also for hosting the WSPBuilder project.
Even that WSPBuilder has not reached its full first version yet, it’s nearly completed. There are still some bugs to be fixed and documentation to be made, but overall it should implement every possible scenario that you are able to make with the Windows SharePoint Package (WSP).
This time some major issues with SecurityAttibutes reflection has been solved and also reflection on assemblies to created the relevant SafeControl tags has been implemented. Now the WSPBuilder with the Mono.Cecil project, is better able to create a correct manifest.xml than it was with the normal .NET assembly reflection. The only downfall is that WSPBuilder is a little bit slower than before, but it should not be notable. Also the Assembly Element tags has been moved to the top of the manifest.xml file in order to ensure that assemblies is deployed first, this seems to solve a problem in rare occasions.
- Assembly element tags in the manifest.xml is placed in the top of the manifest.xml file.
- Resolvement of assemblies is now supported with Mono.Cecil in order to create relevant SafeControl tags. Use the -DLLRefencePath argument to resolve referenced assemblies.
- Bug fixed where the 80\WPResources was not included-.
- Bug fixed where the security attributes was not reflected correctly.
Take care :o)
Tuesday, July 22, 2008
A new version of WSPBuilder Extensions 1.0.3 for Visual Studio has been released on codeplex.
- Now uses the WSPBuilder 0.9.8.0408 version.
- The Addin has been totally rewritten and should now work properly. A number of bugs fixed.
- The WSPBuilder menu is now available from the Tools menu.
- The shortcut key bug now fixed.
- A new command "Copy to GAC" Added.
- You are now able to use “Copy to 12 hive” on project, selected folder or files under the 12 hive folder.
- The WebPart Item template has been updated.
Note: To use the WSPBuilder Extensions on a x64 system, replace the CABLIB.DLL x86 version, found in “Program Files\WSPTools” folder and Global Assembly Cache, with a CABLIB.DLL x64 version. Look for the CABLIB.DLL x64 version in a previous x64 release of WSPBuilder.
Wednesday, May 21, 2008
Feature ID 22A9EF51-737B-4ff2-9346-694633FE4416
In lack of documentation on this feature and the properties it contains, I did some reflection on the class. But the inner workings of the class is obfuscated and therefore I was only able to get the properties declared as constants. I have not tested all of the properties, so I actually do not know if they will work.
Properties in the PublishingFeatureHandler feature that you are enable to set in the ONET.XML
<!-- Publishing feature -->
<Property Key="WelcomePageUrl" Value="$Resources:cmscore,List_Pages_UrlName;/Default.aspx" />
<Property Key="PagesListUrl" Value=""/>
<Property Key="AvailableWebTemplates" Value=""/>
<Property Key="AvailablePageLayouts" Value=""/>
<Property Key="SimplePublishing" Value="true" />
|Name||Type||Default value Simple publishing||Default value Complex publishing||Description|
Add the css file to the application pages resided in the layouts folder.
Syntax format: ~SiteCollection/<pagelayout path1>:~SiteCollection/<pagelayout path2>:~SiteCollection/<pagelayout path3>Example..:
AvailableWebTemplates Key Format is:LCID-[sitetemplatename][#sitetemplatenumber];LCID-[sitetemplatename][#sitetemplatenumber];LCID-[sitetemplatename][#sitetemplatenumber]
|SimplePublishing||bool||If not defined, the default value is true. Specifies the setup with simple or complex publishing configurations.|
Possible values for VersioningSettings is: Major, MajorAndMinor, None
Defines the page that will act as the startup page.
Friday, April 11, 2008
WSPBuilder.exe version 0.9.8.0408 (experimental)
Note! This version is a complete rewrite of the assembly reflection done in WSPBuilder and therefore the experimental status.
Assembly reflection is now done with the Mono.Cecil project. This enables the WSPBuilder to reflect on assemblies without having to load all depending assemblies.
-DLLReferencePath are now obsolete, because there is no need for load depending assemblies, but it still may be used in the future.
The WSPBuilder are not able to detect if a control is inherited from a WebControl, therefore there may be more safecontrols tags in the manifest. This is because that depending assemblies are not loaded.
Code Access Security declaration in the manifest.xml have been improved for DLLs in the 80\Bin folder.
The "assembly is already in the GAC bug" have been solved. WSPBuilder now only loads assemblies from the project folder and do not care about the assemblies in the Global Assembly Cache.
-PermissionSetLevel do NOT support Unrestricted PermissionSet. Because its not possible to add this to the manifest.xml.
Note that there are two versions on codeplex.
WSPBuilder Extensions ver. 1.0.1 - Visual Studio Addin, wspbuilder.exe 0.9.8.0206 is included in this package.
WSPBuilder.exe version 0.9.8.0408 (experimental) - Only exe file and libraries.
The x64 version of WSPBuilder.exe will be added to codeplex soon.
Thats it for today.
Wednesday, February 06, 2008
Now the first version of WSPBuilder Extensions is ready. It has been a long road up the hill and a lot of hours spend at home after my day work to get this first version done.
I want to specially thank Tom Clarkson for doing the Visual Studio Templates, he has done an awesome work on creating the templates and I would never have been able to finish it without him.
It has also been great that the community contributes to the WSPBuilder project with error reports and suggestions for new features.
The WSPBuilder Extensions ver. 1.0.0 (RC) supports Visual Studio ver. 2005 and 2008 and comes in a nice MSI install package.
The WSPBuilder.exe contains a lot of functionality that I simply did not have time to implement into Visual Studio. Also WSPBuilder.exe does not read the Visual Studio project file but still relies on the project folder to build the WSP file. Therefore you may not see the file in Visual Studio because it’s excluded from the project file, but it still gets build into the WSP file.
After install start your Visual Studio, and create a new project.
Now create a new SharePoint Feature.
Finally build the project and deploy it.
Try it out and tell me what you think.