[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.dotnet.framework.setup

ClickOnce Deployment in a Plug-in architecture context

frank

4/17/2007 3:18:00 PM

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
2 Answers

Bryan Phillips

4/18/2007 12:20:00 AM

0

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.space...
Web Site: http://www.composables...



"Frank" <Frank@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

frank

4/18/2007 1:12:00 AM

0

Bryan,

Thanks for your answer. I'll look deeper into the Smart Client Software
Factory. I did not see it so I'll look it up. :)

Have a nice day.

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.space...
> Web Site: http://www.composables...
>
>
>
> "Frank" <Frank@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
>
>