"Frank" <Fr***@discussions.microsoft.com> wrote in message
news:FE7D43E3-C5A7-4E43-A487-EF5A24667C57@microsoft.com:

> Hi all,
>
> I've been browsing through the different posts for a few days now but I
> didn't found the answer.
>
> We are considering the use of the ClickOnce deployment framework for a C#
> application that has a plug-in architecture.  Plug-ins are developed as
> independent DLL projects.  The plugins are loaded at run-time and are not
> really known by the application.  The plugins offer different services used
> that can be used by other services registered to a service broker in our
> application.  Our main application can be easily deployed with ClickOnce but
> we are wondering what to do with the DLL plugin projects?
>
> I saw some posts talking about manualy updating the code with the deployment
> API to get optional file groups for example.  Those groups of files would
> have been added via the MAGEUI.exe tool for example.  I understand how this
> could work.  But, what happens if we want versionning also on the DLL
> projects?  Each time a DLL is modified, the manifest files needs to be
> updated and our main application version incremented?  Causing software
> update on our users computers for the whole application eventhough only a DLL
> has changed?  Our plug-ins are role based also.  Some users won't have
> specific plug-ins because they don't need to. So triggering a full update on
> the application would cause these clients to try to update for nothing right?
>
> Is there a way to successfuly and easily manage DLL projects versioning?  Is
> this method the only way?  Anybody successfully deployed this kind of project
> architecture with ClickOnce?  Any ideas on how to resolve this?  Should we
> still consider ClickOnce?
>
> Another question we have, is it possible to create an MSI deployment that
> includes all external components (databases, etc..) and that would be able to
> update the application via ClickOnce updates?  Is it only to provide manifest
> files during the installation?  Does someone has documented such process?
>
> I hope my questions are clear enough to inspire you answers! :)
>
> Thanks!
>
> Frank

"Bryan Phillips" wrote:

> I have used ClickOnce in combination with the Smart Client Software
> Factory that includes that functionality that you are describing.  In my
> case, I did not care if the clients downloaded more files that they
> actually needed since the file sizes were small and the files were
> signed for the purposes of detecting differences between 2 files.
>
> If you can run your application with Full Trust, you can go much farther
> beyond this by using the classes in the System.Deployment namespace to
> programmatically decide when to check for updates, when to download
> them, and what to
> download.
>
> The Smart Client Software Factory supports roles so we just used that to
> limit the modules loaded when a user launched the application.
>
> To give you an idea of the production environment, the application was
> deployed to a Tier 1 automotive manufacturing environment and needed to
> stay up 24/7, so I limited the frequency of checking for updates.
>
> MSI is not needed for installation. ClickOnce already supports
> installation from CD, file share, and web server including prerequisites
> like .Net Framework 2.0 and SQL Server Express 2005 which are
> automatically installed as needed.  If you have other installations that
> need to be installed, you can configure the same behavior.
>
>
> --
> Bryan Phillips
> MCSD, MCDBA, MCSE
> Blog:  http://bphillips76.spaces.live.com
> Web Site:  http://www.composablesystems.net
>
>
>
> "Frank" <Fr***@discussions.microsoft.com> wrote in message
> news:FE7D43E3-C5A7-4E43-A487-EF5A24667C57@microsoft.com:
>
> > Hi all,
> >
> > I've been browsing through the different posts for a few days now but I
> > didn't found the answer.
> >
> > We are considering the use of the ClickOnce deployment framework for a C#
> > application that has a plug-in architecture.  Plug-ins are developed as
> > independent DLL projects.  The plugins are loaded at run-time and are not
> > really known by the application.  The plugins offer different services used
> > that can be used by other services registered to a service broker in our
> > application.  Our main application can be easily deployed with ClickOnce but
> > we are wondering what to do with the DLL plugin projects?
> >
> > I saw some posts talking about manualy updating the code with the deployment
> > API to get optional file groups for example.  Those groups of files would
> > have been added via the MAGEUI.exe tool for example.  I understand how this
> > could work.  But, what happens if we want versionning also on the DLL
> > projects?  Each time a DLL is modified, the manifest files needs to be
> > updated and our main application version incremented?  Causing software
> > update on our users computers for the whole application eventhough only a DLL
> > has changed?  Our plug-ins are role based also.  Some users won't have
> > specific plug-ins because they don't need to. So triggering a full update on
> > the application would cause these clients to try to update for nothing right?
> >
> > Is there a way to successfuly and easily manage DLL projects versioning?  Is
> > this method the only way?  Anybody successfully deployed this kind of project
> > architecture with ClickOnce?  Any ideas on how to resolve this?  Should we
> > still consider ClickOnce?
> >
> > Another question we have, is it possible to create an MSI deployment that
> > includes all external components (databases, etc..) and that would be able to
> > update the application via ClickOnce updates?  Is it only to provide manifest
> > files during the installation?  Does someone has documented such process?
> >
> > I hope my questions are clear enough to inspire you answers! :)
> >
> > Thanks!
> >
> > Frank
>
>