Distributed Application Deployment

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Robert E. Maurer - 29 Dec 2003 21:07 GMT

Hello,

I am slowly migrating from VB6 development to C#
development in .Net. I am having some trouble with the
layout and design of my application as it relates to
deployment.

As a general overview, our application has a base set of
functionality that can be purchased, and then there is
more functionality that can be bolted on and installed
separately.

Traditionaly, I would have developed VB6 COM components
and host them inside COM+ so I could use the application
security to specify a user for SQL Server access and the
connection pooling of SQL Server connections. Now,
because of the registry, I can develop my application and
deploy the COM components and then later, I can deploy an
add-on to my app that uses those COM objects and I don't
have to install them I can just use them since they are
installed and registered.

Also, if I needed to change how authorzation worked or
fix a bug in the authorization component, I would just
send a patch to the client and update that one component
in the shared folder and upadate COM+ and all
appliations/compents were updated.

Now, with .Net, I am not sure how to break up my
application into components and I am not sure how to
effectively deploy those components. I have some things
that I would like to componetize, such as data access,
authorization, XML process that I can take advantage of
and use in many different applications (i.e. All of our
support applications need to authenticate the user.)

I would like to be able to install the authentication
piece as a stand alone component and then each appliation
I install later could make use of that installed
component.

I am not sure if I need to use Enterprise Services, if I
should install my assemblies in the Global Assembly
Cache, or should I just get rid of the whole "component"
design and just add all that reuseable code into to each
assebly.

I realize that I could install some components as web
services and then have all other applications access it
that way, but that seems like a lot of overhead as well
as being a bit to slow.

I have read many of the articles on the MS sight, but I
can't find anything that specifically addresses these
issues.

Any help would be appreciated.

Robert

Reply to this Message

Paul Glavich - 30 Dec 2003 09:47 GMT

Hi Robert,

My 2 cents worth :-
- Stick with the component design. If I read your comments right, you have
multiple applications that require access to these components and you would
require a componentized design to make this work properly.
- Given this, you at least need to install your components in the GAC so
that they are globally available (machine wide) and you get the benefit of
multiple versions of the same library/component (if thats a feature you
need).
- If you install into COM+, your components need to be in the GAC anyway.
Are you using trxs, object pooling, COM+ role based security or any specific
COM+ functionality? If so, then hosting in COM+ is a no brainer.
- It sounds like you also require specific identities for some components,
in which case, COM+ is easy to setup for this task.
- Using COM+ will incurr a performance hit, as opposed to using native .Net
components though, although its not major (generally speaking).
- You can still use the registry for storing your machine wide settings for
these components or alternatively store your config files in WINDIR\System32
directory (although I personally would not recommend this)

HTH

--
- Paul Glavich

> Hello,
>
[quoted text clipped - 55 lines]
>
> Robert

Reply to this Message

Microsoft MSDN - 30 Dec 2003 13:14 GMT

Paul,

Thanks for your reply. Yes that helps a little. That is what I have been
trying to do. Currently we are only using COM+ for ADO connection pooling,
automatic SQL Server transactions (no begin or end tran needed,) and to
allow our component to run as a specific user instead of the interactive
user. I think we can live without most of that except the connection
pooling.

Anyway, my specific problem lies in the fact that if I create a data access
component or an authentication component on my development machine, should I
install it into the GAC or leave it where it compiles. Then when I start
developing the the second project in the solution, I can use project
references to get the correct reference to the component. When I got to
install the application, it is going to place a copy of the component
assembly in it's destination folder and, setup will install it into the
global assembly cache for me. Now, when I create a new solution or add a
third project to the solution and reference the authorization component and
then finally create my installation for the new app, do I install and
attempt to have setup install that component into the general assembly cache
or do I exclude it from the install since I and installing an add-on and
that component must already be on the target client machine?

Therein lies my confusion. I am not sure if I should build each separate
install to fully install and configure all components or do I use my
knowledge of what is on the client machine and only install what is needed.
It just seems wrong that if I have 6 console applications installed in 6
different folders that I have to install 6 copies of my authenticate dll.
Basically we have a suite of products (similar to how MS Office has word,
excell, powerpoint, etc.) but they are all distinct entities and do not
precisely fall under one heading.

>"Paul Glavich" <glav@aspalliance.com-NOSPAM> wrote in message

news:u2zqAorzDHA.4060@TK2MSFTNGP11.phx.gbl...

> Hi Robert,
>
[quoted text clipped - 81 lines]
> >
> > Robert

Reply to this Message

Paul Glavich - 09 Feb 2004 11:17 GMT

Sorry for the late reply.

When developing, I'd just use project references to build and compile. Your
installation script should check for a correct version of the assembly in
the GAC and if not there, install it.

The GAC is the place for sharing common code, however it does require some
management. Take a cue from the .Net core assemblies. They are shared in the
GAC.

Having said that, if you envision having multiple copies of your
authentication library, with each being a little different or in any way
specific to the application they are servicing, then keep them in the app
directory and not inthe GAC.

HTH,

--
- Paul Glavich

> Paul,
>
[quoted text clipped - 120 lines]
> > >
> > > Robert

Reply to this Message

Distributed Application Deployment

Free Magazines