468,765 Members | 1,291 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,765 developers. It's quick & easy.

how to download exe to client from ASP.Net page

We have a requirement to put a client onto machines intended for some
telephony work. The database access will be via ASP.Net pages, and
that's fine, but the telephony stuff requires access to some legacy
servers. I've prototyped the client itself as Winforms/C# (which was
NOT fun for a C++ curmudgeon like me, but I'll live).

The problem is, I'd like to be able to ensure that the user is always
running the latest client (our current fat clients take care of this
via automatic version checking and self-update, so customers are used
to this).

Now the obvious way to do this is for the users to log in via an
ASP.Net page (as they would have to anyway for data access), have the
exe downloaded to their machines and run automatically. Kind of like
GotoMyPc or CoPilot. This will most likely take place inside the
corporate firewall, though it would be nice if we could achieve the
same over the web.

Problem is I have no idea where to start with this, given that my
web/ASP.Net knowledge is shaky at best. Pointers, anyone ?

--
Bob Moore
http://bobmoore.mvps.org/
(this is a non-commercial site and does not accept advertising)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~
Do not reply via email unless specifically requested to do so.
Unsolicited email is NOT welcome and will go unanswered.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~
Nov 19 '05 #1
16 7133
Bob,

What might work is to have a local service keep the local exe updated by
downloading any new version when the application was not active. So when
the user logs in they have the most recent version.

Streaming files from an http page or ftp area to the client would be quite
an easy task, and that only leaves the service to put it in the correct
place once its got it.

http://www.c-sharpcorner.com/1/filedownloader.asp

--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director

<Bob Moore> wrote in message
news:4i********************************@4ax.com...
We have a requirement to put a client onto machines intended for some
telephony work. The database access will be via ASP.Net pages, and
that's fine, but the telephony stuff requires access to some legacy
servers. I've prototyped the client itself as Winforms/C# (which was
NOT fun for a C++ curmudgeon like me, but I'll live).

The problem is, I'd like to be able to ensure that the user is always
running the latest client (our current fat clients take care of this
via automatic version checking and self-update, so customers are used
to this).

Now the obvious way to do this is for the users to log in via an
ASP.Net page (as they would have to anyway for data access), have the
exe downloaded to their machines and run automatically. Kind of like
GotoMyPc or CoPilot. This will most likely take place inside the
corporate firewall, though it would be nice if we could achieve the
same over the web.

Problem is I have no idea where to start with this, given that my
web/ASP.Net knowledge is shaky at best. Pointers, anyone ?

--
Bob Moore
http://bobmoore.mvps.org/
(this is a non-commercial site and does not accept advertising)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~
Do not reply via email unless specifically requested to do so.
Unsolicited email is NOT welcome and will go unanswered.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~

Nov 19 '05 #2
On Fri, 26 Aug 2005 17:42:01 +0100, John Timney (ASP.NET MVP) wrote:
What might work is to have a local service keep the local exe updated by
downloading any new version when the application was not active. So when
the user logs in they have the most recent version. Streaming files from
an http page or ftp area to the client would be quite
an easy task, and that only leaves the service to put it in the correct
place once its got it.


Nice idea, but we're realy looking for a zero-impact install at login.
The admin access required to install a service on the client would
probably kill this one. We have customers on our current system who...
well, you'd think giving our engineer an admin password was like
sacrificing their first-born.

I'll give the code the once-through and see if it will run from a web
page. That's the killer for us. God, I hate the web :-)

--
Bob Moore
http://bobmoore.mvps.org/
(this is a non-commercial site and does not accept advertising)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~
Do not reply via email unless specifically requested to do so.
Unsolicited email is NOT welcome and will go unanswered.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~
Nov 19 '05 #3
On Fri, 26 Aug 2005 17:42:01 +0100, John Timney (ASP.NET MVP) wrote:
http://www.c-sharpcorner.com/1/filedownloader.asp


Spoke to soon. This sample won't compile under VS.Net 2003 anyway. I
get lots of compile errors and missing references. Amongst other
things, it uses DefaultControlObject, which I can't find any reference
to in the current help, nor any reference online after around 2001
(!).

