Merge module target audience...

Tech-Archive recommends: Fix windows errors by optimizing your registry

From: Christer (winterdk_at_hotmail.com)
Date: 02/25/04 

Date: 25 Feb 2004 07:08:23 -0800

Hi all!

At my company development is devided into two segments: Creating core
components (such as web controls, deployment service classes etc.) and
custom applications as defined by our customers.

As the core components are used in the many different applications we
create, we thinking of creating a merge module containing these
components. I've read the SDK regarding strong naming assemblies (for
registration in the GAC) and got it to work just fine.

Now, as I see it, there are two target audiences for the merge module:
The customers, that may have one or more applications made by us, and
the developers that are developing applications and use the
assemblies. As of now, we expect the merge module to be the only
source to the assemblies to avoid potential assembly mixup's.

How can we utilize the merge module in both situations properly? I
mean, if the developer installs the merge module via some installer,
the developer will have the right assemblies on the local machine.
However, referencing the installed assemblies is not easy, which may
force the developer to fetch the assemblies from the source of the
merge module (not good).

Including the core assembly in the custom application project and the
core component merge module in the install project strikes me as
redundant, as the "project output" from the applocation project also
contains the core components. How can this be avoided? Is there no
other way than to manually select the installer files myself?

Any feedback on how to keep core components confined (and still
usable) in custom application development would be appreciated.

Kind regards
Christer

Relevant Pages

  • Re: Interesting file managment feature of VS2005
    ... used amongst those assemblies. ... > to 'share' common business objects (ex. ... > PDC-2005 who basically told me sharing files in multiple projects wasn't ... > copying lead to more bugs (especially in a multiple developer environment) ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: C# Plugin system - same interface in two different assemblies...
    ... A developer using a skeleton plugin ... a user typing out the interface ... If you simply put one interface per assembly you're only including in the developers code once but then they have to have all the assemblies which they 'may' use... ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Scigraphica ?
    ... As a former developer I'm not sure myself. ... tidy up the core of the code. ... Annoy his mind here: pjf at cmp dot liv dot ack dot ook ...
    (comp.os.linux.misc)
  • Re: C# Plugin system - same interface in two different assemblies...
    ... Is it simpler for developers to duplicate code or not ... A developer cutting and pasting an interface from your SDK documentation? ... There's a bunch of reasons why using a single assembly for anything shared in commonality between assemblies is a poor idea instead of there being a method of equanimity. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: How to get started as a xhtml python mysql freelancer ?
    ... library and either build an application that has wide appeal and sell ... or sell yourself as a custom developer that can build the ... will reuse for the custom applications. ...
    (comp.lang.python)