Windows Deployment Requirements

paul3252

As far as I can tell after looking through website and help I have not been able to find the deployment requirements for an OBJO application. I have built a very simple ODBC, database SQL query builder as a test for OBJO. When built, I get 3 files, app.json, app.objoc and application.exe.

Clicking on the executable runs it on my local machine standalone.

If I take the folder to a 'work based computer' the application never launches and fails silently so I am guessing there are some dependencies missing on the target host machine. Any ideas as to what they may be?

If I take a similar XOJO application and put the whole containing folder including resources, libs etc. on the same host machine the application runs fine.

Do I need to include additional files for the executable, or does the application have to be 'published'?

bgrommes

So long as you are deploying everything in that folder it's supposed to be self-contained with no external dependencies. The EXE includes the .NET runtime, for example -- and Avalonia if it's not a command line app. app.objoc is the compiled bytecode for your app.

The only thing I can think of offhand if it's failing to run on a machine other than the one you built it on is that it isn't signed, which, yes, would require a full Publish and presumably the installer would take care of properly registering it with the OS of the target machine. But I'd expect you to just get a warning message and be able to override and run it anyway.

I haven't personally tried to build on one Windows machine and then run on another; I can probably give that a whirl later today.

Beyond that, Garry will have to provide a definitive answer or better suggestions for trouble shooting.

madamov

bgrommes Beyond that, Garry will have to provide a definitive answer or better suggestions for trouble shooting.

Windows versions and/or computer configurations might help, too. I've spent almost eight years as international tech support team member with 4D SAS, almost half of the tickets would be handled witihin half of the time used if that information was provided upfront.

paul3252

I have no control over the target machine, Windows 11, latest version, and home computer Windows 11, latest version. As I can deploy a XOJO package which in effect runs in a standalone folder, I cannot achieve the same with OBJO. The next time I am at work I will take a look at the windows error logs and see if they contain anything helpful.

madamov

paul3252 Are you deploying command-line application? If yes, how do you run application.exe? If you are opening it from GUI, did you try to open Command prompt or PowerShell, change directory and run application.exe from there?

paul3252

Its a straightforward windows desktop app consisting of one window. Just double clicking the executable to launch, or not launch in this case.

PaulS

paul3252 When built, I get 3 files, app.json, app.objoc and application.exe.

Did you Build or Publish?
See the explanation of @Garry in this thread.

Important distinction
Build: local testing output. Now ad-hoc signed on macOS. No Apple Developer account needed.
Publish: distribution output. This is still the path for Developer ID signing, notarisation, stapling, DMG creation, and sharing with other Mac users.

When I read this I think Build is only for local testing and not supposed to be used for testing on another computer.

bgrommes

PaulS Well ... the portable zip distro of Objo Studio is properly signed but without the installer to fully register it, Windows declines to run it the first time but gives you an opportunity to override. Or Windows Server does anyway. Based on that I (maybe naively) expected similar behavior when running a copied exe, but the difference is that no effort has been made to sign it at all if it is built but not published. However it's odd that it silently fails to run. You'd think there'd be some kind of error message, even an obtuse or unhelpful one ...

Garry

@paul3252, you’re right to expect a Windows application to run when its complete folder is copied to another Windows 11 PC. I’m sorry. I haven’t made the deployment requirements clear enough, and a silent failure is not acceptable.

A couple of important clarifications:

Build produces local-testing output. For another computer, please use Publish → Portable ZIP or Publish → Unpackaged application folder, then extract the complete output before running it.
The published app includes Objo and .NET, so neither Objo Studio nor a separate .NET runtime should be required.
However, our Windows desktop stack currently requires the Microsoft Visual C++ 2015–2022 Redistributable. A locked-down work PC may not have that installed, and the process can fail before Objo gets an opportunity to display a useful error.
Because this application uses ODBC, the destination PC will also need the appropriate ODBC driver and any required DSN. That should normally affect the database connection rather than prevent the window from appearing, so I don’t want to assume it is the cause.

