We are writing an installer where few custom programs are written to update selective components.
Requirement is to keep few components downloadable which could be updated later by custom programs. Along with that an initial version of components should be delivered with installer file.
If we pack components with installer then dat files are not available to download neither updater knows the update URL.
Any suggestions how this could be achieved?
You mark single components as downloadable on the
Files->Installation Components->Options
tab.
In the media wizard, on the "Data files" step, you have to choose the "Downloadable" option and provide the download URL.
A custom installer application can install a downloadable component with a "Download and install component" action.
Related
I want to build an installer as Jira by install4j but they have some custom actions in the installer. I am wondering that is there a method to decode installer or reserve an installer made by install4j to install4j project file? So I can refer those to make my own.
Thank you.
No this is not possible. The installer is a binary artifact and while it does have a config file in .install4j/i4jparams.config it does not contain all required information for reversing it.
I would like to develop GUI application with plugins. The plugins contains VCL Forms which are inherited from Base Forms in the Plugin-Core library. The main application can select which plugin to load dynamically, and then which Form subclasses to display.
In the users side, I would like to deploy main .EXE, the Plugin-Core library, and many plugin libraries for different models. I could release new or modify existed plugin libraries to users to display new Forms for new devices without modifying the main .EXE and the Plugin-Core library.
The first version I developed uses DLL approach, namely both the Plugin-Core library and the plugins are in DLL form. Everything is just fine on the users side. However, in the developers side, the plugin DLL project can not be linked without Base Forms defined in the Plugin-Core DLL project. It means that the Base Forms are actually statically linked in each plugin DLL project, and if someday I modify the Base Forms and rebuild the Plugin-Core DLL project, I have to rebuild all plugin DLL projects and re-release plugin .DLL s to users, too.
After searching and asking in StackOverflow, I realized the limitation that VCL Forms can NOT be inherited across DLL boundary is due to RTTI conflict(?). The suggested solution is to modify the libraries from DLL to BPL form, which is the second version I developed. Everything is also fine except the following two:
The dynamic loaded Form from plugin BPL is separated from the main .EXE in Windows taskbar. It is not what I desired. The solution is that I enabled "Build with runtime packages" in the .EXE project.
After I enabled "Build with runtime packages" in the .EXE project, I have to release other .BPLs to the users, such as vcl.bpl and rtl.bpl. This is not perfectly what I desired.
I would like to know that the above two issues can be resolved at the same time? In my thought, I could resolve both two issues if I:
Disable "Build with runtime packages" in .EXE project.
Enable "Build with runtime packages" in all .BPL projects.
In this way, the .EXE can run without vcl.bpl and rtl.bpl bundled, and the plugin .BPL s can be loaded successfully because the dependent units are already part of the main .EXE? Am I correct? However, the "Build with runtime packages" checkbox is disabled in all .BPL project options. As a result I don't have a chance to check whether the solution works or not. I am sorry for the lengthy description and I can not attach picture due to company's Internet security policy.
The dynamic loaded Form from plugin BPL is separated from the main .EXE in Windows taskbar. It is not what I desired. The solution is that I enabled "Build with runtime packages" in the .EXE project.
After loading a BPL, pass the EXE's Application.Handle to the BPL and assign it to the BPL's own Application.Handle before it creates any Form instances.
Alternatively, on Windows 7+, you can have the EXE call SetCurrentProcessExplicitAppUserModelID() to establish a App ID for its taskbar button. Then each Form in the BPLs can use SHGetPropertyStoreForWindow() and IPropertyStore.SetValue(PKEY_AppUserModel_ID) to set the same App ID for their windows. Multiple windows with the same App ID are grouped together under a single taskbar button.
See MSDN for more details: Application User Model IDs (AppUserModelIDs)
I would like to know that the above two issues can be resolved at the same time? In my thought, I could resolve both two issues if I:
Disable "Build with runtime packages" in .EXE project.
Enable "Build with runtime packages" in all .BPL projects.
In this way, the .EXE can run without vcl.bpl and rtl.bpl bundled, and the plugin .BPL s can be loaded successfully because the dependent units are already part of the main .EXE? Am I correct?
No. BPLs cannot use the EXE's built-in units like that.
If you disable "Build with Runtime Packages", the RTL/VCL units will be statically linked into the executable file. The problem with doing that is multiple copies of a given unit cannot be loaded in memory at the same time, so you wouldn't be able to load multiple BPLs together (or even at all) if the same RTL/VCL units are statically linked into multiple BPLs, or even the EXE itself.
If you enable "Build with Runtime Packages", the executable file will be dependent on the RTL/VCL BPLs, which must then be deployed.
So, if your EXE and BPLs share common units, those units must be loaded via shared BPL(s) so only one copy of the units exist in memory. There is no avoiding that when writing custom BPLs. Which means at a minimum you usually have to deploy RTL.BPL if you are using basic RTL functionalities, and VCL.BPL for UIs.
I have an update site that contains some 100 - 200 features and many more plugins. For some users all of these are needed, so I'd like to simplify the installation process by creating one feature that they can install. This feature would then contain all the contents of the update site.
I've created a new feature project and my plan is to add the contents of the original update site as included features and plugins in this project.
Problems is; In my feature project, when adding feature in the "included features" tab, I can only add features that are currently installed in my Eclipse platform. I'd rather not install those 200 features just so I can add them.
Is there a way to work around this?
Without the features installed in your target platform, you will need to edit the feature.xml file directly. All you need to do is to add the following for each feature that you want to include:
<includes
id="<add_feature_id>"
version="0.0.0"/>
Your build process (PDE or tycho) should add the proper version numbers for you.
I think you should have a detailed look at the Eclipse target platform concept. The features don't need to be installed in your current Eclipse platform (i.e. the IDE), they need to be installed in the target platform to be available for an update site.
If you never defined a target platform, your currently running application will be taken as IDE, and that is where your confusion might come from.
When I try to manipulate a feature I only need to have them in my workspace. No reason to install them.
I'm reading through the nuget documentation and I don't completely understand how nuget works.
I have 2 third party dll's that I have been asked to turn into a nuget package, so that our local developers can just install them to a project via nuget. This would be something that we would host locally.
Does this mean I just create a project in vs and drop the dll's in the project or do I use something like the package explorer.
I apologize in advance if this is a silly question, however I am an absolute beginner when it comes to Nuget, etc..
Any tips would be greatly appreciated.
The simplest and fastest way to get a nuget package up and running is to just fire up package explorer --> create a new package --> drag and drop your dlls into the "Package Contents" area, it'll ask you whether you want the dlls in the "lib" folder, which you do --> create a bit of metadata about the package, ie give it a description and version and whatnot, and then just save it.
After you save it, you can then copy the .nupkg file to a shared location - the file system on a centralised server is fine if you have access to one, and then setup access to this "feed" (ie, the shared folder) in visual studio (tools --> options --> Package Manager --> Package Sources), thus:
Or if you want to host the packages over http you can follow the instructions here: https://github.com/NuGet/NuGetGallery/blob/master/README.markdown.
Other option would be to use Nuget.exe spec, pack commands to quickly create package.
More details here # http://docs.nuget.org/docs/reference/command-line-reference
I can upload RuleFlow (.rf) files to Guvnor (both 5.1 M1 and 5.0) and execute them with rules on the server. If I want to use Guvnor as a repository, is there any way I can download the RuleFlow files into my project on the fly?
On the package level, Guvnor provides some "Information and Important URLs" which only talk about rules. I was wondering if there is any other URL which will give me the RuleFlow files? Is WebDav my only other option?
If you add your ruleflow files to Guvnor, they will be part of the compiled package that is created when building your package. When you use the knowledge agent to build a knowledge base from Guvnor, it will include the ruleflows as well, so you can execute these in your project.
If you really do need the .rf file - you can use the link that the Download link/button provides (it requires an authenticated session though). Otherwise webdav can provide a URL to the file, as you guessed.