468,537 Members | 1,810 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,537 developers. It's quick & easy.

Building my own class library framework

Hi all,

we are building our own class library framework, with stuff in it that
can be used in various projects at various clients.

Initially we had 4 assemblies with everything in it. Of course, when
project A only needs one class, it gets everything in the assembly
also; and we don't want that.

Now we create an assembly for each control or main functionality, so
the project has to add a reference to the assembly it really needs.
But now, we introduce danger for circular references and dependency
issues; it's harder to maintain.

Is there a clean solution to make sure that projects only get the
classes they really need, but without the difficulties of having a lot
of assemblies? Maybe select what components are needed at build time
and then build an assembly with only the needed stuff?

What are your ideas?
Dec 4 '07 #1
12 2240
On Dec 4, 11:21 am, Ludwig <lstuyc...@gmail.comwrote:
we are building our own class library framework, with stuff in it that
can be used in various projects at various clients.

Initially we had 4 assemblies with everything in it. Of course, when
project A only needs one class, it gets everything in the assembly
also; and we don't want that.
Why not? What problem are you running into?

After all, think of the main .NET framework - I doubt that you're
using all the classes in mscorlib.dll or System.dll...

In my view it's much easier to maintain a small number of large
assemblies than vice versa.

Jon
Dec 4 '07 #2
On 4 dec, 12:39, "Jon Skeet [C# MVP]" <sk...@pobox.comwrote:
On Dec 4, 11:21 am, Ludwig <lstuyc...@gmail.comwrote:
we are building our own class library framework, with stuff in it that
can be used in various projects at various clients.
Initially we had 4 assemblies with everything in it. Of course, when
project A only needs one class, it gets everything in the assembly
also; and we don't want that.

Why not? What problem are you running into?

After all, think of the main .NET framework - I doubt that you're
using all the classes in mscorlib.dll or System.dll...

In my view it's much easier to maintain a small number of large
assemblies than vice versa.

Jon
No problem - but the thing is, that if the client needs a particular
control, he should just get that control instead of the whole library,
with components he didn't pay for.
Dec 4 '07 #3


"Ludwig" wrote:
On 4 dec, 12:39, "Jon Skeet [C# MVP]" <sk...@pobox.comwrote:
On Dec 4, 11:21 am, Ludwig <lstuyc...@gmail.comwrote:
we are building our own class library framework, with stuff in it that
can be used in various projects at various clients.
Initially we had 4 assemblies with everything in it. Of course, when
project A only needs one class, it gets everything in the assembly
also; and we don't want that.
Why not? What problem are you running into?

After all, think of the main .NET framework - I doubt that you're
using all the classes in mscorlib.dll or System.dll...

In my view it's much easier to maintain a small number of large
assemblies than vice versa.

Jon

No problem - but the thing is, that if the client needs a particular
control, he should just get that control instead of the whole library,
with components he didn't pay for.
That is a very different question then. You could look at some form of
licensing scheme. Alternatively you could create libraries for each of your
sales products. Each product could depend on one or more core assemblies
that are distributed with the product.

Dec 4 '07 #4
On Dec 4, 12:29 pm, Ludwig <lstuyc...@gmail.comwrote:
No problem - but the thing is, that if the client needs a particular
control, he should just get that control instead of the whole library,
with components he didn't pay for.
As Mike says, that should be done on a licensing basis - in
particular, it makes it a lot easier for your clients if all they need
to do is modify their license file (or registry entry or whatever)
instead of adding hundreds of references, if they need to use multiple
controls (and pay for them).

Jon
Dec 4 '07 #5
On 4 Dec, 13:21, "Jon Skeet [C# MVP]" <sk...@pobox.comwrote:
On Dec 4, 12:29 pm, Ludwig <lstuyc...@gmail.comwrote:
No problem - but the thing is, that if the client needs a particular
control, he should just get that control instead of the whole library,
with components he didn't pay for.

As Mike says, that should be done on a licensing basis - in
particular, it makes it a lot easier for your clients if all they need
to do is modify their license file (or registry entry or whatever)
instead of adding hundreds of references, if they need to use multiple
controls (and pay for them).

