Useful Visual Studio External Tools


Introduction

I have been meaning to document this for a while. Every time I set up a new machine I have to check the configuration of my Visual Studio external tools.

External Tools? If you don’t know what I am talking about then take a look at the image below.

image

Currently I have the following External Tools:-

  • Create GUID – this allows me to quickly get a new GUID when creating all those SharePoint resources, including Content Types, List Schemas, Feature Receivers etc.
  • Get Public Key Token – this uses the .Net Framework Signing Tool (sn.exe) to get the Public Key token, although with the new SharePoint tools in Visual Studio this isn’t needed so much there are always those odd occasions.
  • Get Full Assembly Name – This is used lots particularly when having to hack together various SharePoint Xml files or Entity Framework resource connection strings. I can’t take credit for this one, Sahil Malek – http://blah.winsmarts.com/2009-12-SharePoint_Productivity_Tip_of_the_day.aspx), did all the hard work.
  • Get IIS Web Application Information – This saves me so much time when debugging code especially, feature receivers, application page, web part code. The tool will display a list of all the Web Applications and there Process ID (PID).

Setting up the Tools

Create GUID Tool

First of all locate the Guidgen Tool which should be found in your Windows SDK folder. The path will depend on the Windows Version you are running, this one is for Windows 2008 R2. “C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\”

  • The GUID Generator application can be found in the bin subfolder
  • Full Path: “C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\guidgen.exe”
  • Now you have the path, fire up Visual Studio

clip_image002

  • Click Tools->External Tools
  • Click Add
  • Title: Generate GUID
  • Command: : “C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\guidgen.exe”
  • Click Apply

clip_image004

When this tool is used then the following window will popup:-

clip_image006

Get Public Key Token Tool

This retrieves the public key token for the assembly that is associated to the file that is open in Visual Studio.

To setup the tool do the following:-

  • Get the Path to the SN.exe tool which is found in the .Microsoft SDK Path
  • “C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\sn.exe”
  • From Visual Studio
  • Click Tools->External Tools
  • Click Add
  • Title: Get Public Key Token
  • Command: : “C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\sn.exe”
  • Attributes: -Tp $(TargetPath)
  • Check “Use Output Window”
  • Click Apply

clip_image008

When the External Tool is used then the following output will appear in Visual Studio’s Output Window

clip_image010

Get Full Assembly Name Tool

This tool is excellent and saves me lots of time when you need the full Assembly Name for all the numerous SharePoint development tasks.

