I only want to do a ‘simple’ desktop deploy. I have tried going to Apps and doing a quick deploy, but get this message:
Deploying using ‘Copy’
No Selected Database files to copy.
No Selected App files to copy.
No Selected Library files to copy.
No Selected Page Library files to copy.
No Selected Extension Library files to copy.
No Selected MetaTypes to copy.
No Selected Modules to copy.
Follow the steps/screenshots here.
In the Deploy Workspace:
1. Click the checkbox next to the database, Apps and library files you want to deploy.
2. Click the ‘Preview changes‘ toolbutton in the headerbar.
3. Click the ‘Commit changes‘ toolbutton in the headerbar.
If you are using ‘Quick Deploy’, click the ‘Setup’ button – this takes you to the Deploy workspace – click the checkbox next to the database, Apps and library files you want to deploy then return to the Pages workspace and reopen the ‘Quick Deploy’ dialog and you can now ‘Preview’ and ‘Commit’ from the dialog as required.
Is it possible to build an app in Lianja that can run outside the app center?
For desktop clients, the Lianja App Center is required, but you can specify command line options to open an App or program directly and disable the App Center splash screen. See Command Line Switches in the Lianja wiki.
**** Warning **** Failed to copy table ‘homeloan\contact’ (possibly a linked table on a shared drive)
I get the warning above. This table was already deleted from the database in APP builder. I tried rebuilding the database and deploy again, still the above warning persisted.
Try restarting the App Builder, close your App (if open) then deploy directly from the Deploy workspace.
Is there an overview available for that Custom deploy option in Settings?
What I’m wondering is what kinds of information are passed to the custom app (if any)?
Related to that: is it called once, or multiple times?
‘Custom’ Publisher allows you to specify the ‘Path’ for the publisher command and the ‘Arguments’ to pass to that command.
In the App Settings, where this can also be defined (Deployment), it gives the following examples:
Publisher: The optional full path of the publisher program, e.g. /usr/bin/rsync.
Arguments: The optional arguments to the publisher program, e.g. -avc for rsync.
So looking at rsync parameters, it appears that the Custom app gets, in addition to whatever customer arguments one has, the local file path and the remote file path, which means one call per file.
Furthermore, it appears that the Custom app gets “run” as a system executable, which makes things a bit more complicated. A Custom Script option would be handy. As contrasted with running LianjaRuntime.exe for every file.
In the meantime I am using a small hosted server from 1and1.
What is the recommended way of deploying a cloudserver app to a hosted machine?
I can deploy locally, then copy Data, App and wwwroot\app files via ftp or dropbox.
If you have an SFTP server on your 1&1, that’s an option for deployment in Settings. Filezilla server, however does not have SFTP, so you would need a Custom publisher to do FTPS. Doing this with chilkat is very easy, so it could be a Lianja prg that you use as the custom publisher. I don’t know what Lianja expects, but since it works with rsync, I’m guessing the arguments passed will be in that order.
Also: for your FTP server on 1&1 (which I use also), you will be getting hammered by bad guys trying to get in. I ended up limited the source IP in Windows Advanced Firewall to keep the server from being hammered.
You would be calling the pathed Lianjaruntime.exe with the appropriate arguments.
Do I understand correctly that since there is no .exe capabilities that an app can’t be packaged to self install? And that is more like, I can sell an app that can be run EITHER on desktop or online…and that the desktop is really a shortcut to an online app?
Also, if I create an app with a database of items(proprietary per user),does the database reside on each individual’s desktop or pc?
My app is an estimating app that needs a database of items, each item having attributes such as material price, labor price, etc. But each client that I sell to needs his or her own database of items that they may add to or delete or edit…not affecting any other client’s database.
In short, yes – you can build and sell applications to various clients that are not online. The databases will be installed on the clients local network.
You can think of Lianja in the same context of a pure python application. You create a .py file for python. It’s not technically an executable, but the python execution behind it runs as an executable or service.
Very similar to Lianja. There is an executable/service behind the scenes. So the deploy is not an executable, but the code underneath the hood is.
When creating a desktop app, Lianja has a built-in “install builder” (which you have to configure, although a default template is provided). This is what you use to install the “desktop only” app on a user’s machine.
The days of desktop-only apps is, however, over. What Lianja gives you is a way to create the same app in a desktop version (running Electron) and also running on web/mobile. These apps all hit against the Lianja Cloud Server.
One of the things I’ve been looking at recently is the need to be able to handle Continuous Integration of databases when Apps are running live in the cloud.
There was a need to be able to lock and unlock named resources (shared and exclusive) as requests come into the cloud server.
To achieve this I have implemented several new functions in Lianja 3.4.
where mode can be “shared” or “exclusive”.
The Cloud Server locks a resource called “LianjaCloudServerRequestLoop” for “shared” access (many concurrent readers) while a request is being processed.
This provides everything we need to be able to provide Continuous Integration of our Apps and data without needing to bring the server down.
As I progress with Lianja 4.0 and the Lianja Hosted Cloud the ability to compare database schemas and also package up apps and upgrade them in place on the server is now possible.
For those of you “rolling your own”, you can write a .rsp page to perform live updates. For example if your page was called upgrader.rsp inside it…
unlockResource("LianjaCloudServerRequestLoop") lockResource("LianjaCloudServerRequestLoop", "exclusive") // when the resource access is granted execution continues. // // perform your upgrade procedure possibly processing an upgrade script that you POSTed // unlockResource("LianjaCloudServerRequestLoop")
It is worth mentioning that these functions are cluster-safe meaning that they can operate across multiple containers and/or VMs.
You can declare your own resource names that are specific to your own requirements.
The resourcelocks are not shared between development and runtime. They are specific to each. So if you are testing this from the app builder it won’t have any effect.
Resource names can be anything you want them to be. You use lockResource() in your own applications to gain shared/exclusive access to critical blocks of code or operations.
Think of them as cluster-safe mutex/semaphores that are shared across all instances that access the same data.
// this will block until no more “shared” or “exclusive” locks on the resource “HanksSpecialResource”
// do whatever you want now you have exclusive access to “HanksSpecialResource”
and in another process B:
.. if process A has exclusive access you will be blocked until it unlocks
I intend to do development on a PC, and upon finish testing, deploy the APP(s) to the actual web server. Is there a quick way to do so if both machines had Lianja installed??
Use the deploy workspace.
If you setup a project and add all the apps and databases that you use to the project, when you select the “Deploy” workspace all files in the project will be selected for copying to the remote server.
You can use sftp or a network drive.
In Lianja 4.0 you will be able to create a lianja .lpk (Lianja package) and deploy that to the “deploy” folder in the cloud server. The cloud server can (optionally) unzip the .lpk file updating only the files that have changed. It will also detect database schema changes and alter the tables to match the new table structures. This can be done on a “live” system without any need for down time. This is all part of the Lianja CI (Continuous Integration) pipeline which is coming as part of Lianja Hosted Cloud).
In the current shipping version you do not have this functionality so using sftp from the “Deploy” workspace is the best solution.