I am thinking of auto generating scripts as a way to enusre all dependant dlls are included correctly. This will result in having nested scripts i assume this is not a issue. I will also mean i will get the same file being set for install in multiple places for diffenent features (as below) is this and issue?
. The answer to me is not that clear. In my scheme each dll we have will have a script file with an install command (with web block) each depent dll will have its script file included in this file. So as you see I will only have one script defining the web block but this script will be used multiple times.
[DEFINE WEB MEDIA J2 Builder]
Get Component Plugin\J2 Builder Selection State into Variable SELECTED
if Variable SELECTED Equals TRUE
Install Assembly C:\Source\Main\J2 Libraries\J2 Framework\J2.Framework.Base\bin\Release\J2.Framework.Base.dll to Global Assembly Cache
end
[DEFINE WEB MEDIA J2 Freedom]
Get Component Plugin\J2 Freedom Selection State into Variable SELECTED
if Variable SELECTED Equals TRUE
Install Assembly C:\Source\Main\J2 Libraries\J2 Framework\J2.Framework.Base\bin\Release\J2.Framework.Base.dll to Global Assembly Cache
end
I see that you have two different media bloks, "J2 Builder" & "J2 Freedom".
If you build the project that uses this code as WEB BASED EXE, it will produce respectively two media bloks.
If I am not wrong, those bloks contains the same " C:\Source\Main\J2 Libraries\J2 Framework\J2.Framework.Base\bin\Release\J2.Framework.Base.dl" file.
[DEFINE WEB MEDIA J2 Builder]
Get Component Plugin\J2 Builder Selection State into Variable SELECTED
if Variable SELECTED Equals TRUE
Include Script: J2 Builder Script
[DEFINE WEB MEDIA J2 Freedom]
Get Component Plugin\J2 Freedom Selection State into Variable SELECTED
if Variable SELECTED Equals TRUE
Include Script: J2 Freedom Script
end
J2 Builder Script and J2 Freedom Script will contain
...
[DEFINE WEB MEDIA J2.Framework.Base]
Install Assembly C:\Source\Main\J2 Libraries\J2 Framework\J2.Framework.Base\bin\Release\J2.Framework.Base.dll to Global Assembly Cache
...
Francesco,
My original question came from a half formed idea on how to create an automated process for ensuring that an assembly has all its dependants present in the install. The idea is to use a Visual studio add-in walk thought the dependences of a project and create a script. Remember each dependant will also have dependences; so this lead me to the idea of a script containing a install command and then including dependant scripts. As some assemblies are used in several places this approach means that a scrip maybe included several times, hence my question.
The issue you brought up with web blocks is more to do with our architecture that with this process and may mean AI is unusable for us. Our architecture is plug-in based i.e. the main application searches a known folder for specially marked dll’s an then loads them dynamically. So in the installer we have the main app as a feature and each plug-in as a feature to allow our users to pick and mix. Each of our plug-in dll’s has a set of dependant assemblies, many of the dependant assemblies are shared across multiple plugins. So the question is how do we define web blocks to allow them to be used in multiple features?
thanks for pointing this out, I hope to have a more clear view of your needs.
Generally WEB MEDIA BLOCKS are used with project features or runtimes.
The most common use is with application runtimes, for example; giving the opportunity to share a common runtime with different setup package that may require it. The same approach can be used with any file or group of files, you could also use a single WEB MEDIA BLOCK to handle a single file only.
The only limitation that you have to follow, it is to keep each WEB MEDIA BLOCK unique with its content, if these BLOCKS are used with a same setup package. This is due to the fact, that this mix could cause access errors with file informations access during setup execution.
My question is, when you say;
"Each of our plug-in dll’s has a set of dependant assemblies, many of the dependant assemblies are shared across multiple plugins"
Are these dependant assemblies installed with the same folder that contains the plugin?
Supposing that you have Plugin A and Plugin B and both have to use the same dependant assembly, a copy of this assembly is installed in each plugin folder?
If true, why do you not consider to create for each single PlugIn a completely different setup package, that could be download and installed only if required by feature selection?
The answer to your quetions is yes. To be more accurate the shared files are installed to the GAC, does this make a differance?
create for each single PlugIn a completely different setup package, that could be download and installed only if required by feature selection
This sounds complicated. I dont want the user to have to download a 10+ installers. The other solution is to have a selection installer that calls the selected plugins; which i not sure how to do.
Honestly I suppose that it is easier in this case.
Create a core WEB MEDIA BLOCK component that contains only all common assemblies dlls that have to be installed to the GAC.
Create a WEB MEDIA BLOCK for each possible plugin that you may need and eventually include with it, also any additional assemblies dlls (That it unique with a particular plugin).
Then with your setup package you will install by default the core WEB MEDIA BLOCK and by user selection, the selected plugins.
Doing this you will have each WEB MEDIA BLOCK unique with its content.
Unfortunately this approach misses dll's that are shared by some plugin but not all. Using the offline block may be the way to go for us as our app is relatively small in size and it's a feature that we are not that concurred with. This still however leaves us with understanding if we can have multiple Install commands that install the same file to the same place but for diffent features.
The limitation I am refering is only related with WEB MEDIA BLOCKS contents.
Of course you can have multiple Install commands that install the same file for diffent features, with OFFLINE Block. No limitation doing this.
