Yeah. I agree. Sometimes with "utility" helper functions, I find that I
fairly often want to tweak them as new situations arise or add new methods
as I think of them while working on a project. Simply adding a reference to
the compiled DLL is a bit productivity killing. I think adding the classes
as a Link (as I described) or using your technique (good too) is just way
more convenient.
[quoted text, click to view] "surturz" <surturz@newsgroup.nospam> wrote in message
news:7FFFF813-21E9-4A1B-9D0D-FAE905CB157B@microsoft.com...
>I prefer creating a separate Project for the common code, then adding the
> Project to each Solution.
>
> That way you can see the common code in each Solution. If you have the
> same
> common Project in two Solutions, and they are both open, VB 2005 is even
> smart enough to warn you if you change the common code in one or the other
> Solution.
>
> -SurturZ
>
> "Family Tree Mike" wrote:
>
>> I would strongly recommend making a class library project which contains
>> your
>> common/utility classes. As you need the classes in other projects, add a
>> reference to the dll. This will make maintanance much easier in the long
>> run.
>>
>> "Guy Cohen" wrote:
>>
>> >
>> > Hi all
>> > I made some common used classes (e.g. config reader, email sender, user
>> > login class).
>> >
>> > When I add them to the project - a copy of the file is being made.
>> >
>> > How do I avoid that?
>> >
>> > I want them to stay in (e.g.): c:\myfiles\vb\common classes
>> > So if I update them - all projects will be with latest updates?
>> >
>> > TIA
>> > Guy Cohen
>> >
>> >
>> >
But it makes tweaking them and adding new functions (very common with
utility/helper classes) laborious. How is your suggestion easier to maintain
than the "Add Item As Link" feature or using Surturz technique described in
this thread?
"Family Tree Mike" <FamilyTreeMike@discussions.microsoft.com> wrote in
message news:D2D3DA72-FB1E-40D8-BD84-A094A1842DAF@microsoft.com...
[quoted text, click to view] >I would strongly recommend making a class library project which contains
>your
> common/utility classes. As you need the classes in other projects, add a
> reference to the dll. This will make maintanance much easier in the long
> run.
>
> "Guy Cohen" wrote:
>
>>
>> Hi all
>> I made some common used classes (e.g. config reader, email sender, user
>> login class).
>>
>> When I add them to the project - a copy of the file is being made.
>>
>> How do I avoid that?
>>
>> I want them to stay in (e.g.): c:\myfiles\vb\common classes
>> So if I update them - all projects will be with latest updates?
>>
>> TIA
>> Guy Cohen
>>
>>
>>
I understand and agree so long as you are careful to not make a breaking
change when going back to one of the other projects.
[quoted text, click to view] "CMoya" wrote:
> Yeah. I agree. Sometimes with "utility" helper functions, I find that I
> fairly often want to tweak them as new situations arise or add new methods
> as I think of them while working on a project. Simply adding a reference to
> the compiled DLL is a bit productivity killing. I think adding the classes
> as a Link (as I described) or using your technique (good too) is just way
> more convenient.
>
> "surturz" <surturz@newsgroup.nospam> wrote in message
> news:7FFFF813-21E9-4A1B-9D0D-FAE905CB157B@microsoft.com...
> >I prefer creating a separate Project for the common code, then adding the
> > Project to each Solution.
> >
> > That way you can see the common code in each Solution. If you have the
> > same
> > common Project in two Solutions, and they are both open, VB 2005 is even
> > smart enough to warn you if you change the common code in one or the other
> > Solution.
> >
> > -SurturZ
> >
> > "Family Tree Mike" wrote:
> >
> >> I would strongly recommend making a class library project which contains
> >> your
> >> common/utility classes. As you need the classes in other projects, add a
> >> reference to the dll. This will make maintanance much easier in the long
> >> run.
> >>
> >> "Guy Cohen" wrote:
> >>
> >> >
> >> > Hi all
> >> > I made some common used classes (e.g. config reader, email sender, user
> >> > login class).
> >> >
> >> > When I add them to the project - a copy of the file is being made.
> >> >
> >> > How do I avoid that?
> >> >
> >> > I want them to stay in (e.g.): c:\myfiles\vb\common classes
> >> > So if I update them - all projects will be with latest updates?
> >> >
> >> > TIA
> >> > Guy Cohen
> >> >
> >> >
> >> >
For me, it seems easier to determine which one dll needs an update for a
patch, rather than finding which multiple dlls refer to the class, to be
built for the patch.
It really comes down to how the team builds and distributes software. I
appologize for implying that the way we do it was best for everyone. I will
say it works for us.
[quoted text, click to view] "CMoya" wrote:
> But it makes tweaking them and adding new functions (very common with
> utility/helper classes) laborious. How is your suggestion easier to maintain
> than the "Add Item As Link" feature or using Surturz technique described in
> this thread?
>
> "Family Tree Mike" <FamilyTreeMike@discussions.microsoft.com> wrote in
> message news:D2D3DA72-FB1E-40D8-BD84-A094A1842DAF@microsoft.com...
> >I would strongly recommend making a class library project which contains
> >your
> > common/utility classes. As you need the classes in other projects, add a
> > reference to the dll. This will make maintanance much easier in the long
> > run.
> >
> > "Guy Cohen" wrote:
> >
> >>
> >> Hi all
> >> I made some common used classes (e.g. config reader, email sender, user
> >> login class).
> >>
> >> When I add them to the project - a copy of the file is being made.
> >>
> >> How do I avoid that?
> >>
> >> I want them to stay in (e.g.): c:\myfiles\vb\common classes
> >> So if I update them - all projects will be with latest updates?
> >>
> >> TIA
> >> Guy Cohen
> >>
> >>
> >>
Don't see what you're looking for? Try a search.
