From my presentation of Building WSP Packages Efficiently (schedule), the PowerPoint presentation and Visual Studio Project can be found below.
/keutmann
Doing SharePoint stuff
From my presentation of Building WSP Packages Efficiently (schedule), the PowerPoint presentation and Visual Studio Project can be found below.
/keutmann
Some new updates have been made for WSPBuilder...
The “Reference” folder
One of the new features of WSPBuilder, is the possiblility to add assemblies to the wsp package without getting them reflected upon. This means that there will not be created any safecontrols tags or permission policies for the assemblies. This will improve wsp build speed greatly for very large assemblies. So when you have some 3rd party assemblies that you would like to include into your wsp package, just add the 3rd party assemblies to a “Reference” folder under the GAC folder or 80\bin folder.
Project folder |
..\MyProject ....\GAC ......\Reference ........SomeVeryLarge.DLL ......MyOwnSmall.DLL ....\. |
As showing in the folder structure above, the SomeVeryLarge.DLL is located under the Reference folder and will therefore be included into the wsp package (and manifest.xml) but not reflected upon. This will greatly reduce the time needed to build the wsp package. However if there are UI controls in the SomeVeryLarge.DLL that will be used, you are forced to add it directly under GAC or 80\bin so the SafeControls tags can be created and added to the web.config otherwise you will get a security error. The MyOwnSmall.DLL is located directly under the GAC folder and therefore is reflected upon as normal.
Warning: There will not be created any security policies for the DLL’s in the “80\bin\Reference” folder, so you will need to manually change the policy settings in the SharePoint configuration files to allow the reference assemblies to be used from the 80\bin folder. When using the “GAC\Reference” folder, the assembly will be deployed to the Global Assembly Cache and therefore automatically be fully trusted.
Recycle the Windows SharePoint Services Timer
A new function in the WSPBuilder Visual Studio context menu have been added. This will recycle the Windows SharePoint Services Timer. (OWSTimer service). This function is intented to be used when developing SPTimerJobs, so you quicly can redeploy to GAC and recycle the Timer service from Visual Studio when testing.
Manually modifing the Manifest.xml
I had some request about being able to modify the manifest.xml and DDF file before building the wsp package. But the idea of WSPBuilder is that this should not be necessary. You should be able to do everything you need by use of the folder structure and wspbuilder.config file. But maybe I have missed something, so I would to hear from you if you have any case where you need to modify the manifest.xml file. Please e-mail me on carsten@keutmann.dk
/keutmann