Deploy DLL and admin rights

Sometimes, when working with corporate machines, it can happen that you have security issues that make your SharePoint development harder.

One of these problems is that even if you are machine administrator, or you have started Visual Studio as administrator, you still have problems with deploies, or you have DLL locked in the GAC and you are not able to update/delete them.

The solution to this problem is to remove the admin approval from the local policies:

  • run the Local Security Policy MMC snap-in (from the start menu, run, type Local);
  • go to Security Settings | Local Policies | Security Options
  • disable "User Account Control: Run all administrators in Admin Approval"
  • reboot the machine

I've seen this trick in the blog post Access Denied trying to uninstall assemblies from GAC.

Visual Studio: how to develop SharePoint apps without SharePoint installed

How to develop to SharePoint without having SharePoint installed: you need to place the dll both in the hive folder and in the GAC.

This can be useful when it is needed to develop for both SharePoint 2007 and 2010: of course it's not possible to have both of them installed in a developer machine.

This hint has been taken from the blog post How to Perform SharePoint Development On A Client Workstation.

Using FxCop to enforce Code Analysis

After having described StyleCop in the blog post Using StyleCop to enforce source code standardization, here I describe FxCop.

FxCop is used to do code analysis of generated dlls.

It is automatically integrated in Visual Studio Ultimate edition. In the project properties, it will be possible to find a new "Code Analysis" tab. From this tab, it is possible to enable Code Analysis on build and eventually define a file for custom rules (like for StyleCop, it is a good idea to use a shared file used by all the projects in our solution).

You can find more details in the following articles:

Using StyleCop to enforce source code standardization

StyleCop is a Visual Studio add-on used to enforce C# source code style rules.

After installation, you can run the checks from the new menu voice Tools | StyleCop; after execution, it will display its alterts as warnings in the Error window.

You can configure the type of warnings to be signaled with the online editor, that modifies the Settings.StyleCop file (simply double click on the file on your file system to edit it).

It's enough to have the Settings.StyleCop file (or better: a link, so that all projects reference a common file) in your Visual Studio project, so that after each build these additional checks are done. And StyleCop can work as a custom MSBuild task too.

You can find more informations in the blog post Enforcing coding standards with Microsoft StyleCop.

What to do when creating a new wsp in a Visual Studio 2010 SharePoint 2010 solution

What to do when creating a new wsp in a Visual Studio 2010 SharePoint 2010 solution

Mandatory steps:

  1. delete the created snk and add a reference to your global snk file (add existing item, Add As Link)
  2. from project properties, sign the assembly using the previously referenced strong name key file
  3. from project properties, choose the deployment configuration between Default and No Activation
  4. from project properties, disable the Auto-retract after deploying flag
  5. if not done during creation time, from the project properties set the site url
  6. add the needed references to the other assemblies in the solution
  7. unload the project file and add the tag needed to create the wsp file automatically, as described in my post Visual Studio 2010: how automatically build wsp packages after SharePoint 2010 build
  8. from package, advanced, add the assemblies you want to include  in the wsp and deploy in GAC

Suggested steps:

  1. write one or more web-application scoped features, used to activate and deactivate the other features at site collection (SPSite) or site (SPWeb) scope
  2. if the wsp has not web-application scoped items, create an empy WebPart and a site collection scoped feature to be able to deploy the wsp to a single web-application, as described in my post SharePoint: how make your wsp deployable in a single web application

Improving Visual Studio 2010 for SharePoint 2010 development

If you have ever developed SharePoint packages (wsp) with Visual Studio 2010, for sure you have feld a less than ideal user experience, because Visual Studio is not so integrated as WSPBuilder was with SharePoint 2007.

You can get a few of the better features of WSPBuilder installing the following add-on for Visual Studio: CKS: Development Tools Edition.

In particular, the commands I find more useful are:

  • Copy to SharePoint Root
  • Copy to GAC/BIN
  • Recycle All SharePoint Application Pools
  • Restart IIS
  • Restart OWS Timer Process
  • Attach to All SharePoint Processes
  • Attach to IIS Worker Processes
  • Attach to OWS Timer Process