Jon
Ditto, and think of the other advantages. Imagine having one control
which can then have a variety of levels of license applied to it. A
basic license for basic functionality, and a gold plated license which
enables the super special mode.
Dec 4 '07 #6

"Ludwig" <ls*******@gmail.comwrote in message
news:01**********************************@f3g2000h sg.googlegroups.com...
Hi all,

we are building our own class library framework, with stuff in it that
can be used in various projects at various clients.

Initially we had 4 assemblies with everything in it. Of course, when
project A only needs one class, it gets everything in the assembly
also; and we don't want that.

Now we create an assembly for each control or main functionality, so
the project has to add a reference to the assembly it really needs.
But now, we introduce danger for circular references and dependency
issues; it's harder to maintain.

Is there a clean solution to make sure that projects only get the
classes they really need, but without the difficulties of having a lot
of assemblies? Maybe select what components are needed at build time
and then build an assembly with only the needed stuff?

What are your ideas?
The license idea that others have suggested sounds like the best
approach -if- you're shipping a library to clients for their use building
their own apps.

OTOH, the way I understood your question is that -you- are doing the app
building and you want to be able to only include certain controls from your
library depending on what your client has paid you to do. If this is the
case, I would be interested in what suggestions others might have.

Dec 4 '07 #7
On 4 dec, 15:06, "BobF" <rNfOrSePeA...@charter.netwrote:
"Ludwig" <lstuyc...@gmail.comwrote in message

news:01**********************************@f3g2000h sg.googlegroups.com...


Hi all,
we are building our own class library framework, with stuff in it that
can be used in various projects at various clients.
Initially we had 4 assemblies with everything in it. Of course, when
project A only needs one class, it gets everything in the assembly
also; and we don't want that.
Now we create an assembly for each control or main functionality, so
the project has to add a reference to the assembly it really needs.
But now, we introduce danger for circular references and dependency
issues; it's harder to maintain.
Is there a clean solution to make sure that projects only get the
classes they really need, but without the difficulties of having a lot
of assemblies? Maybe select what components are needed at build time
and then build an assembly with only the needed stuff?
What are your ideas?

The license idea that others have suggested sounds like the best
approach -if- you're shipping a library to clients for their use building
their own apps.

OTOH, the way I understood your question is that -you- are doing the app
building and you want to be able to only include certain controls from your
library depending on what your client has paid you to do. If this is the
case, I would be interested in what suggestions others might have.- Tekst uit oorspronkelijk bericht niet weergeven -

- Tekst uit oorspronkelijk bericht weergeven -
What about this: Yesterday I wrote a test application that reads my
visual studio solution file; then it finds out the visual studio
project files and reads them, en eventually I have a list of all code
files in my solution. I check the ones I want and click a build
button; and then an assembly is build with only the selected code
files. This assembly can then be given to the client, containing only
what he needs.

I also save these profiles so that I can load these settings later and
regenerate the assembly again, or modify the selected code files
first.

Still have to think about versioning, but what do you think about this
approach?
Dec 5 '07 #8
On Dec 5, 7:00 am, Ludwig <lstuyc...@gmail.comwrote:

<snip>
What about this: Yesterday I wrote a test application that reads my
visual studio solution file; then it finds out the visual studio
project files and reads them, en eventually I have a list of all code
files in my solution. I check the ones I want and click a build
button; and then an assembly is build with only the selected code
files. This assembly can then be given to the client, containing only
what he needs.

I also save these profiles so that I can load these settings later and
regenerate the assembly again, or modify the selected code files
first.

Still have to think about versioning, but what do you think about this
approach?
I think it's a maintenance nightmare compared with all your clients
having the same assembly (for any particular version) and using
licensing to prevent use of certain features.

If a client reports a bug, you would need to test against that
particular build, and ensure that whatever fix you put out doesn't
break any of the other myriad combinations. Furthermore, every time a
customer needs a new version you need to go through the same custom
build procedure.

Jon
Dec 5 '07 #9
On 5 dec, 10:10, "Jon Skeet [C# MVP]" <sk...@pobox.comwrote:
On Dec 5, 7:00 am, Ludwig <lstuyc...@gmail.comwrote:

