Sorry if this ones been visited before, but I just built my first Windows app in 16r4.1 choosing to include the Windows runtime DLLs. After the build completes, the DLLs are all located next to the EXE file instead of in the Libs filder.
Is this correct?
Yes
Just felt odd - Thanks.
Yep, that’s where they should be. Previously, you had to place those there yourself I believe, now with R4 you can have it done for you.
45046 IDE » Miscellaneous The Windows build settings include an option to copy the Windows Universal C runtime redistributable DLLs next to the built Windows exe. When you enable this a warning dialog is shown to explain why Microsoft does not recommend this distribution technique.
I understand that - I was just curious about then being at the same level as the app instead of in the app’s Libs folder.
sigh Microsoft.
One packaging technique I use for a client (they insist on having the libs for their win7 users) is that I put the whole output of Xojo (.exe, libs, rsrc, winruntime) inside a subfolder, and make a relative shortcut to the .exe
This works reasonably well, and the relative shortcut (.lnk) doesn’t have any issues with being stored on my Mac and put in place with a build script.
Now - if we could just get a static compile for Linux builds with a similar “warning” … Lots and Lots of compatibility issues would be resolved without putting the users through the great linux lib scavenger hunt!
File a feature request
Third style of installation on Windows though…
Makes installing a new version of an app on top of a previous one a bit of a mess.?
Myapp
\Libs
and
MyApp
\MyApp Libs
And now
MyApp
\loads of stuff
There’s only 2 real choices with the Windows C Runtime DLL’s
Neither of which is our doing
You can choose from “next to the exe” or “installed in one of the system locations”
Next to the exe is simple BUT will never get any security updates etc
Properly installed they will and no other software ever needs to install them
Thank MS for this
You mean the one that is “Closed Won’t Implement” ?
Dont think anything has changed in the assessment to make us reopen it
But - in much the same way that you go against Microsoft’s guidance and allow us to place the runtime in the “bundle”, you could do the same thing in Linux. You would then CYA by warning the user that creating a static binary may make their app incompatible with the GPL and let US choose whether we give two shakes about that. Plus, if we compile static, the issue of updating libraries is a serious non-issue since our statically compiled library elements can’t as easily be plundered (if at all). Finally, the only real documented restriction is that if a developer provides a statically compiled binary, as long as they also offer a shared compiled version of that app so that Purists can wave their victory flags, we’re ALL covered.
My line on that is if we can do it with GCC on a stock Linux system, the precedent is already set and the EFF has no standing.
As Arthur C Clark penned - TNSTAAFL - and that applies to Linux as well.
Its not just a GPL vs not GPL issue
Static linking isn’t happening and isn’t on any to do list
[quote=302966:@Norman Palardy]
Dont think anything has changed in the assessment to make us reopen it[/quote]
Well, one more attempt shot down in trying to make Linux a more acceptible target for Xojo users … to the others I’d spoken with off the forum - I tried.
Static linking isnt JUST a Linux issue
We dont statically link on ANY platform
FWIW : That report was closed in 2015
But could it be possible to put the libs next to the app like on Windows?
Maybe that makes Tim more happy.