ASP.NET Beta 2 web sites, SCCS and Cloaking
With Beta 2 having a go-live license, more and more people are writing code that may end up in a production environment. This means that the code being written is more than likely source code control worthy. Keeping this in mind, there's a little gotcha when integrating VS.NET 2K5 Beta 2 with your source code control system (SCCS) that can make team development a pain.
With VS.NET 2K5 there are no longer web project files when using file-based web sites. The values that used to be stored in the .xxproj file in previous versions of VS.NET have now been pushed into the solution file creating a "Directory Based Project System Model". Since there is no longer a project file, there's no way to "tell" the SCCS to exclude specific files or folders within the web site. To VS.NET 2K5, everything underneath the web directory is "fair game" and is published to the web and SCCS. Matter of fact, the "Exclude from Project" context menu does not even exist. Therein lies the issue. When you add external references, e.g. ref your business layer from your website, VS.NET 2K5 places the referenced assembly in the \bin sub-folder. When you goto check in your source code, your SCCS will attempt to check in your "\bin" folder along with all of your referenced assemblies. Ooooooops! If you are using project references you know what that means, the referenced assembly gets rebuilt and the new version gets copied to your website's \bin folder during each build.
If those files are under source control how can a team work concurrently (assuming that your team uses exclusive locks)?
The short-term Beta 2 workaround is to check-in your bin folder (recursively) to your SCCS, make all of your websites' \bin directories writable locally (recursively) and to "Cloak" the "\bin" folders withing your SCCS. The reason for checking in the \bin folder is more a "give-up" instead of trying to have all of your developers remember to try and not check in the files. Both Vault and VSS support the "Cloaking" feature. I am not sure about CVS and Subversion. By cloaking the folder, Vault/VSS will not retrieve files from the cloaked location using the client utilities (i.e. not the IDE). This is really more useful when building initial folder structure or you are the habit of "Getting Latest" using the client tools provided by Vault and/or VSS. Pulling cloaked folders from the IDE ends up behaving a little differently than you would think. The SCCS providers do not obey the cloaking settings and when you "Get Latest" VS.NET will attempt to retrieve the latest files. I assume (and guessing) this is because its not a feature that all SCCS system have. Enough of the cloaked files, let's get onto the local, writable files in the \bin folder. Vault out-of-box handles local, writable files differently than VSS. Vault will attempt to automatically merge any files changes and if it can, it will fall back to a "Do Not Overwrite" behavior and you must resolve the conflict later. In the case where the reference assembly differs from the assembly in Vault, you will not be prompted and your IDE experience is unscathed. VSS out-of-the-box will prompt you that the file has changed and give you the option to overwrite you local copy or retrieve the one from the server. So the Vault experience is less-intrusive than VSS. But, this will only happen if you do a recursive get. Otherwise, setting your \bin folders to writable should give you a pretty decent dev experience.
Good thing is that others have run across this issue and someone has already posted it on the product feedback site a couple days ago. The purpose of this post is to save you some time if you run across this.
To “Cloak” in Vault (VSS is almost identical):
- Open Vault Client
- Right click on the \bin folders of the web sites and select properties.
- Check the “This project is cloaked for me”
If someone is aware of a way to "tell" VS.NET through the solution file to exclude files for a web site in Beta 2 I would love to know?