Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
How to use QR barcodes in an easy way 3
- Thread starter wibenji
- Start date
Olaf Doschke
Programmer
Please, let me just relativize this rant, it's usually addressing a grown situation no single person is responsible for. I removed some parts of the previous post reflecting a bit of bitter experiences, no need to do that here.
And there are still other downsides of the xcopy deployment process, so there is valid criticism, sure, Idially you deploy software the way it's intended. But just a central share is even less ideal. Copying to local, the usual start process becomes giving the users a shortcut to a batchfile making that xcopy/robocopy followed by starting the local exe that may just have been updated, One disadvantage was introduced when Vista allowed to pin an application currently running on the task bar Or in a tile of the start menu in Win8. User do that and (technically) get a shortcut directly to the local EXE, which after that moment now does not update. And I had my pain and learned that the hard way, too.
To overcome that an EXE needs a start code checking it's own version is current. Then starting the EXE directly does not circumvent the update process.
But centralized executable used by many users often mean strange network errors no one can explain, coming from concurrent access the the EXE itself, which VFP never anticipated to be used by multiple users. Concurrent use of the foxuser.dbf intended for use by the one FoxPro user of that executable, and more.
And then you hear them say: "But it works for years". I wonder if they also tell that about their 15 year old car...
OK, so lets reverse this from a rant to constructive advice. Becasue I do think a lot of you already, having managed to follow the steps to create that helper assembly you already proved yourself as "none of them".
You find such deployment scripts here in the FAQ, for example: faq184-4492
That's already more than just an cmd batch file with an xcopy.
I do find robocoy very useful, still:
This combines the idea of a local apps folder with the idea to let there be no executable file on the share. In this case the EXE file extension is renamed to .EX_ and thus can't be started. The robocopy copies only changed files, so while it runs the EXE has to be named .EX_. After it finishes just rename the local .EX_ to EXE To be able to run it.
But to take the idea to make a version check as start code, I just point out one VFP function: AGETFILEVERSION(). You could compare just a version.txt file that's local to a server share file, but you can do a check that better prevents any cheating when you actually check the version number embedded in your EXE with AGETFILEVERSION(), as this embedded version numbering isn't as easy to manipulate than just a text file.
The concern that this causes a lot of network traffic is not true, the mirror mode means robocopy touches every file, yes, but mainly just its meta data, file size, date, name, to put together a list of files to actually copy. Time to find out nothing changed between central network share and local copy is split seconds, so you get an immediate start.
And then you have all the advantages a local installation has: The only further network load is data access to dbfs, network instabilities won't necessarily affect the local EXE, if you incorporate some behavior how, for example, a POS system stores its receipts local and only commits them at the end of the day, etc. Depends on your needs, of course. Many systems need active central share and won't be of much use in an offline situation, but you're stabilizing that, too.
Bye, Olaf.
Olaf Doschke Software Engineering
And there are still other downsides of the xcopy deployment process, so there is valid criticism, sure, Idially you deploy software the way it's intended. But just a central share is even less ideal. Copying to local, the usual start process becomes giving the users a shortcut to a batchfile making that xcopy/robocopy followed by starting the local exe that may just have been updated, One disadvantage was introduced when Vista allowed to pin an application currently running on the task bar Or in a tile of the start menu in Win8. User do that and (technically) get a shortcut directly to the local EXE, which after that moment now does not update. And I had my pain and learned that the hard way, too.
To overcome that an EXE needs a start code checking it's own version is current. Then starting the EXE directly does not circumvent the update process.
But centralized executable used by many users often mean strange network errors no one can explain, coming from concurrent access the the EXE itself, which VFP never anticipated to be used by multiple users. Concurrent use of the foxuser.dbf intended for use by the one FoxPro user of that executable, and more.
And then you hear them say: "But it works for years". I wonder if they also tell that about their 15 year old car...
OK, so lets reverse this from a rant to constructive advice. Becasue I do think a lot of you already, having managed to follow the steps to create that helper assembly you already proved yourself as "none of them".
You find such deployment scripts here in the FAQ, for example: faq184-4492
That's already more than just an cmd batch file with an xcopy.
I do find robocoy very useful, still:
Code:
c:
cd apps\myapp
IF EXIST myapp.exe ren myapp.exe myapp.ex_
robocopy /MIR \\share\apps\myapp\ c:\apps\myapp
IF EXIST myapp.ex_ ren myapp.ex_ myapp.exe
start /b myapp.exeThis combines the idea of a local apps folder with the idea to let there be no executable file on the share. In this case the EXE file extension is renamed to .EX_ and thus can't be started. The robocopy copies only changed files, so while it runs the EXE has to be named .EX_. After it finishes just rename the local .EX_ to EXE To be able to run it.
But to take the idea to make a version check as start code, I just point out one VFP function: AGETFILEVERSION(). You could compare just a version.txt file that's local to a server share file, but you can do a check that better prevents any cheating when you actually check the version number embedded in your EXE with AGETFILEVERSION(), as this embedded version numbering isn't as easy to manipulate than just a text file.
The concern that this causes a lot of network traffic is not true, the mirror mode means robocopy touches every file, yes, but mainly just its meta data, file size, date, name, to put together a list of files to actually copy. Time to find out nothing changed between central network share and local copy is split seconds, so you get an immediate start.
And then you have all the advantages a local installation has: The only further network load is data access to dbfs, network instabilities won't necessarily affect the local EXE, if you incorporate some behavior how, for example, a POS system stores its receipts local and only commits them at the end of the day, etc. Depends on your needs, of course. Many systems need active central share and won't be of much use in an offline situation, but you're stabilizing that, too.
Bye, Olaf.
Olaf Doschke Software Engineering
- Thread starter
- #42
I´m not sure if this is still directed to me, or just an info for everyone.
I just want to let you know that we are doing something similar. The problem with the dll on an network share was just me messing around in our development environment.
Benjamin Trinkaus
I just want to let you know that we are doing something similar. The problem with the dll on an network share was just me messing around in our development environment.
Benjamin Trinkaus
Olaf Doschke
Programmer
It's okay, I also wouldn't have anticipated that cause for the error.
Just another habit of me to rather test something new completely locally.
Bye, Olaf.
Olaf Doschke Software Engineering
Just another habit of me to rather test something new completely locally.
Bye, Olaf.
Olaf Doschke Software Engineering
Olaf Doschke
Programmer
Try this (zip attached to this post)
I put a PJX together with my state of VFPQRCoder.dll and the wwdotnetbridge files as necessary.
I arranged the files as I arrange them in project subfolders.
The project home folder has the PJX, the built EXE and the files you need to redistribute, ie the DLLs of the assemblies and wwdotnetbridge plus XML (I may be wrong about the XML file, but at least it works that way)^. I managed to keep Rick Strahl's code as is, there's no tweaking to let his DECLARE's find DLLs, etc. He has another strategy than I have for specifying file locations, working with many preprocessor directives also differentiating about using the free bridge version or an extended version in the case west wind connect is used. I solve the file finding with SET PATH in main.prg. In general, I often use a project hook to compile a list of locations for SET CLASSLIB, SET PROCEDURE and SET PATH to some sensible paths. I'm no fan of putting everything in one project folder. I can follow the logic of people who do, that the project managers tabs are there to organize the files, you don't need a file explorer to do so. But you know, different people, different OCD. Well, and as long as I only resort files Rickj Strahl intended to be in one folder, that's okay to me. The strongest reason I do so is I don't want DLLs in subfolders. And then I don't want more than necessary files in project home to easily finally pick the files for setup creation. And I want to be able to debug at design time.
The project self adjusts to any place you put it, of course aside of the question coming up when you first open the PJX whether you want to make the current directory the home directory. Of course, yes.
But I mean you just CD into the PJX home folder when you would change something (as include file relative paths depend on that), otherwise, just start the main.prg or the EXE and it'll create some test QR PNG files in the Output directory, no matter what the root directory is. I'd be interested to know whether that really doesn't work when put on a network share. If that's true it should run on any local drive. If it has dependencies to .NET not installed on your system we'll also see. That'd be good to know.
Bye, Olaf.
Olaf Doschke Software Engineering
I put a PJX together with my state of VFPQRCoder.dll and the wwdotnetbridge files as necessary.
I arranged the files as I arrange them in project subfolders.
The project home folder has the PJX, the built EXE and the files you need to redistribute, ie the DLLs of the assemblies and wwdotnetbridge plus XML (I may be wrong about the XML file, but at least it works that way)^. I managed to keep Rick Strahl's code as is, there's no tweaking to let his DECLARE's find DLLs, etc. He has another strategy than I have for specifying file locations, working with many preprocessor directives also differentiating about using the free bridge version or an extended version in the case west wind connect is used. I solve the file finding with SET PATH in main.prg. In general, I often use a project hook to compile a list of locations for SET CLASSLIB, SET PROCEDURE and SET PATH to some sensible paths. I'm no fan of putting everything in one project folder. I can follow the logic of people who do, that the project managers tabs are there to organize the files, you don't need a file explorer to do so. But you know, different people, different OCD. Well, and as long as I only resort files Rickj Strahl intended to be in one folder, that's okay to me. The strongest reason I do so is I don't want DLLs in subfolders. And then I don't want more than necessary files in project home to easily finally pick the files for setup creation. And I want to be able to debug at design time.
The project self adjusts to any place you put it, of course aside of the question coming up when you first open the PJX whether you want to make the current directory the home directory. Of course, yes.
But I mean you just CD into the PJX home folder when you would change something (as include file relative paths depend on that), otherwise, just start the main.prg or the EXE and it'll create some test QR PNG files in the Output directory, no matter what the root directory is. I'd be interested to know whether that really doesn't work when put on a network share. If that's true it should run on any local drive. If it has dependencies to .NET not installed on your system we'll also see. That'd be good to know.
Bye, Olaf.
Olaf Doschke Software Engineering
- Thread starter
- #45
When i start the .exe from my local drive everything works fine. When i put the folder on our network share i get the "Unable to load Clr Instance"-error.
But when i put a file named "vfpqrcodertest.exe.config" with
into the same folder it works without the error.
Edit1: (just double clicking the .exe file in each case)
But when i put a file named "vfpqrcodertest.exe.config" with
XML:
<configuration>
<runtime>
<loadFromRemoteSources enabled="true"/>
</runtime>
</configuration>Edit1: (just double clicking the .exe file in each case)
Olaf Doschke
Programmer
Ah, that's nice to know.
Some .NET runtime detail knowledge acquired...
Thanks, Benjamin.
Didin't you had another blocking problem? Or "just" the wish to use all this via COM instancing and ensuring it works in several client configurations of .NET version availability?
There once was a ClickOnce article to make that the way to handle prerequisites and even have a way to installing without requiring admin permissions. I actually doubt this holds water in the case of a missing .NET 4 Framework version, but perhaps in the usual case. I know it adds "apps" to the c:\users\username\AppData\Local\Apps\2.0
And IIRC such apps then run in lower than usual permissions. But that whole concept seems not to be popular, I only have one subfolder structure and that's empty.
Olaf Doschke Software Engineering
Some .NET runtime detail knowledge acquired...
Thanks, Benjamin.
Didin't you had another blocking problem? Or "just" the wish to use all this via COM instancing and ensuring it works in several client configurations of .NET version availability?
There once was a ClickOnce article to make that the way to handle prerequisites and even have a way to installing without requiring admin permissions. I actually doubt this holds water in the case of a missing .NET 4 Framework version, but perhaps in the usual case. I know it adds "apps" to the c:\users\username\AppData\Local\Apps\2.0
And IIRC such apps then run in lower than usual permissions. But that whole concept seems not to be popular, I only have one subfolder structure and that's empty.
Olaf Doschke Software Engineering
- Thread starter
- #47
Olaf Doschke
Programmer
OK, one thing is COM doing the instancing and thus loading the CLR, the other is the CLR is still necessary. But as I experimented the dependency is not that strict. It's more about what you use from the framework, and there is very little system assembly usage. System.Drawing, obviously and then a bit Text encodings. Well, and what QRCoder.dll uses (mainly also System.Drawing).
One thing might be worth investigating: How you could tweak QRCoder to work in itself without helper assembly. And then with or without the bridge.
I obviously picked the other route, also because I like to keep thrid party projects untouched only using them as is to be able to update without the need to apply the same tweaks again. I just tried to see what could make it work with the bridge directly. Instancing worked, but the bridge couldn't invoke a method.
Just another hint from a recent question on the inverse situation, trying to use a VFP DLL from Node.js I came across the problem a win32ole module was only working in very old node versions and in itself never was being versioned 1.0, so the originator has abandoned that module. Well, one should perhaps first say that VFPs interop possibilities with DLLs or EXE are only COM interop, you can only crate COM Server DLLs and EXEs, no DLLExport of functions. And then there is the 32bit hurdle...
I got a COM Server in a VFP EXE to work in Node.js with the winax module. That brings back Jsvascripts' ActiveXObject() and to many, that'll cause discomfort. I got no reaction from who asked, so maybe they figured it's not worth it and went another route through ODBC, for example, as it was about DBF data access. Maybe also moved data over to something node can easily address.
So modern platforms don't care for ActiveX/OLE/COM/ADO anymore. MS hs focused on ODBC vs OLEDB providers, too. So the only active use of it I see is with legacy VB6, VFP, and Office VBA, perhaps. And even more exotic languages.
Bye, Olaf.
Olaf Doschke Software Engineering
One thing might be worth investigating: How you could tweak QRCoder to work in itself without helper assembly. And then with or without the bridge.
I obviously picked the other route, also because I like to keep thrid party projects untouched only using them as is to be able to update without the need to apply the same tweaks again. I just tried to see what could make it work with the bridge directly. Instancing worked, but the bridge couldn't invoke a method.
Just another hint from a recent question on the inverse situation, trying to use a VFP DLL from Node.js I came across the problem a win32ole module was only working in very old node versions and in itself never was being versioned 1.0, so the originator has abandoned that module. Well, one should perhaps first say that VFPs interop possibilities with DLLs or EXE are only COM interop, you can only crate COM Server DLLs and EXEs, no DLLExport of functions. And then there is the 32bit hurdle...
I got a COM Server in a VFP EXE to work in Node.js with the winax module. That brings back Jsvascripts' ActiveXObject() and to many, that'll cause discomfort. I got no reaction from who asked, so maybe they figured it's not worth it and went another route through ODBC, for example, as it was about DBF data access. Maybe also moved data over to something node can easily address.
So modern platforms don't care for ActiveX/OLE/COM/ADO anymore. MS hs focused on ODBC vs OLEDB providers, too. So the only active use of it I see is with legacy VB6, VFP, and Office VBA, perhaps. And even more exotic languages.
Bye, Olaf.
Olaf Doschke Software Engineering
- Status
Similar threads
- Question
