> Hi, all!  Trying to build a stand-alone vb.net app (from VS.Net 2k5) that
> will let me just take the EXE from the dev box over to a client box and run
> it, as-is, without "installing" it.  I was under the assumption that this
> was still possible, but I seem to get security errors on client boxes when I
> just run the EXE on the client machine.  Even after tweaking the ClickOnce
> settings to specfically allow the type that's giving me the error, I still
> get it.  The only way to prevent the errors is to do a typical install (run
> the setup.exe), which defeats the whole purpose in the first place.
>
> What's the trick?  Workstations are all Xp/Pro, latest patches (including
> Framework 2.0), running inside a Win2k3 domain (users do NOT have
> administrative privilege locally).  Help!! :)
>
> Jack

"FishingScout" <fishingsc***@comcast.net> wrote in message
news:1163543318.293693.99630@h48g2000cwc.googlegroups.com...
>
> Mr. JackBlack,
>
> What is your application trying to do?  What is reporting the security
> errors or how are the errors being reported to you?
>
> You may already know this, but...  Some application behavior requires
> administrative privileges to perform their activities.  For example,
> the logged in user may not have the correct permissions to modify the
> registry; if your application is attempts to create a key it will fail
> due to permissions.  Are you running the application on the other boxes
> using the same domain account?
>
> Some application behavior requires administrative privledges
> JackBlack wrote:
>> Hi, all!  Trying to build a stand-alone vb.net app (from VS.Net 2k5) that
>> will let me just take the EXE from the dev box over to a client box and
>> run
>> it, as-is, without "installing" it.  I was under the assumption that this
>> was still possible, but I seem to get security errors on client boxes
>> when I
>> just run the EXE on the client machine.  Even after tweaking the
>> ClickOnce
>> settings to specfically allow the type that's giving me the error, I
>> still
>> get it.  The only way to prevent the errors is to do a typical install
>> (run
>> the setup.exe), which defeats the whole purpose in the first place.
>>
>> What's the trick?  Workstations are all Xp/Pro, latest patches (including
>> Framework 2.0), running inside a Win2k3 domain (users do NOT have
>> administrative privilege locally).  Help!! :)
>>
>> Jack
>

> Thanks for responding!
>
> No, the app is just about as basic as it gets!  Display a RichTextBox with a
> legal disclaimer, and a CommandButton to close the window.  The app has to
> run under the restricted privs of every domain account (it'll be called from
> a domain login script and run from a network share that all users have Read
> & Execute privs to).  Took a whole 2 minutes to build, and now it's taking
> hours to get the security ironed out! :-P
>
> Any suggestions would be of help at this point, since the permissions
> settings appear to be good.
> Jack
>
>
>
> "FishingScout" <fishingsc***@comcast.net> wrote in message
> news:1163543318.293693.99630@h48g2000cwc.googlegroups.com...
> >
> > Mr. JackBlack,
> >
> > What is your application trying to do?  What is reporting the security
> > errors or how are the errors being reported to you?
> >
> > You may already know this, but...  Some application behavior requires
> > administrative privileges to perform their activities.  For example,
> > the logged in user may not have the correct permissions to modify the
> > registry; if your application is attempts to create a key it will fail
> > due to permissions.  Are you running the application on the other boxes
> > using the same domain account?
> >
> > Some application behavior requires administrative privledges
> > JackBlack wrote:
> >> Hi, all!  Trying to build a stand-alone vb.net app (from VS.Net 2k5) that
> >> will let me just take the EXE from the dev box over to a client box and
> >> run
> >> it, as-is, without "installing" it.  I was under the assumption that this
> >> was still possible, but I seem to get security errors on client boxes
> >> when I
> >> just run the EXE on the client machine.  Even after tweaking the
> >> ClickOnce
> >> settings to specfically allow the type that's giving me the error, I
> >> still
> >> get it.  The only way to prevent the errors is to do a typical install
> >> (run
> >> the setup.exe), which defeats the whole purpose in the first place.
> >>
> >> What's the trick?  Workstations are all Xp/Pro, latest patches (including
> >> Framework 2.0), running inside a Win2k3 domain (users do NOT have
> >> administrative privilege locally).  Help!! :)
> >>
> >> Jack
> >

"rowe_newsgroups" <rowe_em***@yahoo.com> wrote in message
news:1163547394.100691.181580@m73g2000cwd.googlegroups.com...
> You still didn't share which exceptions you're getting...
>
> Without that it's a bit difficult to help anymore!
>
> Thanks,
>
> Seth Rowe
>

"Chris Dunaway" <dunaw***@gmail.com> wrote in message
news:1163600976.368338.220460@f16g2000cwb.googlegroups.com...
> JackBlack wrote:
>
>> (it'll be called from a domain login script and run from a network share
>> that all users have Read
>> & Execute privs to).
>
> That is the problem right there.  Because the app is on a network
> share, the .Net framework on the local machine is not allowing the code
> to execute because it is not trusted.  You need to use caspol.exe to
> grant trust on the local machine to that application.
>
> Here is the command we use:
>
> C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\caspol -m -ag All_Code
> -url file://server/folder/* FullTrust -n AppName
>
> This grants full trust on the client machine to the application on the
> network share.
>

> Chris, thanks for replying!
>
> Well, a couple things:  First, running caspol as you suggested below
> (substituting the appropriate machine names and file paths, of course) had
> no effect whatsoever.  I still get a UIPermissions exception when the
> program is executed by the average domain user.  Additionally, when a user
> with local Admin privileges and elevated domain privs executes the app now,
> it starts up fine, but upon clicking the CommandButton that terminates the
> program, I now get a SecurityPermission exception.
>
> Second, if this command needs to be run at each workstation, then it kinda
> defeats the purpose of having a stand-alone app, doesn't it?  If I have to
> touch each machine, I might as well just do a normal installation to the
> local machine (setup.exe route), right?
>
> Additionally, the caspol.exe app can only be run by an administrator, so
> even that can't be scripted (requiring that I touch each machine).  So we're
> still at square one, no?
>
> Having read a bit more, it seems that the "xcopy distribution" method isn't
> really true.  What I need to be able to do is take an executable, drop it on
> a network device that the average network user has read/execute privs on,
> and have it run from a login script, without having to touch any of the
> machines.  Is this do-able?
>
> Much thanks again,
> Jack
>
>
>
>
>
>
>
> "Chris Dunaway" <dunaw***@gmail.com> wrote in message
> news:1163600976.368338.220460@f16g2000cwb.googlegroups.com...
> > JackBlack wrote:
> >
> >> (it'll be called from a domain login script and run from a network share
> >> that all users have Read
> >> & Execute privs to).
> >
> > That is the problem right there.  Because the app is on a network
> > share, the .Net framework on the local machine is not allowing the code
> > to execute because it is not trusted.  You need to use caspol.exe to
> > grant trust on the local machine to that application.
> >
> > Here is the command we use:
> >
> > C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\caspol -m -ag All_Code
> > -url file://server/folder/* FullTrust -n AppName
> >
> > This grants full trust on the client machine to the application on the
> > network share.
> >