Likewise WebRequestFactory and SingleCredential.

What's going on here ?

--
Bob Moore
http://bobmoore.mvps.org/
(this is a non-commercial site and does not accept advertising)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~
Do not reply via email unless specifically requested to do so.
Unsolicited email is NOT welcome and will go unanswered.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~
Nov 19 '05 #4
Sorry Bob, I just picked a random example to give you an idea. The method
your after would be the downloadfile method of the wenclient classes.

http://msdn.microsoft.com/library/de...dfiletopic.asp

The example here is really quite straightforward.
--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director

<Bob Moore> wrote in message
news:64********************************@4ax.com...
On Fri, 26 Aug 2005 17:42:01 +0100, John Timney (ASP.NET MVP) wrote:
http://www.c-sharpcorner.com/1/filedownloader.asp


Spoke to soon. This sample won't compile under VS.Net 2003 anyway. I
get lots of compile errors and missing references. Amongst other
things, it uses DefaultControlObject, which I can't find any reference
to in the current help, nor any reference online after around 2001
(!).

Likewise WebRequestFactory and SingleCredential.

What's going on here ?

--
Bob Moore
http://bobmoore.mvps.org/
(this is a non-commercial site and does not accept advertising)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~
Do not reply via email unless specifically requested to do so.
Unsolicited email is NOT welcome and will go unanswered.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~

Nov 19 '05 #5
On Mon, 29 Aug 2005 22:15:09 +0100, John Timney (ASP.NET MVP) wrote:
Sorry Bob, I just picked a random example to give you an idea. The method
your after would be the downloadfile method of the wenclient classes.


One API ? Too simple !!!

Thanks mate, I'm bug hunting in legacy land at the moment and it's
golf tomorrow PM, so it'll have to wait till thursday for a tryout.
Everything stops for golf :-)

--
Bob Moore
http://bobmoore.mvps.org/
(this is a non-commercial site and does not accept advertising)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~
Do not reply via email unless specifically requested to do so.
Unsolicited email is NOT welcome and will go unanswered.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~
Nov 19 '05 #6
On Tue, 30 Aug 2005 19:48:48 +0100, Bob Moore <> wrote:
Everything stops for golf :-)


I got a chance to try DownloadFile. Interesting. It works when the
site is run locally (i.e. the IIS host can download files to its own
hard drive (C:\) from within the web site folder structure), however
it fails when run remotely : the files aren't downloaded to the remote
client. This is probably something to do with security settings, but
more worringly, IIS becomes *completely* unresponsive for *any* hosted
site when this happens. I got some grief from another developer when
I'd brought the web server down for the third time just before lunch.

He got his own back though - he beat me on the golf course :-)

--
Bob Moore
http://bobmoore.mvps.org/
(this is a non-commercial site and does not accept advertising)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~
Do not reply via email unless specifically requested to do so.
Unsolicited email is NOT welcome and will go unanswered.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~
Nov 19 '05 #7
Thats a bit wierd. You could always set your site access permissions to
anonymous and see if it makes a difference. As a client exe, IIS probably
wont know who you are if you have any access permissions turned on - oddly I
would expect it to reject you locally just the same though.

You may well need to tell IIS who you are, and turn on impersonation in your
web.config file so it runs the asp.net page as you. In your client you
might well have to use the identity of the current user.

http://samples.gotdotnet.com/quickst...tityCheck.aspx

Of course as a service, the user would be whatever account you run the
service under when you install it. You can always cheat and run it as an
exe in a scheduled job under a named user which makes it easy to pass
credentials.

So, some success at least - nearly a hole in one!!! Perhaps you should test
it on a test server next time, that way your golfing balls would remain
intact should the server hang again.................

--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director

<Bob Moore> wrote in message
news:sa********************************@4ax.com...
On Tue, 30 Aug 2005 19:48:48 +0100, Bob Moore <> wrote:
Everything stops for golf :-)


