CodePlex is basically just a front end to TFS - and from a developer perspective you actually interact with it through Visual Studio.
We need to be careful about folder structures as things get rolling. Each individual project within CSLAcontrib needs to have a top-level folder for that project, and then the project can be managed within that context.
If anyone has any other ideas about how to best manage/organize the overall folder structure, this is the thread to discuss it.
I don't think all the projects are even DLLs. Some are templates, others may be code files and still others may be tools (EXEs).
This is why I'm describing CSLAcontrib as a "project of projects", because there are quite a few good ideas out there (existing or future), and not all of them will fit into a single structure like a dll.
Actual CSLA .NET code files can't go on CSLAcontrib, because the licenses aren't compatible.
One non-goal of CSLAcontrib is to directly alter CSLA .NET itself. There are all sorts of IP issues around that, which I'd rather just avoid. Having watched what happens with OSS projects when contributors need to sign away their IP rights, I'd rather just not go there with CSLA .NET...
Instead, the goal of CSLAcontrib is to provide a home for the community to build tools, templates and other cool stuff around CSLA .NET.
I hate to reply to myself, but...
I added some folders for code-gen templates - just to get a feel for how this whole thing works. It seems pretty easy to work with through Team Explorer, which is nice.
\CodeGenTemplates\CodeSmith\VB
\CodeGenTemplates\CodeSmith\CS
But I can see already that care will need to be taken even within the templates sub-directory, since there are multiple template projects for CodeSmith alone. So my directory structure may not be good as-is, since it pre-supposes one set of templates per language, when in reality there are these multiple template efforts.
And having multiple efforts is not, imo, bad. Some may use inheritance, others partial classes, and still others may have more imaginative approaches - and that is a good thing!
So perhaps the structure needs to have another layer? Something like this:
\CodeGenTemplates\CodeSmith\Effort1\VB
\CodeGenTemplates\CodeSmith\Effort1\CS
\CodeGenTemplates\CodeSmith\Effort2\VB
\CodeGenTemplates\CodeSmith\Effort2\CS
Or perhaps each template project should have its own moniker, and the code-gen tool name should be dropped:
\CodeGenTemplates\Effort1\VB
\CodeGenTemplates\Effort1\CS
\CodeGenTemplates\Effort2\VB
\CodeGenTemplates\Effort2\CS
Thoughts?
(Even if your project is only VB or only C#, I recommend setting up the folder structure to handle the other language. Because if your templates are good and become widely used, you can bet good money someone will want them in the other language, and someone will port them if you don't ![Smile [:)]](/emoticons/emotion-1.gif)
)
I added my Codesmith templates (CSLA Express) to the CodeGenTemplates sub-project root. I think this sub-project root may get confusing when someone else adds an 'effort' of their own because the download will include all efforts within the sub-project.
Yes, I can see where this could get difficult.
I had removed the VB and CS folders at the CSLAExpress level, but you re-added them when you added CSLAExpress. I find that odd, but it must be the way TFS works...
I have re-removed the VB/CS folders, because I think they are problematic. I think that you can do check-in/out operations at the CSLAExpress sub-folder level to achieve a reasonable level of isolation. (or so I hope!!)
I have added Ricky's templates from GotDotNet. I think the structure is now fine as can be seen by example. Ricky and I have each created a specific language version and the current structure fits quite nicely.
Thanks for your efforts so far, happy to change the structure if you think its needed but at this stage I think it fits well.
Copyright (c) Marimer LLC