Yes, its safe to remove those. Not using TFS I've never run into this problem but I confirm that the VS project had some referecnnes to no longer exsiting files under ClientScript/tiny_mce and under /Data/HtmlTemplates/readyset.

I just removed them from my copy so it will get cleaned up in our svn repository.

Not sure about the /bin references, I'm sure you can delete them but its not something I can fix permanently because VS seems to create those project references. I did remove the references to missing xml files in the /bin.

Really the bin folder should not be part of the commit, at least in svn we don't have the /bin folder under source control as those files are supposed to be generated by building the code. Maybe its differentin TFS but if they have a way to excluse the bin folders I would as well as files like user.config and .csproj.user files which should be user specific and not in the code repository.

Hope it helps,

Joe

I'll review the skin folders and see about removing those. Feel free to point out any others you encounter. I do try to keep that cleaned up but there are lots of folders and sometimes I miss a few here and there.

Any beers are always appreciated!

Cheers,

Joe

A couple of tips that may help.

If you only build the mojoportal-core.sln it will not have any features and may produce the result you describe.

When the setup page runs it checks for the existence of the /Data/Sites/[SiteID]/skins folder where SiteID is usually 1 on a new install. If the folder does not exist it copies the contents from /Data/skins to /Data/Sites/[SiteID]/skins
Perhaps file system permissions prevented it from completing this task. If so delete the /Data/Sites/[SiteID]/skins folder and visit /Setup/Defauolt.aspx again or copy the files manually yourself.

If you build the mojoportal-complete.sln it will build all the features and files from features in separate projects like the mojoPortal.Features.* projects are copied up to the Web folder by a post build event. ie the dlls get copied up to the /Web/bin folder and .aspx and .ascx files etc also get copied up to specific locations.

You can't use the Visual Studio Publish feature to package a build because it only deploys files that are part of the Web project. This misses all the files copied by the post build because they are not part of the main Web project. I recommend packaging builds with the free UnleashIt tool which goes by file extension rather than project membership of files.

Also, you are of course free to do as you wish but I really don't recommend that you put the mojoportal source code in your TFS repository because I don't recommend you make changes to the mojoportal code. If you do that you make it difficult or impossible to get upgrades later.

Its best to keep all customizations in your own external proejcts and only put those in your TFS repository. I recommend work with mojoportal directly from our svn repository so you can always build your custom code against the latest mojoportal code.

The way I do it with customer projects is get a clean checkout of mojoportal, add a subfolder where my customer proejcts will go. Copy the mojoportal-copmplete.sln file and rename it then drop it back in to the root. Add the custom projects to this solution and remove alternate db projects or other projects you don't plan to use. Then commit the sub folder with your custom work to your repository while keeping the rest of mojoportal using its own repository so you can easily stay up to date with the constant improvements being made in mojoPortal.

In this scenario the only important file that can't live in within either repository is the custom .sln file because it has to be in the root which would be owned by the mojoportal repo if it were checked in. Though you could commit it somewhere in your repo with instructions that it needs to be put in the root of the tree.

Hope it helps,

Joe