I got a chance to try DownloadFile. Interesting. It works when the
site is run locally (i.e. the IIS host can download files to its own
hard drive (C:\) from within the web site folder structure), however
it fails when run remotely : the files aren't downloaded to the remote
client. This is probably something to do with security settings, but
more worringly, IIS becomes *completely* unresponsive for *any* hosted
site when this happens. I got some grief from another developer when
I'd brought the web server down for the third time just before lunch.

He got his own back though - he beat me on the golf course :-)

--
Bob Moore
http://bobmoore.mvps.org/
(this is a non-commercial site and does not accept advertising)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~
Do not reply via email unless specifically requested to do so.
Unsolicited email is NOT welcome and will go unanswered.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~

Nov 19 '05 #8
incidentally, before the actual file write

myWebClient.DownloadFile(myStringWebResource,fileN ame);

try either setting the working directory using

System.IO.Directory.SetCurrent*Directory("put path here"*);

or hard code a full path name in and see if it makes a difference.

--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director

"John Timney (ASP.NET MVP)" <ti*****@despammed.com> wrote in message
news:uJ**************@tk2msftngp13.phx.gbl...
Thats a bit wierd. You could always set your site access permissions to
anonymous and see if it makes a difference. As a client exe, IIS probably
wont know who you are if you have any access permissions turned on - oddly
I would expect it to reject you locally just the same though.

You may well need to tell IIS who you are, and turn on impersonation in
your web.config file so it runs the asp.net page as you. In your client
you might well have to use the identity of the current user.

http://samples.gotdotnet.com/quickst...tityCheck.aspx

Of course as a service, the user would be whatever account you run the
service under when you install it. You can always cheat and run it as an
exe in a scheduled job under a named user which makes it easy to pass
credentials.

So, some success at least - nearly a hole in one!!! Perhaps you should
test it on a test server next time, that way your golfing balls would
remain intact should the server hang again.................

--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director

<Bob Moore> wrote in message
news:sa********************************@4ax.com...
On Tue, 30 Aug 2005 19:48:48 +0100, Bob Moore <> wrote:
Everything stops for golf :-)


I got a chance to try DownloadFile. Interesting. It works when the
site is run locally (i.e. the IIS host can download files to its own
hard drive (C:\) from within the web site folder structure), however
it fails when run remotely : the files aren't downloaded to the remote
client. This is probably something to do with security settings, but
more worringly, IIS becomes *completely* unresponsive for *any* hosted
site when this happens. I got some grief from another developer when
I'd brought the web server down for the third time just before lunch.

He got his own back though - he beat me on the golf course :-)

--
Bob Moore
http://bobmoore.mvps.org/
(this is a non-commercial site and does not accept advertising)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~
Do not reply via email unless specifically requested to do so.
Unsolicited email is NOT welcome and will go unanswered.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~


Nov 19 '05 #9
On Wed, 31 Aug 2005 22:20:00 +0100, John Timney (ASP.NET MVP) wrote:
So, some success at least - nearly a hole in one!!! Perhaps you should test
it on a test server next time, that way your golfing balls would remain
intact should the server hang again.................


Oh it's got far worse since then. We've set up a test server so I can
check out this code. It's IIS 5.1 on an XP rather than the W2K server
I was using before <shrug>.

But now I can't even create a project on the server without triggering
the traditional "user not authorised for a.b.c.d:80" error from
VS.Net. I've spent most of today trawling the net for answers to this
problem, to find that causes vary from security settings on a
pseudo-random selection of server folders, to trusted site settings on
the client. Of course none of these solutions work for me.

<sigh>

I ***hate*** web programming, I really do.
Almost as much as I hate VS.Net.
Remind me again how DLL hell was worse than this ?
--
Bob Moore
http://bobmoore.mvps.org/
(this is a non-commercial site and does not accept advertising)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~
Do not reply via email unless specifically requested to do so.
Unsolicited email is NOT welcome and will go unanswered.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~
Nov 19 '05 #10
Well if its any consolation I prefer the SDK and notepad as I find vs.net
cumbersome for any quick development. Its a lot easier to throw stuff
together as raw text on a web site sometimes, thankfully a lot of the
complexity is removed in whidby.

