One of the things I really hate about 2010 and the packaging solution that comes out-of-the box is that it encourages bad practices (plopping everything - web code, static artifacts, packaging) into one project.

There are lots of issues with this, but the most egregious issue -- in my opinion -- is that it forces the creation of artifacts in a hierarchy that needs to map to the SharePoint deployment targets instead of making sense in the logical structure of the application and code. I find that this decreases navigability and if some code *is* separated out into other libraries, just makes things that much harder to find and find a home for.

With 2007 and even with 2010, when using WSPBuilder, I've followed the standard project layout pattern of having at least three projects:

1. **Package** - The package project that encapsulates the deployment artifacts and the deployment artifacts **ONLY**
2. **Web** - The UI project that contains the static web artifacts, the ASPX pages, the ASMX endpoints, the WCF endpoints, etc. - has no direct reference to SharePoint
3. **Core** - A class library project with the core business logic - encapsulates the direct reference to SharePoint. Feature receivers, event receivers, base classes, domain model classes, data mapping classes, helper classes, etc. go here.

With WSPBuilder, it was easy to separate the artifacts by simply using XCOPY on pre- or post-build to move artifacts from the **Web** project to the **Package** project before calling the WSPBuilder executable. WSPBuilder didn't care if the .aspx or .js or .css file was part of the VS solution tree; it would include it in the package if it was in the directory on the file system.

This allowed me to separate web code from the SharePoint code and build a nice boundary to prevent "leakage" of SharePoint API calls to the web artifacts (as well as logically organize the web code into a hierarchy that made more sense). In other words, it forced everything on the front-end in **Web** to call through a domain model in **Core**. The **Web** project becomes a "pure" ASP.NET web application that has no knowledge of SharePoint. I can have strong ASP.NET developers work on the front-end and strong SharePoint developers work on the domain model without giving the ASP.NET guys a chance to "cheat" and write "dirty" code in the codebehind since they have no reference to SharePoint.

I've been trying to figure out how exactly this type of separation can be duplicated with the OOB packaging with Visual Studio 2010.

The core problem with VS2010 is that the contents of mapped folders (i.e. Layouts) don't get included in the manifest and package if they are not included in the project in the VS solution. In other words, if I just XCOPY the files from the **Web** project to the **Package** project, they don't get added to the package because -- even though they are in the file system -- they are not part of the solution.

One workaround is to manually create "stubs" for the files (same name) in mapped Layouts directory so that when the XCOPY occurs, it's copying the latest file and replacing the placeholder in the package. But this seems a pain in the butt, redundant, and easy for developers to forget when adding new files.

But I'm curious how other shops out there are handling this issue. I feel strongly that for any non-prototype code, this type of separation becomes a must to ensure maintainability and approachability of the code for new developers. Are there workarounds to short-circuit the OOB packaging quirks that can be automated and remove manual steps like creating a stub .aspx? Are there alternative patterns for separating logic out of the package?
['https://sharepoint.stackexchange.com/questions/21141', 'https://sharepoint.stackexchange.com', 'https://sharepoint.stackexchange.com/users/803/']
After installing SP1, you need to install the latest Cumulative Update (CU), which is currently the Aug 2011 CU. After running that CU you'll need to re-run the SharePoint Product config wizard again after that is installed.

If I was doing a fresh install, I would install and configure SP2010, and run the config wizard to make sure it all came up as expected and worked. and then I would install SP1, and the Aug CU and then re-run the config wizard. I am not certain if you can skip the PS Config wizard after the initial installation of 2010.
The verdict is still unclear as to whether or not the latest CU is needed for SharePoint 2010, you'll hear arguments on both sides with some saying "stop at SP1 and go no further" and some saying "go on to the latest CU", I've seen farms configured both ways with no issues. You don't need to run the config wizard until all components are installed if you're doing a first-time install. My suggestion is to do it this way:

1. Look up how to "SlipStream" the service pack 1 install into SharePoint 2010, and do so, this way you can install both at the same time
- After installing, run config wizard and start your farm
- (Optional depending on your point of view) install the latest CU
- Run the config wizard again