I also don’t think we should assume signing is the explanation without evidence.

I don’t want you spending your next visit to work doing diagnostic archaeology for us. I’m going to try reproduce this with a published desktop app on a clean Windows 11 installation and determine exactly what is missing. I’ll also investigate whether the portable output can carry the required native runtime locally, which would be much more useful on computers where you cannot install prerequisites.

If you can tell me which Objo Studio version you used, that would help me test the exact path. If the small test project is shareable, you’re also welcome to send it to me privately but I’ll begin with a clean test application either way and report back here.

Garry

@paul3252 , I’ve now tested this using the exact Windows host shipped with the current public release.

I compiled a desktop application on macOS, transferred its output to a separate Windows 11 computer, and launched it there successfully. I also confirmed that application.exe is already validly signed by Pettet Industries.

So your expectation was correct: copying the complete Build folder to another Windows computer should work for testing. Publish is not required merely to make it launch, and signing is not the explanation here. I’m sorry that the earlier replies sent you in those directions.

The most useful clue is that this application uses ODBC. If an ODBC connection fails during App.Opening or Window.Opening, an uncaught runtime error can terminate the app before its window appears. Because this is a Windows GUI executable, double-clicking it hides the diagnostic output and makes the failure look completely silent.

When you are next at the work computer, there is no need to start with Event Viewer. Open PowerShell in the application folder and run:

$p = Start-Process .\application.exe `
    -RedirectStandardError .\objo-error.txt `
    -PassThru -Wait

$p.ExitCode
Get-Content .\objo-error.txt

If the app fails immediately, objo-error.txt should contain the actual Objo or ODBC error. Please post that text here or send it to me privately if it contains sensitive connection details.

If your application attempts to connect to the database during startup, please mention that too. A missing or differently named 64-bit ODBC driver or DSN on the work computer is now the leading possibility.

You should not have had to reverse-engineer this, and I’ll also improve the way built desktop applications report startup failures.

paul3252

Garry back in tomorrow so will give it a try BUT I think you may have highlighted the problem. Only the Access 32 bit ODBC drivers are installed and this is why i have to build my main XOJO desktop application in 32 bit. In the dim and distant past I recall this being an issue for the original 64 bit build and had to revert to 32 bit as the IT department would not install 64 bit drivers for some strange reason, just to be awkward I think LOL towards us 'enthusiastic amateurs' 😀.

I'll also build a simple 64 bit app no ODBC today and try this in the morning and that will likely confirm tomorrow.

paul3252

I can report that all other apps. run fine and it appears ODBC related, there are no 64 bit drivers on the system , just 32 bit. Pasting the commands into powershell to produce an error.txt file produces,

<unknown>: DatabaseException: ERROR [IM002] [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified.

Garry

Thanks for the diagnostics. They confirmed two separate issues.

The deployed application itself is working correctly. The database error occurs because the Objo application is 64-bit, while the destination machine only has a 32-bit Access ODBC driver or DSN. Objo’s current Windows targets are x64 and ARM64; there is no x86 target. A matching 64-bit ODBC driver must therefore be installed, and any required DSN must be configured using ODBC Data Sources (64-bit). A DSN-less connection string removes the named-DSN requirement but still needs a compatible 64-bit driver.

Separately, a desktop application silently closing on an unhandled error is not acceptable. I’ve implemented a fix for the next release: standalone desktop applications will show a copyable error window containing the exception and Objo call stack, including for errors that occur during startup before the first window appears. The same information will continue to be written to standard error for PowerShell and other diagnostic capture. Studio debugging and profiling will continue to report errors through Studio without displaying a duplicate dialog.

The ODBC and error-handling documentation will also be updated.

Thanks for testing the non-ODBC application and capturing the error - it isolated both the deployment question and the usability problem.

https://feedback.objo.dev/bug/1210

paul3252

Garry

Garry thanks Garry.