<snip>
What about this: Yesterday I wrote a test application that reads my
visual studio solution file; then it finds out the visual studio
project files and reads them, en eventually I have a list of all code
files in my solution. I check the ones I want and click a build
button; and then an assembly is build with only the selected code
files. This assembly can then be given to the client, containing only
what he needs.
I also save these profiles so that I can load these settings later and
regenerate the assembly again, or modify the selected code files
first.
Still have to think about versioning, but what do you think about this
approach?

I think it's a maintenance nightmare compared with all your clients
having the same assembly (for any particular version) and using
licensing to prevent use of certain features.

If a client reports a bug, you would need to test against that
particular build, and ensure that whatever fix you put out doesn't
break any of the other myriad combinations. Furthermore, every time a
customer needs a new version you need to go through the same custom
build procedure.

Jon
true.. maybe I should clarify that I'm not talking about real
'products' that we ship, but rather independent stuff like windows and
web controls, validation methods, a random number generator, and so
on; things than can be used in the client's products (that we also
develop). The idea is that if we can reuse things that are in the
class library, then we have shorter development time - but we don't
want everything in the library that we don't need now to be available
to the customer.

Anyway, as most of you propose, a licensing scheme would be the best
thing to do I guess.
Dec 5 '07 #10
On 5 dec, 10:47, Ludwig <lstuyc...@gmail.comwrote:
On 5 dec, 10:10, "Jon Skeet [C# MVP]" <sk...@pobox.comwrote:


On Dec 5, 7:00 am, Ludwig <lstuyc...@gmail.comwrote:
<snip>
What about this: Yesterday I wrote a test application that reads my
visual studio solution file; then it finds out the visual studio
project files and reads them, en eventually I have a list of all code
files in my solution. I check the ones I want and click a build
button; and then an assembly is build with only the selected code
files. This assembly can then be given to the client, containing only
what he needs.
I also save these profiles so that I can load these settings later and
regenerate the assembly again, or modify the selected code files
first.
Still have to think about versioning, but what do you think about this
approach?
I think it's a maintenance nightmare compared with all your clients
having the same assembly (for any particular version) and using
licensing to prevent use of certain features.
If a client reports a bug, you would need to test against that
particular build, and ensure that whatever fix you put out doesn't
break any of the other myriad combinations. Furthermore, every time a
customer needs a new version you need to go through the same custom
build procedure.
Jon

true.. maybe I should clarify that I'm not talking about real
'products' that we ship, but rather independent stuff like windows and
web controls, validation methods, a random number generator, and so
on; things than can be used in the client's products (that we also
develop). The idea is that if we can reuse things that are in the
class library, then we have shorter development time - but we don't
want everything in the library that we don't need now to be available
to the customer.

Anyway, as most of you propose, a licensing scheme would be the best
thing to do I guess.- Tekst uit oorspronkelijk bericht niet weergeven -

- Tekst uit oorspronkelijk bericht weergeven -
I was just a few second late in posting my findings Ludwig. You came
to the same conclusion I had. It could turn out a nightmare
maintaining all different versions for different clients.
If the license option is feasable, I would go that way. If providing a
new license key (file, registry entry) is sufficient to unlock new
features in an assembly, that would be great.

kind regards,
Pascal
Dec 5 '07 #11
On 5 dec, 10:55, pascal.des...@gmail.com wrote:
On 5 dec, 10:47, Ludwig <lstuyc...@gmail.comwrote:


On 5 dec, 10:10, "Jon Skeet [C# MVP]" <sk...@pobox.comwrote:
On Dec 5, 7:00 am, Ludwig <lstuyc...@gmail.comwrote:
<snip>
What about this: Yesterday I wrote a test application that reads my
visual studio solution file; then it finds out the visual studio
project files and reads them, en eventually I have a list of all code
files in my solution. I check the ones I want and click a build
button; and then an assembly is build with only the selected code
files. This assembly can then be given to the client, containing only
what he needs.
I also save these profiles so that I can load these settings later and
regenerate the assembly again, or modify the selected code files
first.
Still have to think about versioning, but what do you think about this
approach?
I think it's a maintenance nightmare compared with all your clients
having the same assembly (for any particular version) and using
licensing to prevent use of certain features.
If a client reports a bug, you would need to test against that
particular build, and ensure that whatever fix you put out doesn't
break any of the other myriad combinations. Furthermore, every time a
customer needs a new version you need to go through the same custom
build procedure.
Jon
true.. maybe I should clarify that I'm not talking about real
'products' that we ship, but rather independent stuff like windows and
web controls, validation methods, a random number generator, and so
on; things than can be used in the client's products (that we also
develop). The idea is that if we can reuse things that are in the
class library, then we have shorter development time - but we don't
want everything in the library that we don't need now to be available
to the customer.
Anyway, as most of you propose, a licensing scheme would be the best
thing to do I guess.- Tekst uit oorspronkelijk bericht niet weergeven -
- Tekst uit oorspronkelijk bericht weergeven -

