R – How should I create a good environment for .Net development for Sharepoint

development-environmentinstallationnetsharepoint

My company have used external companies for all software development and infrastructure but now we want to move it inhouse. The company uses Microsoft products where applicable to standardize the enviroment. Sharepoint will be used as a portal to all tools needed by management, sales personal etc. Sharepoint runs on one server and our databases on another. They are both located abroud. Now to the question:

How can I setup a good environment for developing and testing our software. i.e. customized Web Parts, integration of externally located web sevices etc?

How would a good development / test server be equipped (hardware and software)?

Is it better to buy a powerful server or better equipped workstations running virtual copies of our servers?

How have your companies solved it, and what would you change in your setup?

With regards
Marcus

Best Answer

I do MOSS development at the moment, and the setup I use currently consists of a single Windows Server 2008 Standard system (used to be a VM, now its a physical machine but I have no personal preference one way or the other) with:

  • Visual Studio 2008 Standard
  • WSS 3 Visual Studio Extensions for 2008 (link)
  • SmartPart templates (link)
  • Active Directory configured and setup with its own domain
  • Exchange configured and setup (very good for getting access to the customAttributes in AD profiles, which you can use to manage user data and import into SharePoint)
  • WSPBuilder (link)
  • SQL Server 2005 Standard

Hardware wise, I am fine running all of the above on a dual core 2.5Ghz system with 4GB ram - but the most important thing is that it has to be a 32bit system, that has to be stressed significantly. Your development environment must be 32bit, there is so much in SharePoint which will run fine under 64bit, but you cannot develop against it in 64bit.

I will stress that again - you must use a 32bit environment for developing.

Lastly, never assume in code a set GUID for a document library, list or other SharePoint feature - if you need something setup in a certain way, make it part of your deployment script. This way, your admin overhead for maintaining the development, UAT and production environments is reduced drastically.

The only thing I would change about my current setup is moving the SQL Server off to its own hardware, as that reduces overhead and also allows you to investigate the NTLM/Kerberos double hop issue with regard to separate services such as SQL Server Reporting Services and the Business Data Catalog.

Related Topic