Required Sharepoint Development Tools

Site definitions are complex no question about it, but they are very useful if you need to deploy to unrelated enviornments. If you are staying on the same server farm, maybe site definition is overkill. If you are going between domains (i.e. test & prod, then maybe they are worth looking into).

Another advantage to site definitions, esp. if delivering to a client is it feels more like a traditional deliverable. They will have a bunch of files (hopefully in source control) that are their custom site. I think that gives IT dept's a much warmer feeling than an XML file created from the SharePoint UI.

Another benefit of site definitions are you have a lot more control over the pages that make up the site. IMHO its easier to add master pages & custom CSS via site defintion that site template.

I am curious as to what are the 'moving parts' to the site you are trying to deliver? I think that answering that question will determine how to define the project's structure.

Generally, I think you are on the right track. Features and solutions are a must. I would stay away from VSeWSS, its buggy and clunky and generally terrible if you are trying to do anything complex. It tries to be so smart, that it leaves you no control.

That said, it really depends on what you are trying to do. If you are going to build a solution to deploy to the GAC with one assembly, and only building features supported by vsewss you may be fine.

If however, you want to develop, say a timer job wiring that into the VSeWSS feature framework gets tough. Also, if you need multiple assemblies in the solution. YMMV, but I had to junk it and find of a more flexible solution (hello NANT).

A lot of the work you will end up doing is building and checking, and re-checking XML configuration files. Bookmark the Feature Schema reference page on MSDN, you will be spending a lot of time going through it.

Finally, yes, if you have all of the parts packaged as features you should be able to develop a nice install script. Ultimately the script will need to call the STSADM (there are some really nice STSADM extensions here) commands necessary to create the site structure, add & deploy the solution & activate the features. You can start with a batch file, and get as complicated as you want.

In my honest opinion it sounds like you are trying to reinvent the wheel. If users are finding it cumbersome it is generally do to lack of understanding or incorrect implementation and training.

However if you do want to integrate into SharePoint, you can reference the full SharePoint API Library. It is .Net based and allows you to access any aspect of SharePoint in code. You need to reference the Microsoft.SharePoint assembly to access these classes. You will need to setup a development environment for this, since you can't develop for SharePoint without having it installed. The detailed documentation on the namespace starts here

From personal experience we had much more success implement a solid SharePoint structure, with training, and also building the SharePoint portal the same way we would have built a website. Users now insist on having applications in SharePoint.