--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director

<Bob Moore> wrote in message
news:35********************************@4ax.com...
On Wed, 31 Aug 2005 22:20:00 +0100, John Timney (ASP.NET MVP) wrote:
So, some success at least - nearly a hole in one!!! Perhaps you should
test
it on a test server next time, that way your golfing balls would remain
intact should the server hang again.................


Oh it's got far worse since then. We've set up a test server so I can
check out this code. It's IIS 5.1 on an XP rather than the W2K server
I was using before <shrug>.

But now I can't even create a project on the server without triggering
the traditional "user not authorised for a.b.c.d:80" error from
VS.Net. I've spent most of today trawling the net for answers to this
problem, to find that causes vary from security settings on a
pseudo-random selection of server folders, to trusted site settings on
the client. Of course none of these solutions work for me.

<sigh>

I ***hate*** web programming, I really do.
Almost as much as I hate VS.Net.
Remind me again how DLL hell was worse than this ?
--
Bob Moore
http://bobmoore.mvps.org/
(this is a non-commercial site and does not accept advertising)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~
Do not reply via email unless specifically requested to do so.
Unsolicited email is NOT welcome and will go unanswered.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~

Nov 19 '05 #11
On Wed, 31 Aug 2005 22:41:24 +0100, "John Timney \(ASP.NET MVP\)"
<ti*****@despammed.com> wrote:
incidentally, before the actual file write
myWebClient.DownloadFile(myStringWebResource,file Name);
try either setting the working directory using
System.IO.Directory.SetCurrent*Directory("put path here"*);
or hard code a full path name in and see if it makes a difference.


I was using a full path, and I've also tried the above. The problem
appears to be that this code :

try
{
WebClient myWebClient = new WebClient();
myWebClient.BaseAddress = "http://10.1.6.50";
System.IO.Directory.SetCurrentDirectory
("C:\\PNC5Download");
myWebClient.DownloadFile ("Login/Download/Appbars.dll",
"AppBars.DLL");
myWebClient.DownloadFile ("Login/Download/SinkTest.exe",
"SinkTest.EXE");
}
catch (WebException we)
{
MessageBox.Show (we.Message);
MessageBox.Show (we.InnerException.Message);
}
catch (SecurityException se)
{
MessageBox.Show (se.Message);
MessageBox.Show (se.InnerException.Message);
}

Always produces an InnerException error "Could not find file
C:PNC5Download"

Note the missing backslash. If I put the full path in, thus :

myWebClient.DownloadFile ("Login/Download/Appbars.dll",
"C:\\PNC5Download\\AppBars.DLL");

Then I get the error "could not find a part of the path
c:PNC5DownloadAppBars.DLL"

Again with the missing backslashes. What is it about executing this
code in ASP.Net that removes backslashes ?
Bob Moore
http://bobmoore.mvps.org/
Nov 19 '05 #12
On Mon, 05 Sep 2005 17:13:36 +0100, Bob Moore <bo**@mvps.org> wrote:
Again with the missing backslashes. What is it about executing this
code in ASP.Net that removes backslashes ?


OK, I've discovered that doubling-up the doubling-up fixes this issue,
i.e. if I put C:\\\\PNC5Download, that fixes the exception.

