views:

928

answers:

3

Is it possible to deploy a native Delphi application with ClickOnce without a stub C# exe that would be used to launch the Delphi application?

The same question applies to VB6, C++ and other native Windows applications.

+1  A: 

I'm not 100% sure if this can be accomplished without the stub, but this article may provide some insight:

How To: ClickOnce deployment for unmanaged app with COM component in managed assembly

DaveK
It seems specific to an environment where you can point your manifest towards a COM component which is a managed assembly. A 100% unmanaged solution would not provide this little hack any room to work.
Warren P
+3  A: 

No, the entry point to your app needs to be managed code.

This is from a blog post by Brian Noyes, one of the main authorites on ClickOnce and author of Smart Client Deployment with ClickOnce.

If you app is REALLY legacy (i.e. VB6, MFC, ATL, etc.), as in an unmanaged code executable, then no, you cannot deploy it as an executable through ClickOnce.

The accepted workaround seems to be a managed code stub exe that launches the main exe.

whatknott
+2  A: 

Personally, I build my own mechanism to kick off self update process when my application timestamp is out of sync with the server. Not too difficult, but it's not a simple task.

By the way, for Delphi you can use some thirdparty help:

http://www.tmssoftware.com/site/wupdate.asp

UPDATED:

For my implementation:

MyApp.EXE will run in 3 different modes

  1. MyApp.EXE without any argument. This will start the application typically.

    1.1 The very first thing it does is to validate it's own file-time with the server.

    1.2 If update is required then it will download the updated file to the file "MyApp-YYYY-MM-DD-HH-MM-SS.exe"

    1.3 Then it invoke "MyApp-YYYY-MM-DD-HH-MM-SS.exe" with command argument

    MyApp-YYYY-MM-DD-HH-MM-SS.exe  --update MyApp.EXE
    

    1.4 Terminate this application.

    1.5 If there is not update required then the application will start normally from 1.1

  2. MyApp.EXE --update "FILENAME".

    2.1 Try copying itself to "FILENAME" every 500ms until success.

    2.2 Invoke "FILENAME" when it success

    2.3 Invoke "FILNAME --delete MyApp-YYYY-MM-DD-HH-MM-SS.exe" to delete itself.

    2.4 Terminate

  3. MyApp.EXE --delete "FILENAME"

    3.1 Try deleting the file "FILENAME" every 500ms until success.

    3.2 Terminate

I've already been using this scheme for my application for 7 years and it works well. It could be quite painful to debug when things goes wrong since the steps involve many processes. I suggest you make a lot of trace logging to allow simpler trouble-shooting.

Good Luck

Sake
That is exactly what I ended up doing.
Branko
I won't mind some upvote then ;)
Sake