The setup of the tool comes from Sahil Malek (http://blah.winsmarts.com/2009-12-SharePoint_Productivity_Tip_of_the_day.aspx).

  • Fire up Visual Studio
  • Click Tools->External Tools
  • Click Add
  • Title: Get Full Assembly Path
  • Command: PowerShell
  • Arguments: -command “[System.Reflection.AssemblyName]::GetAssemblyName(\”$(TargetPath)\”).FullName”
  • Check “Use Output Window”
  • Click Apply

clip_image012

The output for this tool is as follows:-

clip_image014

Get IIS Web Application Info

This tool is great for getting information on the Web Server Application Pools. This is great if you need to debug a particular Web Application Pool Process.

  • Fire up Visual Studio
  • Click Tools->External Tools
  • Click Add
  • Title: Get IIS WP Info
  • Command: “c:\windows\system32\inetsrv\appcmd.exe”
  • Arguments: list WP
  • Check “Use Output Window”
  • Click Apply

clip_image016

The Output for this tool is as follows:-

clip_image018

Conclusion

I hope you find some of those tools useful, I would love to hear about any that you use.

Visual Studio Tip: Using SharePoint Site Url in Pre-Deployment and Post-Deployment scripts.


Within Visual Studio 2010 SharePoint projects you might want to use the SharePoint Site Url that you have specified for your SharePoint project in Pre or Post Deployment scripts.

The SharePoint Site Url value can be retrieved using the $(SharePointSiteUrl) variable.

Usage

For example, this variable could be used in a pre-deployment script to deactivate certain features for the debug configuration.

To add the Pre Deployment script do the following:-

  • From Visual Studio 2010
  • Open your SharePoint Solution/Project
  • Click Project Properties
  • Click the SharePoint Tab
  • Add the following script to the Pre Deployment Script text box.
echo SiteUrl: $(SharePointSiteUrl)
if "$(ConfigurationName)" == "Debug" (
stsadm -o deactivatefeature -name "Feature1" -url $(SharePointSiteUrl) -force
stsadm -o deactivatefeature -name "Feature2" -url $(SharePointSiteUrl) -force
stsadm -o deactivatefeature -name "Feature3" -url $(SharePointSiteUrl) -force
stsadm -o deactivatefeature -name "Feature4" -url $(SharePointSiteUrl) -force
stsadm -o deactivatefeature -name "Feature5" -url $(SharePointSiteUrl) -force
)

Hope that helps.

For more information on Pre and Post-Deployment steps see this MSDN Link:

How to: Set SharePoint Deployment Commands (http://msdn.microsoft.com/en-us/library/ee231534.aspx)

 

U4FVW5JMFNEH

Visual Studio SharePoint Packaging Issue: Both "SharePointItem" and "SharePointItem" contains a file that deploys to the same Package location.


I have had this problem a few times when moving and copying SharePoint SPI objects within Visual Studio 2010.

When you attempt to package and deploy your SharePoint solution the following error occurs:-

  • C:\TFSBulid\4\Project\BuildLocation\Sources\ProjectName\Package\Package.package: Both “[ExampleSiteDefinition]” and “[ExampleSiteDefinition]” contain a file that deploys to the same Package location: [Location]

The problem occurs because two of the SharePoint Project Item (SPI) have references to the same location. This seems to occur when you copy SharePoint Project Items.

If you take a look at the SharePointProjectItem.spdata file for the SharePoint Project Item that you copied from the SharePoint Point Item specified in the [Location] portion of the error message you will see that the SharePointProjectItem.spdata file will show details of the old SharePoint Project Item rather then the new SharePoint Item.

The content of the SharePointProjectItem.spdata looks like this:-

 1: <?xmlversion="1.0"encoding="utf-8"?>
 2: <ProjectItemType="Microsoft.VisualStudio.SharePoint.SiteDefinition" DefaultFile="onet.xml" SupportedTrustLevels="FullTrust" SupportedDeploymentScopes="Package"
 3: xmlns=http://schemas.microsoft.com/VisualStudio/2010/SharePointTools/SharePointProjectItemModel>
 4: <Files>
 5: <ProjectItemFileSource="default.aspx" Target="SiteTemplates\ExampleSiteDefinition\"
Type="TemplateFile" />
 6: <ProjectItemFileSource="onet.xml" Target="SiteTemplates\ExampleSiteDefinition\Xml\"
Type="TemplateFile" />
 7: <ProjectItemFileSource="webtemp_ExampleSiteDefinition.xml" Target="1033\XML\"
Type="TemplateFile"/>
 8: </Files>
 9: </ProjectItem>

To fix this update the ProjectItemFileSource element’s Target attribute to point to the correct location.

SharePoint Feature Receiver token replacement only works with Guids using lower case characters


Introduction

This week I have been writing my first proper SharePoint 2010 Service Application.

Part of that solution is using a Feature Receiver to install the various components that make up a Service Application. These include:-

  • Service
  • Service Proxy
  • Service Application
  • Service Application Proxy
  • Service Instance

Tip: Andrew Connell’s chapter in the Real World SharePoint 2010 book is an excellent resource for getting the plumbing of the service application setup.

One of the issues came about at deployment time. Now that I write this, I do remember hearing about this issue before when during a SharePoint 2010 Developer Bootcamp. Of course I didn’t take enough notice and then hit the problem when I decided to update the GUID for the feature receiver.

The following error was displayed when deploying the solution:-

Error occurred in deployment step ‘Add Solution’: Failed to create receiver object from assembly “ITSP.SPMonitoringStatusPackage, Version=1.0.0.0, Culture=neutral, PublicKeyToken=de085cbd57463aa2”, class “$SharePoint.Type.edd0669b-2393-4fe6-988d-17a2De06c6e4.FullName$” for feature “ITSP.SPMonitoringStatusPackage_ITSP.SPMonitoringStatusInstaller” (ID: a5ede1b3-cbd6-4918-9f31-4322603295f5).: System.ArgumentNullException: Value cannot be null.
Parameter name: type
at System.Activator.CreateInstance(Type type, Boolean nonPublic)
at Microsoft.SharePoint.Administration.SPFeatureDefinition.get_ReceiverObject()

Screenshot:-

guid-featurereceiverdeployerror

The deployment show that any error occured because it could not create a feature receiver object from assembly “ITSP.SPMonitoringStatusPackage, Version=1.0.0.0, Culture=neutral, PublicKeyToken=de085cbd57463aa2” with the class “$SharePoint.Type.{GUID}.FullName$”.

The token, “$SharePoint.Type.{GUID}.FullName$”, should be replaced by Visual Studio as part of the build process. However this does not seem to happen with the GUID value that I was using (see below).

In this example the {GUID} value is specified against the feature receiver class using an attribute as below (please note the capital letters have been added for this example):-

guid-featurereceiveruppercase

The item that uses this GUID attribute for the Feature Receiver Class can be seen by double-clicking on the feature Visual Studio SPI object:-

featureceiver-spi

If you then look at the properties of the feature Visual Studio SPI object, you see the section as below:-

featureceiver-spi-properties

As you can see the Receiver Class has a value of:-

$SharePoint.Type.edd0669b-2393-4fe6-988d-17a2De06c6e4.FullName$

 

Solution

The issue is that upper case characters are being used and changing these to use lower case alphabetic characters for the GUID fixes the issue.

The following changes need to be made.

  1. Change the Feature Receiver’s GUID attribute.
 1: [Guid("edd0669b-2393-4fe6-988d-17a2de06c6e4")]

 

 2:     public class ITSPSPMonitoringStatusInstallerFeatureReceiver : SPFeatureReceiver

 

2. Update the Feature Receiver Visual Studio SPI object’s Receiver Class property to:-

featureceiver-spi-properties-fixed

Save all the files, rebuild, deploy and the solution is deployed successfully, hurrah!

feature-installed-successfully

 

Hope that helps.

Issue with Updating SharePoint Publishing Page Layouts and Ghosting


Introduction

This post has come about due to some challenges when upgrading a publishing site page layout.

Before we delve into the issues I best explain how the Page Layouts are setup. The page layouts are all contained within a feature called “Company.Intranet.Publishing” which are deployed to the folder:

SharePointRoot\Template\Features\Company.Intranet.Publishing\PageLayouts.

Each of the page layouts are deployed into the master page gallery (/_catalogs/masterpages) using a Module. The page layouts are deployed as uncustomised or ghosted files.

The fact these resources are deployed as ghosted files is very important as you will see in the next section.

Finally the feature is deployed using the SharePoint Solution framework as a single SharePoint WSP using WSP Builder.

What do you mean by Ghosted / UnCustomised files?

There has been quite a lot of information published about this and the following are good resources:-

My understanding is that a ghosted file is where the binary content is actually stored on the file system of the server and a pointer to that binary content is held in the content database. If a user modifies the content of a page layout in a site collection by a tool such as SharePoint Designer then a copy of that binary content is taken from the file system and merged along with the changes made by the user and stored in the content database.

Hence when you retrieve an uncustomised file its binary content is being pulled from the content database.

Why are Ghosted / Uncustomised files preferred?

Recently at the SharePoint Best Practices conference, Eric Shupps and Rob Foster did a great presentation on Fine Tuning and Optimising SharePoint Performance. One of the key points in improving performance is to ensure that files are ghosted/uncustomised for the following reasons:-

  • Ghosted files all point to a single file and hence they all point to the same binary content. This means only one file needs to be cached and the load on the database is significantly reduced.
  • Actually Unghosted files cannot be cached within a BlobCache. Unghosted files are therefore slower to load and render (10% slower on average) than a ghosted file.

Upgrading Page Layouts

The method used to upgrade page layouts is simply by redeploying the files through an updated wsp solution file. We have also been careful through training and guidance with users to ensure that page layouts are not edited through SharePoint Designer.

Therefore if a change to a page layout is required, then the page layout is updated within the feature directory using Visual Studio and the WSP solution file is rebuilt.

The solution is then ready to be updated using the command:-

stsadm –o upgradesolution –filename [solutionname.wsp] –name [solutionname.wsp] –allowgacdeployment –allowcaspolicies –immediate

The change to the page layout is then reflected within the SharePoint site.

Why are my changes are not seen?

More history, our last deployment required that we tidied up the page layout’s title and description.

One of the problems with using a Module to deploy files within a feature is that with SharePoint 2007 it is difficult to make changes to existing files deployed by a module without resorting to code. Any changes to the filenames or properties that are deployed by the Module are not reflected until the file is deleted from the site collection.

As there were not that many site collections, we took the decision not to write any code and we modified the page layout titles and descriptions through the SharePoint UI.

Unfortunately when we did our next release into our testing environment the changes to the page layout markup were not seen within the site.

After checking that the page layouts were being deployed correctly to the the WFE’s file system we started thinking of the reason. Finally I thought it must be due to unghosting of the files.

Normally you can use SharePoint Designer to revert page layouts to their site definition. So I fired up SharePoint Designer and browsed to the /_catalogs/masterpages document library but could see that the Page Layouts were not customised.

I started to search for tools to find out which files are customised. The legendary Gary LaPointe (@glapointe) came to the rescue.

If you don’t deploy Gary LaPointe STSADM tools on your Production/UAT environments then I plead with you that you start to do so as soon as possible. Time and time again I have been in a bind and Gary’s STSADM commands have got me out of trouble.

The commands that saved the day this time are:-

The commands give a lot of flexibility, though I will warn you that you need to be a bit careful as you could quickly reghost all the files within your site collection if you are not careful.

I performed the following command:-

stsadm –o gl-enumghostedfiles –url http://sharepointsite.domain.com/

This displayed a list of files that were unghosted. Funnily enough all the page layouts that we had modified and changed their Title and Description fields had become unghosted!

Once we had a list of the unghosted page layouts we could reghost each of them in turn using the command:-

stsadm –o gl-reghostfile –url http://sharepointsite.domain.com/_catalogs/masterpage/RandomPageLayout.aspx –Scope File

This command would reghost each of the files, there were occasions where the page layout reghosting would fail, using the –force option for the gl-reghostfile would ensure that the page was ghosted.

Now looking at the site the page layouts had been updated and reflected the changes that had been deployed by the update solution.

Hope that helps!

Building WSP Solution out of Multiple Visual Studio Projects


>

Introduction
Recently I have been building a reasonable sized SharePoint solution which is using multiple Visual Studio projects. Using the excellent WSPBuilder by Carlos Keutmann, the SharePoint content can be packaged up build individual solution files.
WSP Builder
Ok so as with these things there have been a few hacks to ensure that WSPBuilder does the right thing when building the package. Before I start I should explain how to use WSPBuilder, basically what you do is define the structure of the SharePoint 12 Hive in your project. So you create one folder called 12 and then create sub folders which mimics the SharePoint 12 Hive structure.
So under the 12 folder you would add the appropriate sub folders for your solution :-
TEMPLATESTEMPLATES\LAYOUTS\[YourAppFolder]TEMPLATES\IMAGES\[YourAppFolder]TEMPLATES\FEATURESTEMPLATES\SITETEMPLATES\YOURSITEDEFFOLDER.....
To add assemblies to your solution you create a GAC folder and an 80 folder at the same level as the 12 Folder.
To add an assembly into the GAC put the assembly in the GAC folder. To add an assembly into the web application bin folder put the assembly in the 80 folder.
The Problem
So far so good but when you have multiple projects building multiple assemblies, it is difficult to organise the files so that WSP Builder can build the solution correctly.
This is made worse when you have a project that builds an assembly which is then used by another of the projects.
To explain this if we have two projects, Project A and Project B. Project A builds assembly ProjectA.dll and Project B builds ProjectB.dll, Project B uses Project A.
When Project B is built it relies on the Project A dll and the assembly is copied into Project B’s build directory.
Now if you wanted to package up the solution using WSP Builder, you can run WSP Builder as part of the post build event by running “c:\program files\wspbuilder\wspbuilder.exe”. However if the assemblies, ProjectA.dll and ProjectB.dll need to be in the GAC then we need to build the project and then copy the dlls into the GAC folder.
Thus when the WSP Builder runs it will pickup that the assemlbies need to go into the GAC and build the wsp solution correctly.
These post build events become more and more complex as the number of projects is included in the solution, more complexity equals more room for errors.
A Solution
In order to make things less complex I use the post build events for the projects to copy all the appropriate content from the project directory and build a directory structure under the solution dir.
This can be done as follows:-
echo Running WSP Builderecho Copying GAC Dlls to $(ProjectDir)GACcopy /y "$(TargetDir)*.dll" "$(ProjectDir)GAC\"

echo Copying 12 Directory to Solution Buildxcopy /S /E /I /H /Y "$(ProjectDir)12" "$(SolutionDir)Build\12\"

echo Copying GAC Directory to Solution Buildxcopy /S /E /I /H /Y "$(ProjectDir)GAC" "$(SolutionDir)Build\GAC\"

echo Running WSP Builder against FCT System Solutioncd "$(SolutionDir)Build\%programfiles%\WSPTools\WSPBuilderExtensions\wspbuilder" -WSPName [solutionfilename.wsp]-SolutionId [SolutionIDGUID]

echo Copying packages to Deployment\Packagecopy /y "$(SolutionDir)Build\*.wsp" "$(SolutionDir)Deployment\Package\" copy /y "$(ProjectDir)Package\*.*" "$(SolutionDir)Deployment\Package\":exit
Some enhancements
One of the annoying things when you are coding is that there is a cycle of fix, build, deploy, debug. If you are building the WSP file each time then the cycle between build->deploy->debug can be quite slow. To speed things up I use different build configurations. For example the Debug build does not call the wsp builder command but uses gacutil to add the assembly to the GAC or copies the assembly to the web application bin directory. The application pool is then recycled.
echo Copying content into $(SolutionDir)
copy /y /e /s/i “$(ProjectDir)\12” “$(SolutionDir)\Build\12”
For example:-
This is achieved in the following manner:-
I hope that you find this useful, I would love to hear about other ways that people achieve this and also if anyone has any enhancements to this solution.

SPVSX (SharePoint Visual Studio Extensions) Alpha Released


>One of my teammates, Matt Smith, has been working hard alongside Wes Hackett, Glyn Clough and Martin Hatch on what looks to be a very interesting tool to help us developers.

The tool extends the new Visual Studio 2010 SharePoint development features further providing the following key points:-

  • Deployment
  • Quick Deploy (similar to Copy to 12/GAC in old-school WSPBuilder and VSeWSS 1.3)
  • Quick Deploy Custom Deployment Steps and Configurations
  • Project and Solution-level Quick Deploy (without changing deployment configuration)
  • Copy to SharePoint Root at File and SharePoint Item (SPI)-level (right-click in Solution Explorer)
  • Auto Copy to SharePoint Root when saving a file (e.g. auto deploy a change to an ASCX)
  • Auto Copy to GAC/BIN when building a project
  • Restart IIS
  • Recycle app pools
  • Attach to IIS worker processes (for quicker debugging!)

 

Matt has more details on his blog.
To download the extensions take go to the SPVSX Visual Studio Plugin Gallery and provide feedback/comments/requests on the SPVSX Codeplex site.