However there's something more fundamental here. DownloadFile
downloads the file to wherever the code is executing. So this function
may well work for a Winforms app, but if I put it into an ASP.Net
webform all it does is download the file from the server.... to the
server. Not terribly useful :-(

Bob Moore
http://bobmoore.mvps.org/
Nov 19 '05 #13
yes, it would do that as it takes a remote file and creates it locally. With
any asp.net page, its running on the server - so any local activity is on
the server.

The idea would be that the asp.net file would stream the file to a client
(like a local service exe) - with the client calling downloadfile - hence
the file gets written locally at the client and you have your most recent
version installed. Stick it in a local exe and run the exe on system
startup even to download the remote file.

If you expect to invoke the download from asp.net then you want to use
binarywrite or Response.WriteFile. The disadvantage is that the user would
have to choose to save the file, and the location it went into.

You could of course use the exe as the target for downloadfile and leave
asp.net out of the loop.

You could use the string verbatim marker @"C:\PNC5Download" so it takes the
string as written.

--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director

"Bob Moore" <bo**@mvps.org> wrote in message
news:7s********************************@4ax.com...
On Mon, 05 Sep 2005 17:13:36 +0100, Bob Moore <bo**@mvps.org> wrote:
Again with the missing backslashes. What is it about executing this
code in ASP.Net that removes backslashes ?


OK, I've discovered that doubling-up the doubling-up fixes this issue,
i.e. if I put C:\\\\PNC5Download, that fixes the exception.

However there's something more fundamental here. DownloadFile
downloads the file to wherever the code is executing. So this function
may well work for a Winforms app, but if I put it into an ASP.Net
webform all it does is download the file from the server.... to the
server. Not terribly useful :-(

Bob Moore
http://bobmoore.mvps.org/

Nov 19 '05 #14
On Tue, 6 Sep 2005 17:47:07 +0100, John Timney (ASP.NET MVP) wrote:
The idea would be that the asp.net file would stream the file to a client
(like a local service exe) - with the client calling downloadfile - hence
the file gets written locally at the client and you have your most recent
version installed. Stick it in a local exe and run the exe on system
startup even to download the remote file.


I think since our most pertinent problem is update, rather than the
initial install, it's probably enough for the local client to call
DownloadFile and first install to be done manually. So the scenario
would be

Client starts up
Client sends message to server indicating its version
Client gets reply saying "you need an update, and it's here"
Client calls DownloadFile, warns user, then renames itself, copies the
new file into the right place and shuts down.
User restarts client, and now has new version.
I'm your uncle :-)

--
Bob Moore
http://bobmoore.mvps.org/
(this is a non-commercial site and does not accept advertising)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~
Do not reply via email unless specifically requested to do so.
Unsolicited email is NOT welcome and will go unanswered.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~
Nov 19 '05 #15
Sounds good to me. At least you have most of the research done on making it
tick..........

--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director

<Bob Moore> wrote in message
news:0l********************************@4ax.com...
On Tue, 6 Sep 2005 17:47:07 +0100, John Timney (ASP.NET MVP) wrote:
The idea would be that the asp.net file would stream the file to a client
(like a local service exe) - with the client calling downloadfile - hence
the file gets written locally at the client and you have your most recent
version installed. Stick it in a local exe and run the exe on system
startup even to download the remote file.


I think since our most pertinent problem is update, rather than the
initial install, it's probably enough for the local client to call
DownloadFile and first install to be done manually. So the scenario
would be

Client starts up
Client sends message to server indicating its version
Client gets reply saying "you need an update, and it's here"
Client calls DownloadFile, warns user, then renames itself, copies the
new file into the right place and shuts down.
User restarts client, and now has new version.
I'm your uncle :-)

--
Bob Moore
http://bobmoore.mvps.org/
(this is a non-commercial site and does not accept advertising)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~
Do not reply via email unless specifically requested to do so.
Unsolicited email is NOT welcome and will go unanswered.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~

Nov 19 '05 #16
On Tue, 6 Sep 2005 20:07:54 +0100, "John Timney \(ASP.NET MVP\)"
<ti*****@despammed.com> wrote:
Sounds good to me. At least you have most of the research done on making it
tick..........


Well, the code should now be in Winforms rather than ASP.Net (which
makes me happier), so any further questions will be directed to
another forum. Thanks for the steer.

NB: I could be back if I end up having any of the database webapps
foist on me :-)

Bob Moore
http://bobmoore.mvps.org/
Nov 19 '05 #17

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by Skwish | last post: by
7 posts views Thread by Brian Paul | last post: by
2 posts views Thread by Sleepy | last post: by
4 posts views Thread by Hitesh | last post: by
1 post views Thread by Iulian | last post: by
2 posts views Thread by Jan Paul van de Berg | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by Marin | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.