I was just a few second late in posting my findings Ludwig. You came
to the same conclusion I had. It could turn out a nightmare
maintaining all different versions for different clients.
If the license option is feasable, I would go that way. If providing a
new license key (file, registry entry) is sufficient to unlock new
features in an assembly, that would be great.

kind regards,
Pascal- Tekst uit oorspronkelijk bericht niet weergeven -

- Tekst uit oorspronkelijk bericht weergeven -
Is there a way to lock/unlock functionalities by providing different
licence keys, and if so, how does that work? If someone could provide
me with a link here I can find information about this, that would be
great!!
Dec 5 '07 #12
On 5 dec, 11:00, Ludwig <lstuyc...@gmail.comwrote:
On 5 dec, 10:55, pascal.des...@gmail.com wrote:


On 5 dec, 10:47, Ludwig <lstuyc...@gmail.comwrote:
On 5 dec, 10:10, "Jon Skeet [C# MVP]" <sk...@pobox.comwrote:
On Dec 5, 7:00 am, Ludwig <lstuyc...@gmail.comwrote:
<snip>
What about this: Yesterday I wrote a test application that reads my
visual studio solution file; then it finds out the visual studio
project files and reads them, en eventually I have a list of all code
files in my solution. I check the ones I want and click a build
button; and then an assembly is build with only the selected code
files. This assembly can then be given to the client, containing only
what he needs.
I also save these profiles so that I can load these settings later and
regenerate the assembly again, or modify the selected code files
first.
Still have to think about versioning, but what do you think about this
approach?
I think it's a maintenance nightmare compared with all your clients
having the same assembly (for any particular version) and using
licensing to prevent use of certain features.
If a client reports a bug, you would need to test against that
particular build, and ensure that whatever fix you put out doesn't
break any of the other myriad combinations. Furthermore, every time a
customer needs a new version you need to go through the same custom
build procedure.
Jon
true.. maybe I should clarify that I'm not talking about real
'products' that we ship, but rather independent stuff like windows and
web controls, validation methods, a random number generator, and so
on; things than can be used in the client's products (that we also
develop). The idea is that if we can reuse things that are in the
class library, then we have shorter development time - but we don't
want everything in the library that we don't need now to be available
to the customer.
Anyway, as most of you propose, a licensing scheme would be the best
thing to do I guess.- Tekst uit oorspronkelijk bericht niet weergeven -
- Tekst uit oorspronkelijk bericht weergeven -
I was just a few second late in posting my findings Ludwig. You came
to the same conclusion I had. It could turn out a nightmare
maintaining all different versions for different clients.
If the license option is feasable, I would go that way. If providing a
new license key (file, registry entry) is sufficient to unlock new
features in an assembly, that would be great.
kind regards,
Pascal- Tekst uit oorspronkelijk bericht niet weergeven -
- Tekst uit oorspronkelijk bericht weergeven -

Is there a way to lock/unlock functionalities by providing different
licence keys, and if so, how does that work? If someone could provide
me with a link here I can find information about this, that would be
great!!- Tekst uit oorspronkelijk bericht niet weergeven -

- Tekst uit oorspronkelijk bericht weergeven -
Meanwhile I've found http://windowsclient.net/articles/Licensing.aspx,
maybe this will do the trick.
Dec 5 '07 #13

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

17 posts views Thread by Nick | last post: by
1 post views Thread by The_Enforcer | last post: by
5 posts views Thread by Terence | last post: by
8 posts views Thread by Jacob Arthur | last post: by
reply views Thread by Herman Jones | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.