1. even though its a bit late for me to ask this, i wanna know if MOSS
2007 is stable, robust and efficient enough to act as a development
platform for an enterprise wide business intelligence application,
compared to developing  it from scratch on say ASP.NET 2.0 or dotnetnuke?

Reply> Yes, it is stable and robust enough. I don't have enough hands on
knowledge about dotnetnuke to comment on it, but MOSS will provide
significant capability over and above just ASP.NET 2.0 while maintaining
full support for ASP.NET 2.0 capabilities. MOSS 2007 leverages many of the
functions and features of ASP.NET 2.0, but adds more.


2. What would be an ideal development environment/platform for
developing applications  over MOSS 2007? our team consists of 3
developers, two test engineers, one analyst and one project manager. we
are developing a business intelligent application and will need to write
our own web parts, custom .ASPX pages, custom database design (to hold
business data).

Reply> I think each developer should have their own Virtual PC (or VMware)
machine running MOSS 2007 for development. They should also have a Virtual
machine running XP to test client access after initial development. The
test engineers would then test on something that duplicates your production
environment as much as possible. This environment facilitates maximum
programmer productivity and ease of debugging, without sacrificing final
testing in a production like environment.

3. Should we use VSS for configuration management, or VSTS?

Reply> At this point it doesn't really matter all that much. VSTS doesn't
have any capabilities specific to SharePoint so it can be overkill.

4. What tool/method should we use to deploy the developement version to
test, staging and finally to production environment?

Reply> SharePoint Solutions and Features for deployment of custom programming.
MOSS Content Deployment for content that you want to roll out.

5.someone told me that you can't use VS.NET 2005 to connect to a MOSS
2007 website, modify existing pages, create custom .ASPX pages etc. The
only available tool for this purpose is sharepoint designer. is this
true? also, what exactly can we do using VS.NET 2005 IDE if we are to
develop an enterprise level web application over MOSS 2007, other than
developing web parts?

Reply> You can't use VS.NET 2005 to connect to a MOSS website like you can
SharePoint Designer. If you are using publishing you can download the page
and load it into VS.NET. If you are editing "uncustomized" (read ghosted)
pages that are in the 12 hive file systems then VS.NET is the only real tool
to use (other than notepad). VS.NET can be used to edit Master Pages,
layout pages, .aspx pages. It can also be used to develop webparts, web
services, and applications that run on the SharePoint server using the
SharePoint object model. Since VS.NET has a good XML editor it is also
useful for editing CAML in custom site definitions, features, solutions,etc.
It just can't get any of these from the SharePoint database.

6. Are there any tips, articles discussing the pros & cons of using
sharepoint designer and VS.NET 2005?

Reply> Editing with Sharepoint designer will result in "customized"
(unghosted) instance pages that can be harder to maintain long term if you
wish to make global look and feel changes in the future. VS.NET is normally
used to edit "uncustomized" (ghosted) pages and keep them that way.

I agree with PPS and would add that if you are seriously considering
setting up a dev environment then number one on your to do list
should be buy and thoroughly read Todd's book
(www.amazon.co.uk/.../202-7952402-
1763035).

Also, I have been discussing this very issue recently on my blog:
www.sharepointblogs.com/.../setting-up-
a-moss-development-environment-part-ii.aspx

One other thing I would say, imo chosing VSTS against VSS, VS Ent/Pro
or whatever isn't a SharePoint issue at all so if you have access to
VSTS then I would say use it because it provides many team facilities
that your set up would benifit from.

Thanks for the detailed response! Just a few more questions to make
things a bit more clear for myself:

1. What is a "Sharepoint Solution"?

2. When you suggest to use VS.NET for editing ghosted pages or
masterpages, does that mean opening the ghosted pages/masterpage
directly into VS.NET and editing them right there (which I assume might
be a bit risky) or adding those files in your solution and then
packaging and deploying them through a "sharepoint feature"?

3. If we were to develop our own custom .aspx pages, what should
be the location to deploy them? From what I have understood reading
different discussions is that sharepoint only allows you to place your
customized .aspx pages in \_layouts folder and a good method would be to
create your own folder like \_layouts\myweb\ and place all custom .aspx
pages there. Also, would it be a good way to use our custom .aspx code
by embedding the "page viewer" webpart in a sharepoint webpage and
configuring it to use our custom .aspx page. I have seen a lot of
developers using this method to mix up their custom source code with
sharepoint pages but I am not sure if this is one of the best practices
or a really good method at all.

1) A SharePoint Solution is a .CAB file containing the particular
feature or webpart that you wish to deploy. It also contains a Manifest.xml
which provides information about the contents of the .CAB. The solution can
then be installed into SharePoint and used to schedule deployment of the
item contained in the .CAB file to all the Web Front Ends in a server farm.
Take a look at the following blog entry
<blogs.msdn.com/.../749105.aspx>" target="_blank" rel="nofollow">blogs.msdn.com/.../749105.aspx>
blogs.msdn.com/.../749105.aspx

2) Of course you never want to make changes to files that Microsoft
puts in the 12 hive. You make copies of those files and work on the copies.
So for example, if you create a custom site definition that uses a custom
master, you would start with a copy of Microsoft's default.master and make
changes to it using Visual Studio. Depending on what you are doing you
might or might not deploy it using a solution.

3) There are several places that you can place custom .aspx files.
When creating a custom site definition or feature the files can go right in
the subdirectory with the definition or feature. They are referenced as
"ghostableinlibrary" and SharePoint accesses them directly as though they
were in the database. But for custom .aspx files that are standalone you
are correct, they are normally located in a custom directory of _Layouts
(Layouts in the 12 hive). For small chunks of custom code you can look at
the Content Editor Web Part. This is frequently used to embed small pieces
of code or stylesheet declarations directly onto a sharepoint page.