ClickOnce Deployment in a Plug-in architecture context

[Guest]

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]

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

 

[Guest]

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