Running from a Network Drive
Bengt Skogvall
Network drive?
If I try, I get a security exception, saying that mscorlib.dll was not
granted access.
I know, I can set the security level for LocalIntranet to FullTrust in
the .NET Configuration, but I want to be able to run inside the confines
of LocalIntranet.
Regards,
Bengt
Peter Below (TeamB)
> What do I have to do to be able to run a D8 Winform Application from a
> Network drive?
You have to install any of the Borland.* assemblies it needs into the GAC.
The problem is that the assemblies (especially the VCL for .NET assemblies)
use PInvoke to go to the API, and that is considered a security risk by MS
if done from a network drive...
--
Peter Below (TeamB)
Use the newsgroup archives :
http://www.mers.com/searchsite.html
http://www.tamaracka.com/search.htm
http://groups.google.com
http://www.prolix.be
Bengt Skogvall
Other than that I only use
System.Drawing,
System.Collections,
System.ComponentModel,
System.Windows.Forms,
System.IO
I do not see a dependency to use any borland.* assemblies, so I assume,
that classes got linked into the application.
The error I am getting is that I am not allowed to load mscorlib.dll.
That is referenced by System.Windows.Forms and others. Apparently
mscorlib.dll uses PInvoke as it is flagged as unmanagedCode.
Any other ideas how I can get it to run from a network drive? Or is it
simply not possible to get a WinForms Application to run from a Network
Drive?
Best regards,
Bengt
Peter Below (TeamB)
> Well, I do use 'classes' from Borland.*
>
> Other than that I only use
> System.Drawing,
> System.Collections,
> System.ComponentModel,
> System.Windows.Forms,
> System.IO
>
> I do not see a dependency to use any borland.* assemblies, so I assume,
> that classes got linked into the application.
I think you *always* have a dependency on borland.delphi.system.dll since it
contains the Delphi-specific stuff of the run-time. But i'm not really up to
speed with all this .NET details.
> The error I am getting is that I am not allowed to load mscorlib.dll.
> That is referenced by System.Windows.Forms and others. Apparently
> mscorlib.dll uses PInvoke as it is flagged as unmanagedCode.
It does, but that assembly should always be in the GAC (which has to be on a
local drive, so does not have this problem).
> Any other ideas how I can get it to run from a network drive? Or is it
> simply not possible to get a WinForms Application to run from a Network
> Drive?
Other than changing the security to full trust? I cannot answer this question,
sorry. I dimly remember reading something about this whole issue in an article
in The Delphi Magazine early this year but cannot find it at the moment.
Marc Rohloff [TeamB]
> I think you *always* have a dependency on borland.delphi.system.dll since it
> contains the Delphi-specific stuff of the run-time. But i'm not really up to
> speed with all this .NET details.
The compiler always adds a reference tot his assembly even if you
don't. You should be able to link it into a single executable by
explicitly adding a reference to Borland.System.dll, right clicking on
it and selecting 'Link In Units'.
(This is also worth a look:
http://www.codeproject.com/dotnet/mergingassemblies.asp
and
http://research.microsoft.com/~mbarnett/ilmerge.aspx
)
If I remember correctly you can refer to code from the system unit but
adding code from SysUtils will cause problems.
--
Marc Rohloff [TeamB]
marc rohloff -at- myrealbox -dot- com
Bengt Skogvall
>>I do not see a dependency to use any borland.* assemblies, so I assume,
>>that classes got linked into the application.
>
>
> I think you *always* have a dependency on borland.delphi.system.dll since it
> contains the Delphi-specific stuff of the run-time. But i'm not really up to
> speed with all this .NET details.
Looking at Borland Reflection, I see Borland.Delphi.System is linked
into the exe. Also, the exe can be run on a clean xp system witout
deploying Borland.Delphi.System.dll into that system.
>
>
>>The error I am getting is that I am not allowed to load mscorlib.dll.
>>That is referenced by System.Windows.Forms and others. Apparently
>>mscorlib.dll uses PInvoke as it is flagged as unmanagedCode.
>
>
> It does, but that assembly should always be in the GAC (which has to be on a
> local drive, so does not have this problem).
I am not sure that is enough, as that would compromise .NET Security (I
think). You should be able to use an assembly, which could potentially
do things you are not allowed to do, as long as you do not use these
features. If you can use also such features, you have effectively
increased your rights.
Best regards,
Bengt
Bengt Skogvall
> The compiler always adds a reference tot his assembly even if you
> don't.
According to adepends.exe (in the SDK), the list of referenced
assemblies does not contain Borland.System.dll. It is also possible to
run the application on a clean XP without including Borland.System.dll.
I actually need only the exe. In my case, the compiler apparently
automagically merges it into the exe.
>You should be able to link it into a single executable by
> explicitly adding a reference to Borland.System.dll, right clicking on
> it and selecting 'Link In Units'.
> (This is also worth a look:
> http://www.codeproject.com/dotnet/mergingassemblies.asp
> and
> http://research.microsoft.com/~mbarnett/ilmerge.aspx
> )
ILmerge is cool! Thanks for the Links!
However, it does not solve my current problem.
There must be a way to tell programmatically that this app will stay
within bounds of what is allowed in LocalIntranet.
Best regards,
Bengt
Marc Rohloff [TeamB]
> According to adepends.exe (in the SDK), the list of referenced
> assemblies does not contain Borland.System.dll. It is also possible to
> run the application on a clean XP without including Borland.System.dll.
> I actually need only the exe. In my case, the compiler apparently
> automagically merges it into the exe.
Then I suggest you
a) Register the Borland assemblies in the GAC on your development and
client machine.
b) Add an explicit reference to Borland.System.dll
c) Right click on the reference and make sure 'link in units' is
unchecked.
Bengt Skogvall
> Then I suggest you
> a) Register the Borland assemblies in the GAC on your development and
> client machine.
> b) Add an explicit reference to Borland.System.dll
I do not have a Borland.System.dll on my computer. Where should it be? I
use Delphi 8.
Best regards,
Bengt
Marc Rohloff [TeamB]
>> b) Add an explicit reference to Borland.System.dll
On my system its at:
C:\Program Files\Common Files\Borland Shared\BDS\Shared Assemblies\3.0
Bengt Skogvall
> On Sat, 13 Aug 2005 20:11:55 +0200, Bengt Skogvall wrote:
>
>
>>>b) Add an explicit reference to Borland.System.dll
>
>
> On my system its at:
> C:\Program Files\Common Files\Borland Shared\BDS\Shared Assemblies\3.0
>
You have Delphi 2005. I only have Delphi 8. in
c:\program files\common files\borland shared\bds\shared assemblies\2.0
there is no borland.system.dll
Any other ideas?
Best regards,
Bengt
Marc Rohloff [TeamB]
> You have Delphi 2005. I only have Delphi 8. in
> c:\program files\common files\borland shared\bds\shared assemblies\2.0
> there is no borland.system.dll
Have you tried:
c:\program files\borland\bds\2.0\bin ?
I know it must be somewhere <g>
There where several changes in Delphi 2005 to handle security better,
I'm not sure if it will work in Delphi 8 at all.
Bengt Skogvall
> Have you tried:
> c:\program files\borland\bds\2.0\bin ?
> I know it must be somewhere <g>
No, it's not on the hard disk, anywhere :-(
> There where several changes in Delphi 2005 to handle security better,
> I'm not sure if it will work in Delphi 8 at all.
>
Ok, I have Delphi 2005 personal edition lying around here somewhere. I
will try installing it.
Best regards,
Bengt
danny heijl
> Have you tried:
> c:\program files\borland\bds\2.0\bin ?
> I know it must be somewhere <g>
D8:
C:\Program Files\Common Files\Borland Shared\BDS\Shared
Assemblies\2.0\Borland.Delphi.dll
D2005:
C:\Program Files\Common Files\Borland Shared\BDS\Shared
Assemblies\3.0\Borland.Delphi.dll
Danny
---
Bengt Skogvall
> D8:
> C:\Program Files\Common Files\Borland Shared\BDS\Shared
> Assemblies\2.0\Borland.Delphi.dll
>
> D2005:
> C:\Program Files\Common Files\Borland Shared\BDS\Shared
> Assemblies\3.0\Borland.Delphi.dll
>
"link in Delphi Units", I get exactly the same error as before.
BUT:
If I do not select "link in Delphi Units", (as Marc suggested) I get
another error:
Security error:
PermissionSet class="System.Security.PermissionSet"
Still a problem with mscorlib.dll, though.
Apparently, we are one step further. I recon, now mscorlib.dll gets
loaded and fails during initialization.
I tried running it further and noticed that the initialization of
classes failed. I let it continue and then the initialization of
sysutils failed.
SYSUTILS???? What has that to do with my app? The only class I used
from the Borland.VCL namespace was Tstringlist.
I tried adding a reference to Borland.vcl without selecting "link in
Delphi units" but that did not make any change.
So, I removed all references to classes. I changed TstringList in my App
to StringCollection. Now my App starts!
I now removed Borland.vcl.dll and Borland.Delphi.dll from references and
it still runs!
Well at least sort of. Not completely. It starts. My App wants to copy
some files from a usb drive to the hard disk. To be able to know which
ones, it calls Directory.GetFiles. Request for the right to do
PathDiscovery is denied, however. :-(
Oh well.
To summarize it, It seems that the usage of ANY class in the Borland.VCL
namespace is not possible under Delphi 8 if you need to run from a
network drive.
Perhaps Delphi 2005 implements the libraries differently?
Is PathDiscovery really outside of what is allowed for Applications
starting from a Network drive? If that is the case, also Open Dialogs
would be off limits, I think. Are there alternatives?
Any Ideas?
Best regards,
Bengt
danny heijl
> I tried running it further and noticed that the initialization of
> classes failed. I let it continue and then the initialization of
> sysutils failed.
>
> SYSUTILS???? What has that to do with my app? The only class I used
> from the Borland.VCL namespace was Tstringlist.
If you want to avoid these problems you should not use any Borland.* class.
The .Net framework has excellent (frequently better) equivalent classes
for stuff like TStringList etc... (have a look at ArrayList and
Collection for instance).
You can easily provide a "compatibility" wrapper for basic Delphi
classes like TStringList using the native .Net classes like ArrayList
internally while preserving source compatibility between Win32 and .Net.
Danny
---
Bengt Skogvall
> If you want to avoid these problems you should not use any Borland.* class.
>
> The .Net framework has excellent (frequently better) equivalent classes
> for stuff like TStringList etc... (have a look at ArrayList and
> Collection for instance).
>
> You can easily provide a "compatibility" wrapper for basic Delphi
> classes like TStringList using the native .Net classes like ArrayList
> internally while preserving source compatibility between Win32 and .Net.
>
Thanks for pointing that out! I will definitively stay clear of the
Borland.* classes.
It is really a pity that I have to do that. In the past, the Borland
classes really stood out in the win32 world.
Best regards,
Bengt
danny heijl
> It is really a pity that I have to do that. In the past, the Borland
> classes really stood out in the win32 world.
They still do stand out to some extent in the Win32 world, but they have
also "stood still" for a very long time, so you could say that they let
.Net overtake them.
Danny
---