views:

72

answers:

2

Honestly, I can't word my question any better without describing it.

  • I have a base project (with all its glory, dlls, resources etc) which is a CMS.
  • I need to use this project as a base for othe custom bake projects.
  • This base project is to be maintained and updated among all custom bake projects.
  • I use subversion (Collabnet and Tortise SVN)

I have two questions:

1 - Can I use subversion to share the base project among other projects

What I mean here is can I "Checkout" the base project into another "Checked Out" project and have both update and commit seperatley. So, to paint a picture, let's say I am working on a custom project and I modify the core/base prject in some way (which I know will suit the others) can I then commit those changes and upon doing so when I update the base project in the other "Checked out" resources will it pull the changes? In short, I would like not to have to manually deploy updated core files whenever I make changes into each seperate project.

2 - If I create a custom file (let's say an webcontrol or aspx page etc) can I have it compile seperatley from the base project

Another tricky one to explain. When I publish my web application it creates DLLs based on the namespaces of projects attached to it. So I may have a number of DLLs including the "Website's" namespace DLL, which could simply be website. I want to be able to make a seperate, custom, control which does not compile into those DLLs as the custom files should not rely on those DLLS to run. Is it as simple to set a seperate namespace for those files like CustomFiles.ProjectName for example?

Think of the whole idea as adding modules to the .NET project, I don't want the module's code in any of the core DLLs but I do need for module to be able to access the core dlls.

(There is no need for the core project to access the module code as it should be one way only in theory, though I reckon it woould not be possible anyway without using JSON/SOAP or something like that, maybe I am wrong.)

I want to create a pluggable environment much like that of Joomla/Wordpress as since PHP generally doesn't have to be compiled first I see this is the reason why all this is possible/easy. The idea is to allow pluggable themes, modules etc etc.

(I haven't tried simply adding .NET themes after compile/publish but I am assuming this is possible anyway? OR does the compiler need to reference items in the files?)


UPDATE (16/05/2010):

I posted a similar question with a little more detail for question 2 on Experts-Exchange. I don't want to post all that info here as it just will be too messy but it explains question 2 in greater detail.

+1  A: 

For your first question, you want to use svn externals. More details can be found here: http://svnbook.red-bean.com/en/1.0/ch07s03.html

For your second question, you need to create a seperate assembly and the easiest way is to create a new project within your solution. You can't have a single project emit 2 dll's (that I know of)

lomaxx
Yes, SVN externals seems the way to go here and is exactly what I was looking for as for question 1. I haven't tried to if a single project will allow mutliple Dlls but creating a seperate project seems more logical anyway. I read up a post in realtion to this (http://www.west-wind.com/Weblog/posts/8191.aspx) and I have yet to try it. My only concern is, yes, this method allows me to store custom controls, aspx pages, and resources in a seperate DLL and is logically what I am looking for, it seems I have to create a http handler. I'm not familiar with this, can it be in the custom assembly?
Anthony
+1  A: 

For your first question:

If the base project is a library then there is nothing stopping you from creating the following directory structure on your SVN:

  • Base project
  • Cool project nr 1
  • Cool project nr 2

All projects built on the Base project will include a relative reference and then everybody can checkout his Cool project X and the Base project and work on them. Checking-in changes for Base project will allow everybody else to see them by updating their Base project image. Advantage: only one SVN trunk required.

For your second question :

I tried my best, but I can't understand what you're asking :).

Ando
In ways I like your idea for queston and while it's not a wrong answer, it doesn't suit what I am doing, svn externals seems the way to go. You did help me solve another issue I was having.
Anthony
Thanks for the feedback :)
Ando