>"Paul Glavich" <glav@aspalliance.com-NOSPAM> wrote in message
news:u2zqAorzDHA.4060@TK2MSFTNGP11.phx.gbl...
> 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
>
>
> "Robert E. Maurer" <rmaurer@upstream.net> wrote in message
> news:020301c3ce4f$d3f2f880$a501280a@phx.gbl...
> > 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
>
>

"Robert E. Maurer" <rmaurer@upstream.net> wrote in message
news:020301c3ce4f$d3f2f880$a501280a@phx.gbl...
> 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

"Microsoft MSDN" <rmaurer@upstream.net> wrote in message
news:OSVMkbtzDHA.3468@TK2MSFTNGP11.phx.gbl...
> 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,
> >
> > 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
> >
> >
> > "Robert E. Maurer" <rmaurer@upstream.net> wrote in message
> > news:020301c3ce4f$d3f2f880$a501280a@phx.gbl...
> > > 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
> >
> >
>
>