Naming and referencing

Topics: General discussion
Nov 20, 2007 at 7:51 AM
Edited Nov 20, 2007 at 10:15 AM
Hi,

Suppose I have an assembly that defines the namespace "Mycompany.Security". Several other projects references this assembly. Now my "Mycompany.Security" assembly extends some functionality in EntLib2. Suppose time has come to switch to EntLib3. I cant assume that all projects using my security DLL is compatible with EntLib3 so I have to create a new assembly of "Mycompany.Security" that consumes EntLib3 instead of EntLib2.

Now what do I name my new assembly and namespace? Best practice - looking at the Enterprise library - would be to call it the same. That would be the conclusion since "Microsoft.Practices.EnterpriseLibrary.Data" is called just that in all EntLib versions.

How do you guys deal with this? If you have a new version of a "base class" (and the old class must continue its own life) how do you name it? All thoughts are really welcome since this is becomming quite annoying...

EDIT:
To help you help me I'll just write where my thoughts are on the subject rigth now:

1. Maintain same name. In general this is just a major version bump. Create branch under original in Source control with new project.
2. Local copy of new project also as "branch" under original. Like: "c:\source\Mycompany.Security\1", where "1" then is the new branch...

Thus my idea sofar.

--
Werner
Nov 20, 2007 at 1:37 PM
Hi Werner,

I'm confused about your question. Is it about naming, versioning of assemblies, or source control?

Fernando
Nov 20, 2007 at 2:28 PM
Hi Fernando,

Well, my question probably involves all, but let me try to tweak my English a little better:

I want to update a commonly used project (App1) to consume EntLib3 instead of EntLib2, however I cant just start reference EntLib3 dll's because there are end-applications that are incompatible with EntLib3. I figure this must be a problem that people that have used EntLib over some version have come across. And maybe solved it in a way I could use?

Its probably about best practice. I have App1 that must evolve to use EntLib3 (no other changes) but at the same time I have a need that the same application does not change from using EntLib2. My first assumption here is that this can only be achieved if I let App1 evolve to a new application, say App2. However - apart from App1 using EntLib2 and App2 using EntLib3 they offer the exact same interface to consumers.

To be more practical I'll just put some usage to the above.
Lets say that App1 is really a VS project called "Itemplate.Security" with its own solution in Source Safe. So the question here is really: Does project "Itemplate.Security" evolve to "Itemplate.Security2" or do I create a new branch of the project so it continues with the same project name (and this would also mean same assembly name)?

I know what I would like to do here (branch) but it would be very interesting to hear how others cope with the same scenario. I realize that this is nowhere specific to EntLib and might aswell be asked in some newsgroup, however the problem was "created" by me downloading EntLib3 and I figured that a lot of EntLib users must be in some similar situation thinking "Wow I really want all my applications to be updated to use EntLib3"...

Thanks,

--
Werner











Nov 22, 2007 at 11:16 AM
Hi Werner,

I don't think there are unique answers for your questions. For the source code management aspect, I suggest you read the very good compendium of branching patterns available here http://www.cmcrossroads.com/bradapp/acme/branching/; in particular, those related to managing different releases like http://www.cmcrossroads.com/bradapp/acme/branching/branch-structs.html#OverlappingReleases and how to deal with third parties (like EL) http://www.cmcrossroads.com/bradapp/acme/branching/branch-structs.html#ThirdPartyLine. It's a lot of information but it describes pros and cons that I think are very helpful; keep in mind though that not all these patterns can be implemented with source safe.

Regarding the identity, is there any reason why you wouldn't use thea assembly versioning mechanism to deal with evolution?

Regards,
Fernando
Nov 23, 2007 at 11:58 AM

fsimonazzi wrote:
Regarding the identity, is there any reason why you wouldn't use thea assembly versioning mechanism to deal with evolution?


Hi Fernando,

Thanks for your post. I will look up those URL's right after my reply here.
About the identity - hm right now I cant think of a reason why I should'nt use the version-scheme. Makes sense thanks :)

--
Werner