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 derfloh 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
You may be right Olaf, I might be the only user of the apps using this technique now!
In fact I'm pretty sure I am, and as I have the right privileges, I never see the elevation.
On the other hand, I do use ChilKat on some things, I'll have a look and see if it's registered...
Regards
Griff
Keep [Smile]ing
In fact I'm pretty sure I am, and as I have the right privileges, I never see the elevation.
On the other hand, I do use ChilKat on some things, I'll have a look and see if it's registered...
Regards
Griff
Keep [Smile]ing
There are 10 kinds of people in the world, those who understand binary and those who don't.
I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.
I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.
When the app first runs, if there is no ChilKat dll in the folder it's run from, the app extracts the dll as mentioned above and runs that code to register it
and it seems to work in Windows 10.
Can't say any more than that... ChilKat doesn't work unless registered - I don't think - and this is the only route to register it I have.
Not saying you are wrong Olaf, but that is the thing I see before me.
Regards
Griff
Keep [Smile]ing
and it seems to work in Windows 10.
Can't say any more than that... ChilKat doesn't work unless registered - I don't think - and this is the only route to register it I have.
Not saying you are wrong Olaf, but that is the thing I see before me.
Regards
Griff
Keep [Smile]ing
There are 10 kinds of people in the world, those who understand binary and those who don't.
I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.
I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.
Olaf Doschke
Programmer
OK,
I also won't question your experience. Maybe you have UAC off, there still are some reasons it could fail under some circumstances. I take it Chilkat doesn't work by just being in the same folder or System32/SysWow64.
It's not that hard to write a VFP COM-Server to check out registration woes to the core extent,I think all do it at some point and check influences of UAC, account type of users. It's astonishing you don't even see an elevation popup, but that would be the case with UAC turned off or to a lower level so it becomes sufficient you're an admin account. It also matters what group policies are set in an environment with Windows Enterprise. That's differences I couldn't currently test, too.
Bye, Olaf.
Olaf Doschke Software Engineering
I also won't question your experience. Maybe you have UAC off, there still are some reasons it could fail under some circumstances. I take it Chilkat doesn't work by just being in the same folder or System32/SysWow64.
It's not that hard to write a VFP COM-Server to check out registration woes to the core extent,I think all do it at some point and check influences of UAC, account type of users. It's astonishing you don't even see an elevation popup, but that would be the case with UAC turned off or to a lower level so it becomes sufficient you're an admin account. It also matters what group policies are set in an environment with Windows Enterprise. That's differences I couldn't currently test, too.
Bye, Olaf.
Olaf Doschke Software Engineering
UAC is strictly enforced, so it's not that, and the users are not ADMINs, although the very first ones, before ChilKat was employed, would have been (because they would have been doing an install).
Dunno.
Regards
Griff
Keep [Smile]ing
Dunno.
Regards
Griff
Keep [Smile]ing
There are 10 kinds of people in the world, those who understand binary and those who don't.
I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.
I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.
Olaf Doschke
Programmer
A setup is always a solution to put in such actions, as they only happen once, but not in a continuous update situation like you have in companies quite frequently.
The same company that required that was willing to assign once for everyone, VFP runtimes and other components including ActiveX a software package needs. GRoup policy is used to prevent and VFP exe to work at any location, though, so it's no free ride, too.
What differed with assemblies is that you don't register them with regsvr32 but regasm. I'm a bit unsure about the aspect of COM visibility, that's still an OLE COM Server thing and registering OLE classes is what regsvr32 is for. For me just another reason to work with regfree manifests and Rick Strahls bridge and avoid ActiveX. Beside the decline of this in OLEDB Providers and ActiveX usage in browsers.
When it comes to components with license the only way even the professional Dev OPS at a customers IT department saw was using the official installer of a component that registered it including license for usage.
Bye, Olaf.
Olaf Doschke Software Engineering
The same company that required that was willing to assign once for everyone, VFP runtimes and other components including ActiveX a software package needs. GRoup policy is used to prevent and VFP exe to work at any location, though, so it's no free ride, too.
What differed with assemblies is that you don't register them with regsvr32 but regasm. I'm a bit unsure about the aspect of COM visibility, that's still an OLE COM Server thing and registering OLE classes is what regsvr32 is for. For me just another reason to work with regfree manifests and Rick Strahls bridge and avoid ActiveX. Beside the decline of this in OLEDB Providers and ActiveX usage in browsers.
When it comes to components with license the only way even the professional Dev OPS at a customers IT department saw was using the official installer of a component that registered it including license for usage.
Bye, Olaf.
Olaf Doschke Software Engineering
I'm trying an experiment.
I have a server which has never had ChilKat on it, I'm popping a modified exe of the app I was talking about on it. Not installing, it already has the VFP runtimes.
I have changed it so it does not register ChilKat... back in a moment
** update **
Ran without registering ChilKat, did not work, said class definition not present.
Going to log in as ordinary user (was Admin) and see what happens, when I try to register the .dll
** update 2 **
Created new user with remote desktop access, connected, allowed code above to register ChilKat and I sent myself an email
via it. Just checking regedit for ChilKat entries...
** Update 3 **
The ChilKat entries are there in the registry - I can see them from Admin and the new user.
UAC is on, it's Server 2012R2. Go figure
** Update 4 **
The keys in the registry are user based, so without registering the .dll again as Admin, the class does not exist.
Regards
Griff
Keep [Smile]ing
I have a server which has never had ChilKat on it, I'm popping a modified exe of the app I was talking about on it. Not installing, it already has the VFP runtimes.
I have changed it so it does not register ChilKat... back in a moment
** update **
Ran without registering ChilKat, did not work, said class definition not present.
Going to log in as ordinary user (was Admin) and see what happens, when I try to register the .dll
** update 2 **
Created new user with remote desktop access, connected, allowed code above to register ChilKat and I sent myself an email
via it. Just checking regedit for ChilKat entries...
** Update 3 **
The ChilKat entries are there in the registry - I can see them from Admin and the new user.
UAC is on, it's Server 2012R2. Go figure
** Update 4 **
The keys in the registry are user based, so without registering the .dll again as Admin, the class does not exist.
Regards
Griff
Keep [Smile]ing
There are 10 kinds of people in the world, those who understand binary and those who don't.
I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.
I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.
Olaf Doschke
Programmer
Thanks Griff.
Okay, so a per user registering works. It would just be more comfortable to have one administrative registration for all.
I would have bet OLE does not look into user-specific branches of the registry for a class and it's location.
That makes some observations about the uselessness of virtualised keys I learned years ago wrong.
Regarding the .NET bridge one of it's advantages remains, it allows bridging to assemblies without any COM Interop and COM Visible methods and properties/fields.
But several other QR libraries and ActiveX controls also get into an easy enough to use spot. Even when not having the chance to update installations with a regular setup running elevated and only triggering the self registering API functions at first start of a user. The test would be simple, try to create an instance, when it fails selfregister, that should work.
Bye, Olaf.
Olaf Doschke Software Engineering
Okay, so a per user registering works. It would just be more comfortable to have one administrative registration for all.
I would have bet OLE does not look into user-specific branches of the registry for a class and it's location.
That makes some observations about the uselessness of virtualised keys I learned years ago wrong.
Regarding the .NET bridge one of it's advantages remains, it allows bridging to assemblies without any COM Interop and COM Visible methods and properties/fields.
But several other QR libraries and ActiveX controls also get into an easy enough to use spot. Even when not having the chance to update installations with a regular setup running elevated and only triggering the self registering API functions at first start of a user. The test would be simple, try to create an instance, when it fails selfregister, that should work.
Bye, Olaf.
Olaf Doschke Software Engineering
It does seem clumsy - but makes sense if you are thinking of a licenced product, where some users might not have paid for it and some have maybe?
If you are talking about an RDS installation where there could be fifty users with different privileges?
Getting back to the OP though, he could use the code from William GC Steinford in 2003 regardless of Admin rights.
Regards
Griff
Keep [Smile]ing
If you are talking about an RDS installation where there could be fifty users with different privileges?
Getting back to the OP though, he could use the code from William GC Steinford in 2003 regardless of Admin rights.
Regards
Griff
Keep [Smile]ing
There are 10 kinds of people in the world, those who understand binary and those who don't.
I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.
I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.
- Thread starter
- #29
I´m just in the process of trying this. I will report back when i´m done
Edit1: The working .dll i made with Olaf´s help is not registering with the regsvr function. It generates the following error:
Edit1: The working .dll i made with Olaf´s help is not registering with the regsvr function. It generates the following error:
Code:
ERROR: Library VFPQRCode has no entry point for DllRegisterServerOlaf Doschke
Programmer
No, it doesn't register, it's an assembly. I wrote I'm unsure whether COM-Visibility changes that, but the registration of assemblies is done with regasm, not regsvr.
Ánd I could have said earlier an assembly has no entry point DllRegisterServer, that's only part of "normal" COM Server DLLs. So that way of registration Griff shows only works for COM Server DLLs. And ActiveX DLLs from third parties will have that. The topic of self-registering won't work with assemblies. Griff's contribution only puts ActiveX alternatives in the spot of being an easy enough update extension.
My main point still is using the .NET bridge. The registration/self-registration process only helps with other actual ActiveX alternatives.
I thought I said everything you need to know about QRCoder and VFPQRCoder. Pick whether you want to avoid the bridge or not. You won't avoid this assembly to need and run in the .NET framework. I still prefer the bridge in that regard, as it's just changing your instancing a bit and the rest of the usage is the same.
Bye, Olaf.
Olaf Doschke Software Engineering
Ánd I could have said earlier an assembly has no entry point DllRegisterServer, that's only part of "normal" COM Server DLLs. So that way of registration Griff shows only works for COM Server DLLs. And ActiveX DLLs from third parties will have that. The topic of self-registering won't work with assemblies. Griff's contribution only puts ActiveX alternatives in the spot of being an easy enough update extension.
My main point still is using the .NET bridge. The registration/self-registration process only helps with other actual ActiveX alternatives.
I thought I said everything you need to know about QRCoder and VFPQRCoder. Pick whether you want to avoid the bridge or not. You won't avoid this assembly to need and run in the .NET framework. I still prefer the bridge in that regard, as it's just changing your instancing a bit and the rest of the usage is the same.
Bye, Olaf.
Olaf Doschke Software Engineering
- Thread starter
- #31
The point is that .NET bridge needs .NET Framework which still needs installation. I need a solution that´s fully working without admin rights. I´m not making that decision, i just need to find a way. I will keep trying to find a solution for me. A big thanks to everyone who tried to help me.
Olaf Doschke
Programmer
.NET 4.0 framework is present. And you can't avoid a .NET framework with a .NET solution, whether you use the bridge or not, that's not the constraint of the bridge.
.NET 4.90 really isn't a constraint.
Bye, Olaf.
Olaf Doschke Software Engineering
.NET 4.90 really isn't a constraint.
Bye, Olaf.
Olaf Doschke Software Engineering
- Thread starter
- #33
how do you know that? If that´s the case i could easily use the bridge.Olaf Doschke said:
Code:
DO wwDotnetBridge
loBridge = GetwwDotnetBridge()
? loBridge.GetDotnetVersion()Olaf Doschke
Programmer
I have Windows 10 and that also compares with new Server OSes, what are you using?
I also called the bridge differently. Shouldn't matter much, but you can call it to another version and QRCoder.dlls are also available for different versions and you can target your own helper assembly for the version already present.
OSes usually have 2 or 3 versions of the framework, it's not just one, so you have your range of possibilities.
The files you need to run the bridge are
wwDotNetBridge.dll
wwDotNetBridge.xml
wwDotnetBridge.PRG
ClrHost.dll
And then the assembliey
QRCoder.dll"
VFPQRCoder.dll
And then your own PRG
And target what is available to avoid the need of an installation. It would be something that only once needs to be done anyway.
4.0 is there in the most usual cases from XP up to Win10 and the same range of Windows Server versions, ie IIRC 2008-2016?
Bye, Olaf.
Olaf Doschke Software Engineering
I also called the bridge differently. Shouldn't matter much, but you can call it to another version and QRCoder.dlls are also available for different versions and you can target your own helper assembly for the version already present.
OSes usually have 2 or 3 versions of the framework, it's not just one, so you have your range of possibilities.
The files you need to run the bridge are
wwDotNetBridge.dll
wwDotNetBridge.xml
wwDotnetBridge.PRG
ClrHost.dll
And then the assembliey
QRCoder.dll"
VFPQRCoder.dll
And then your own PRG
And target what is available to avoid the need of an installation. It would be something that only once needs to be done anyway.
4.0 is there in the most usual cases from XP up to Win10 and the same range of Windows Server versions, ie IIRC 2008-2016?
Bye, Olaf.
Olaf Doschke Software Engineering
-
1
- #35
Olaf Doschke
Programmer
And here's a cut from the brodge PRG code
It shows that
1. Rick strahl has forseen specifying V2 or V4 in these shortcut versions.
2. You can specify other specific versions.
3. The bridge can also use COM, yes, specified in the second llUseCOM parameter
But what does that mean? You then leave it to the OS COM mechanism, which generally instance OLE classes to also invoke the corresponding runtime. It's still only there when it's there, it's still needing a runtime, nothing runs without a runtime.
Since you target your VFPQRCOder DLL to one or some .NET versions you know what you want. It might be possible to provide several DLLs, as they also come from the QRCoder solution in
...\QRCoder\bin\Release\netstandard2.0
...\QRCoder\bin\Release\net35
...\QRCoder\bin\Release\net40
...\QRCoder\bin\Release\netstandard1.1
When you pick your .NET target version you also pick what QRCoder.dll you'll reference.
Now I think it would get complicated to need to provide a bunch of DLLs to be able to use one of them. Even if COM instancing instead of the bridge loading a .NET version, you'll need to provide versions for the different versions and register them all with regasm. That doesn't make it really simpler. It may then support more customers with what they already have.
But when you reference QRCoder you pick a version already anyway. I picked .NET 4 for my project first and the reference to QRCoder.dll then is its packages\QRCoder.1.4.0\lib\net40\QRCoder.dll, so I am locked in one version the way I configured my project anyway. I could imagine you can also target more versions and have a bunch of outputs like the QRCoder solution. But I don't think that's necessary for the range of OSes supporting 4.0 assemblies is still current Windows and also reaches back to XP. And it contradicts the reason to use the bridge. That use com parameter is okay for system assemblies or the like, available in different versions on different target machines. But if you bring in a software, and then need to bring in several versions and register them with regasm, then you can use it via COM even without the bridge. That doesn't remove complexity.
All that said, I would double-check if the problem you have using the bridge is really your OS or a missing .NET 4.0 version and not just wrong path, missing files from the bridge zip, etc. "V4" is translated to "v4.0.30319" and also is the class definition line cClrVersion = "v4.0.30319". And that was also a reason I targeted .NET 4.0 too. But you are not limited to V2 and V4 parameters and "v4.0.30319" default, you can pass in any concrete version number, too, like a 4.5 version. It's just not a version QRCoder has in its outputs, so you'd have to add it there. Totally possible, I don't think 4.5 deprecates anything that needs special different handling. But I also opted for just using the given binaries from the Nuget source, as I struggled to get the QRCoder solution to compile in the first place, in VS 2017.
Bye, Olaf.
Olaf Doschke Software Engineering
Code:
FUNCTION Init(lcVersion, llUseCom)
IF !EMPTY(lcVersion)
LOCAL lcShortVer
lcShortVer = UPPER(lcVersion)
DO CASE
CASE lcShortVer == "V4"
lcVersion = "v4.0.30319"
CASE lcShortVer == "V2"
lcVersion = "v2.0.50727"
ENDCASE
this.cClrVersion = lcVersion
ENDIFIt shows that
1. Rick strahl has forseen specifying V2 or V4 in these shortcut versions.
2. You can specify other specific versions.
3. The bridge can also use COM, yes, specified in the second llUseCOM parameter
But what does that mean? You then leave it to the OS COM mechanism, which generally instance OLE classes to also invoke the corresponding runtime. It's still only there when it's there, it's still needing a runtime, nothing runs without a runtime.
Since you target your VFPQRCOder DLL to one or some .NET versions you know what you want. It might be possible to provide several DLLs, as they also come from the QRCoder solution in
...\QRCoder\bin\Release\netstandard2.0
...\QRCoder\bin\Release\net35
...\QRCoder\bin\Release\net40
...\QRCoder\bin\Release\netstandard1.1
When you pick your .NET target version you also pick what QRCoder.dll you'll reference.
Now I think it would get complicated to need to provide a bunch of DLLs to be able to use one of them. Even if COM instancing instead of the bridge loading a .NET version, you'll need to provide versions for the different versions and register them all with regasm. That doesn't make it really simpler. It may then support more customers with what they already have.
But when you reference QRCoder you pick a version already anyway. I picked .NET 4 for my project first and the reference to QRCoder.dll then is its packages\QRCoder.1.4.0\lib\net40\QRCoder.dll, so I am locked in one version the way I configured my project anyway. I could imagine you can also target more versions and have a bunch of outputs like the QRCoder solution. But I don't think that's necessary for the range of OSes supporting 4.0 assemblies is still current Windows and also reaches back to XP. And it contradicts the reason to use the bridge. That use com parameter is okay for system assemblies or the like, available in different versions on different target machines. But if you bring in a software, and then need to bring in several versions and register them with regasm, then you can use it via COM even without the bridge. That doesn't remove complexity.
All that said, I would double-check if the problem you have using the bridge is really your OS or a missing .NET 4.0 version and not just wrong path, missing files from the bridge zip, etc. "V4" is translated to "v4.0.30319" and also is the class definition line cClrVersion = "v4.0.30319". And that was also a reason I targeted .NET 4.0 too. But you are not limited to V2 and V4 parameters and "v4.0.30319" default, you can pass in any concrete version number, too, like a 4.5 version. It's just not a version QRCoder has in its outputs, so you'd have to add it there. Totally possible, I don't think 4.5 deprecates anything that needs special different handling. But I also opted for just using the given binaries from the Nuget source, as I struggled to get the QRCoder solution to compile in the first place, in VS 2017.
Bye, Olaf.
Olaf Doschke Software Engineering
- Thread starter
- #36
Ah the puzzle pieces are slowly making sense to me. I think i can work with that. I also solved the "Unable to load Clr Instance"-Problem by putting the vfp9.exe.config file into the right path. I will now work on making the helper assembly work with all our needs. Again thank you all very very much for your valuable input.
Benjamin Trinkaus
Benjamin Trinkaus
Olaf Doschke
Programmer
OK,
so I guess I was just more fortunate, but indeed the bridge and it's components never failed for me, even when I first used it on Vista, I think.
I thought you just need to target .NET4 in your helper assembly and then get it going. Maybe add a few files you missed from the bridge, maybe add the correct QrCoder.dll, etc. There's a lot of things that could be "off by one" here.
The idea of regasm differs from ActiveX/COM servers as you usually will stay in the .NET world with assembly usage and go about DLLs as always to avoid DLL hell of some globally registered DLLs, by adding it to the packages your software uses and not register them. That's only necessary - as far as I now dived into it - when you actually need that global visibility even from such languages as VFP without proxies such as Rick Strahl's bridge.
If you do a setup it's quite easy to install dependencies, too. Then anything needing administrative elevation for once is no problem, as setup is having that constraint anyway. OK, and then the bridge even becomes questionable in itself.
I have to cope with many different target systems of a customer distributing his software to multiple customers, too. But it's no problem to specify .net 4.0 as prerequisite then. It'd be something that the distributor would do or even their customers' IT departments. In short, they're having the deployment process under their hands, so I fortunately only explain some things and they figure out more details. Stll usually I aim for them to be able to just distribute a new EXE for updates, and maybe some accompanying files.
Bye, Olaf.
Olaf Doschke Software Engineering
so I guess I was just more fortunate, but indeed the bridge and it's components never failed for me, even when I first used it on Vista, I think.
I thought you just need to target .NET4 in your helper assembly and then get it going. Maybe add a few files you missed from the bridge, maybe add the correct QrCoder.dll, etc. There's a lot of things that could be "off by one" here.
The idea of regasm differs from ActiveX/COM servers as you usually will stay in the .NET world with assembly usage and go about DLLs as always to avoid DLL hell of some globally registered DLLs, by adding it to the packages your software uses and not register them. That's only necessary - as far as I now dived into it - when you actually need that global visibility even from such languages as VFP without proxies such as Rick Strahl's bridge.
If you do a setup it's quite easy to install dependencies, too. Then anything needing administrative elevation for once is no problem, as setup is having that constraint anyway. OK, and then the bridge even becomes questionable in itself.
I have to cope with many different target systems of a customer distributing his software to multiple customers, too. But it's no problem to specify .net 4.0 as prerequisite then. It'd be something that the distributor would do or even their customers' IT departments. In short, they're having the deployment process under their hands, so I fortunately only explain some things and they figure out more details. Stll usually I aim for them to be able to just distribute a new EXE for updates, and maybe some accompanying files.
Bye, Olaf.
Olaf Doschke Software Engineering
Olaf Doschke
Programmer
By the way, I made an experiment and changed the target framework version for my VFPQRCoder helper assembly to .NET 4.5 and it still works with the bridge loading the V4 framework.
I ensured the new version DLL is used and not some old DLL version hidden somewhere I don't know by changing the names a bit and I also extended parameters to be able to specify ECC-Level and PixelsperModule.
What's still not under control is the final image size, I think it's simply using a fixed QR pixel size. The most verbose parameterization of GetGraphics allow to set some icon border size, but for the moment that's a side point.
The main point is, it seems not so much important to use exactly the right .NET Framework version at runtime, as long as you stay within overlap of what you're really using. And it's not very much. A bit of Text and encoding (UTF8) and then System.Drawing (.NET GDI+, so to say).
So this is more flexible than I thought and I can't reproduce the problem you have using QRCoder.dll assembly via VFPQRCoder.dll helper assembly via the bridge. I left off COM visibility and didn't register anything.
I think that it works with wrong .NET framework, too, mainly is because I only use the original QRCoder.dll which still targets .NET 4 version. Plus System.Text.UTF8Encoding may not have changed since the beginning of .NET. All in all it's a bit similar to VFP, you can use the VFP9r.dll runtime to run an FXP compiled in VFP6, 7, or 8, too. Just an EXE embeds which runtime version it actually expects, an FXP will be run from some process, it's not an EXE, just ocject code. And VFP object code just like C# CLR code is opcodes interpreted by whatever runtime is active. The opcodes are backward compatible most of the time, even if a native function has one more parameter in VFP9, the main code for the function doesn't change, so the assemblies targeted for 4.5 also can run with various other runtime versions.
I'd not overstretch the flexibility of that, but I wonder how you get to an error at any stage of the process.
Bye, Olaf.
Olaf Doschke Software Engineering
I ensured the new version DLL is used and not some old DLL version hidden somewhere I don't know by changing the names a bit and I also extended parameters to be able to specify ECC-Level and PixelsperModule.
What's still not under control is the final image size, I think it's simply using a fixed QR pixel size. The most verbose parameterization of GetGraphics allow to set some icon border size, but for the moment that's a side point.
The main point is, it seems not so much important to use exactly the right .NET Framework version at runtime, as long as you stay within overlap of what you're really using. And it's not very much. A bit of Text and encoding (UTF8) and then System.Drawing (.NET GDI+, so to say).
So this is more flexible than I thought and I can't reproduce the problem you have using QRCoder.dll assembly via VFPQRCoder.dll helper assembly via the bridge. I left off COM visibility and didn't register anything.
I think that it works with wrong .NET framework, too, mainly is because I only use the original QRCoder.dll which still targets .NET 4 version. Plus System.Text.UTF8Encoding may not have changed since the beginning of .NET. All in all it's a bit similar to VFP, you can use the VFP9r.dll runtime to run an FXP compiled in VFP6, 7, or 8, too. Just an EXE embeds which runtime version it actually expects, an FXP will be run from some process, it's not an EXE, just ocject code. And VFP object code just like C# CLR code is opcodes interpreted by whatever runtime is active. The opcodes are backward compatible most of the time, even if a native function has one more parameter in VFP9, the main code for the function doesn't change, so the assemblies targeted for 4.5 also can run with various other runtime versions.
I'd not overstretch the flexibility of that, but I wonder how you get to an error at any stage of the process.
Bye, Olaf.
Olaf Doschke Software Engineering
- Thread starter
- #39
Hey Olaf the "Unable to load Clr Instance"- Error was because of the .dll being on a network drive. I fixed it with this
Olaf Doschke
Programmer
Okay, thanks.
Another thing I automatically not anticipate, as the usual recommendation always is to not run anything from a share directly. That's only causing troubles. CHM help wasn't working from a share, you can't simply replace a file in use by any of the N=? (in a case I maintained 100s) users, the major administrative advantage of a central share is sabotaged by users executing there.
I don't know, XCOPY deployment still involves to only use a share as a repository of the newest versions of files to copy from. But never to use it actively itself. OK, it seems even less modern to use some shell command than using the share itself. You know, there are better tools than XCYOP to copy just newest changed files: robocopy insync mirror mode. Yes, also just a shell command, but see - it'll even delete files locally, when you delete them from the share, so you gain full control about all user's local directories, not only about the newest file versions, about the full content of that local folder, it'll be a mirror of the server share. To me, that is modern enough.
You can't copy into the system protected c:\Program Files (x86) folder, is that an IT department concern? Well, you can whitelist allowed EXEs in a separate folder, you don't need to lower the security of Program Files(x86) in general, but also could just lower the security of the one company application folder. All possible via group policies. So a separate program folder or one application folder open for overwriting the main executable does not mean an entry point for malware or viruses freely roaming on client workstations as you can pinpoint what's allowed to run there.
Bye, Olaf.
Olaf Doschke Software Engineering
Another thing I automatically not anticipate, as the usual recommendation always is to not run anything from a share directly. That's only causing troubles. CHM help wasn't working from a share, you can't simply replace a file in use by any of the N=? (in a case I maintained 100s) users, the major administrative advantage of a central share is sabotaged by users executing there.
I don't know, XCOPY deployment still involves to only use a share as a repository of the newest versions of files to copy from. But never to use it actively itself. OK, it seems even less modern to use some shell command than using the share itself. You know, there are better tools than XCYOP to copy just newest changed files: robocopy in
You can't copy into the system protected c:\Program Files (x86) folder, is that an IT department concern? Well, you can whitelist allowed EXEs in a separate folder, you don't need to lower the security of Program Files(x86) in general, but also could just lower the security of the one company application folder. All possible via group policies. So a separate program folder or one application folder open for overwriting the main executable does not mean an entry point for malware or viruses freely roaming on client workstations as you can pinpoint what's allowed to run there.
Bye, Olaf.
Olaf Doschke Software Engineering
- Status
Similar threads
- Locked
- Question