I have been developing in SharePoint for many years now and have developed a number of practices that allow me to work in what I feel is quite an efficient manner.  I intend to write a number of posts on these and thought I'd start here with a few tips.  Hopefully they might come in handy.

 

Tip 1 - Shortcut Folders

There are a number of key folders that a SharePoint developer needs:

1) C:\Program Files\Common Files\Microsoft Shared\web server extensions\12

2) C:\WINDOWS\assembly

3) C:\WINDOWS\system32\LogFiles

4) C:\Inetpub\wwwroot\wss\VirtualDirectories

5) Your development folder or a sub-folder within it for the project you are working on ... e.g. c:\development\customerx

6) Your log file location e.g. c:\windows\temp

Quick access to these folders is essential so I have a folder on my desktop with shortcuts to each of these folders and I have a folder toolbar next to the system tray pointing to this.  If, for example, I want to deploy code to the GAC I just click the assembly and development folder shortcuts , get them sized and positioned on the screen (using folder view on the left for quick navigation if you have a number of assembly projects) and copy them across.  This example can be more easily achieved using a batch file that copies to the GAC but this is just an example and also leads on to my next tip.

 

Tip 2 - IIS Reset in Quick Links

Add a shortcut to IIS Reset in Quick Links ... essential.

 

Tip 3 - Batch files

You'll save yourself loads of time using batch files to do as much as possible.  If you ever think to yourself "for the time it takes to write the batch file it isn't worth it", just remember that it isn't just about the time saving (which will end up being greater by using batch files) but it's also about efficiency at the right time.  When things are going wrong and you are feeling impatient (we all do at points, some more than others!) the most annoying thing is to have to carry out laborious processes.  The click of a button to carry out a load of repetitive tasks couldn't be more useful when you need it!

[UPDATE] Always put a "pause" statement at the end of any batch files,where appropriate, so that you can see whether there were any failures during execution.

 

Tip 4 - Develop using solutions

Always, always, always develop using solutions.  The first thing you should add to your Visual Studio Solution is an SP Solution project (as originally blogged by Andrew Connell here).  As previously mentioned I shall be providing an updated and extended version of this blog post.

Get used to it.  Every single time you develop anything in SharePoint, start off developing the solution.  Once you've done it a couple of times, it'll be second nature - it is to me and it was well worth the extra effort (which was very little).

[as specified in tip 3] write batch files for adding and upgrading the solution to make it quick and easy (and don't forget those pause statements!).

Having said all that, don't update DLLs using the solution as it is more time consuming than installing them into the GAC with a batch file and clicking the IIS Reset button in quick launch as you will be waiting on the timer service to restart IIS.  You will need to upgrade the solution when you update any server files, but not DLLs.  Also, this works around the next tip!

[POSSIBLE UPDATE TO COME SEE COMMENTS]

 

Tip 5 - Watch out when building your SP Solutions using the VS IDE!

I have noticed a rather annoying bug in Visual Studio where DLLs used by MakeCab.exe (which builds the WSP - SP Solution file) seem to get cached and so the WSP file gets built with old DLLs in it (for those who don't know, the WSP is a cab file).  This has driven me crazy at points!  The easy way around this is to close and reopen Visual Studio but if you follow tip 4 you won't have to worry unless you are deploying to another server.  But ... DO NOT FORGET TO GET THIS RIGHT BEFORE DEPLOYING!  I have forgotten to do this as I was following my [tip 4] practice without thought.  It was rather confusing when things didn't seem to be working properly on the test server!

 

Tip 6 - Have another IDE open which is a console app - and use it!

Developing in SharePoint can be pretty slow with all the IIS Resets and carrying out non trivial tasks to test small bits of code.  For everything you develop that can be done outside SharePoint to at least prove concepts, do it in a console app.  I always have two IDEs open - my main solution and my console app.  It is quick and easy to debug rather than having to hook into IIS and then every time you want to IIS Reset reattaching, etc.  I would advise creating a class per thing you want to do (List.cs, AD.cs, Profile.cs, Workflow.cs etc) and then writing static methods and calling them from your main method in program.cs (e.g. List.TestSchema()) ... that way it's as simple as just commenting out the calls you don't want to make and/or adding any new calls you want.

 

Tip 7 - Always use the same port for your development Central Administration

Simple one - I always use 99.  Don't do this on production.

 

Tip 8 - Use Virtual Server

Use Virtual Server (or VMWare, whatever floats your boat) for all development ... I'm sure you all are already but I have to say it.

 

Tip 9 - Use DNS

Use DNS on your virtual server (or your hosts file) so all your sites are on port 80.  It's a lot easier.

 

Ok - comments appreciated please - I'd love to hear if these are either useful to anyone or if anyone disagrees and has different / better ideas ... !

---

Posted 12-07-2007 3:00 PM by georgebonney