Don't Modify your Output Path. Really.

Todays read is an excercise in balance. The balance is between what Microsoft says and what Microsoft says about development, specifically creating Web Parts. Buried deep in the best practices around the build process is a quote. "Don't Alter the Build Output Path". The section that's relevant goes on to say:

You might be tempted to alter the output paths of your projects in order to build to a single folder and then establish file references to that folder. Do not do this for the following reasons:

• It causes the build process to fail with file lock errors when a referenced assembly exceeds 64 KB in size. This problem is likely to be fixed in a future version of Visual Studio .NET.
• You can encounter another problem when you reference an assembly from a folder that is designated as your project's output folder. In this event, Visual Studio .NET cannot take a local copy of the assembly because the source and destination folders for the copy operation are the same. If you subsequently remove the reference from your project, Visual Studio .NET deletes the "local" working copy. Because the local folder is the same as the assembly's original folder, the original assembly is deleted.

Any developer worth his salt and building Web Parts probably knows that buried deep in the SPS/WSS SDK is this little tidbit:

Specify the build output path
This task assumes that you are running Visual Studio .NET on a server running Windows SharePoint Services or SharePoint Portal Server. Setting the build output path to the C:\inetpub\wwwroot\bin folder will build your Web Part's assembly in the same location from which it will run on your server. If you are not running Visual Studio .NET on your computer, you can copy your Web Part's assembly to the folder C:\inetpub\wwwroot\bin folder on your server after building it.

So on one hand we have Microsoft telling us to not change the Output path, and another we have them telling us to do it. Now for most of you, changing it has never been a problem. You set it to c:\inetpub\wwwroot\bin and all is well. Your Web Part compiles and runs and you can do all kinds of things like debugging and good stuff like that. On a larger project this isn't true so heads up to those about to approch the platform. Once airborne, it's an ugly trip back.

On larger projects there can be lots of Web Parts. Our current project (a Contract Management System) has about 40 of them but even that might be considered small. However all the Web Parts are reletively thin (as they should be) and just simply make calls to a Service Layer to retrieve Domain Objects and update the views. Nothing fancy and nothing complicated. All 40+ Web Parts compile to less than 64k. We have a single assembly that represents the Business and Data Access Layer. They're combined just because everything is sitting on the SharePoint server anyways and the DAL is just a wrapper around accessing lists using the SharePoint Object Model so again it has to be local.

It hasn't been a problem so far and we, as documented in the SDK, changed our output path to c:\inetpub\wwwroot\bin for development. Debugging and all that goodness abounds. The problem was this morning when I added a new assembly to handle communications with a third party system (SAP). SAP (via the .NET connector) creates proxy classes for you and these can change frequently and have to be regenerated so the assembly will change often. I didn't want to keep changing our Core assembly whenever SAP changed (because every Web Part referenced it) so it was split out. Herein lies the problem that surfaced. Now the system was referencing an assembly larger than 64k and, due to circular references in the assemblies, I couldn't avoid this. There were a few other things I tried with separating and combining classes but it's just not going to happen.

So now it's back to resetting all 40+ projects to compile to bin\Debug again and creating an extra NAnt task to do an xcopy deployment to the c:\inetpub\wwwroot\bin directory for debugging. A bit of a PITA but has to be done and it fixes the issue. As Microosft says "this will be fixed in a future version of Visual Studio .NET". I checked and compiled with Beta 2 and it seems to be fixed but then I can't fully check it because I can't run Beta 2 against SharePoint just yet.

Bottom line, follow the first rule and don't modify your Output path and use a build script to copy the files after a successful build. Even if your project is small today, someday it might grow. So do you want the pain now or later?