By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,635 Members | 2,240 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,635 IT Pros & Developers. It's quick & easy.

ClickOnce files being re-downloaded unneccesarily

P: n/a
I have an application which requires a number of DLLs (unmanaged ansi C dlls)
to reside in the same directory as the application. I currently have these
dlls included in the project folder and marked as "content".

When I publish the application with ClickOnce and update my application -
these dlls (along with a .chm help file that doesnt change) keep being
redownloaded. From what I've read in all of the ClickOnce marketing hype, it
claims that only files that have changed will be redownloaded - but these
files seem to be always redownloading. From what I can tell from the manifest
file in the Release directory, the hashes of these dlls are the same. My
application is simply using "dllimport" statements to access functions in the
dlls, so the dlls themselves arent being recompiled.

If I mark the files as data - and choose the "exclude" option in the
publishing properties, it seems to roll the existing files forward to the new
version as expected - however as I said previously, I need the files to exist
in the same folder as the program/executable.

I've considered using System.IO.File.Move to grab the dlls from the data
directory and put them in the application folder at runtime, but for some
reason this seems dangerous/unreliable to me.

If this application was just residing on a regular LAN, I wouldnt care - but
the intent is to distribute updates over the web to customers, and this is
adding an unccessary 2-3MB of downloading for each update.

Anyone have any ideas what I'm doing wrong? Or is this just how ClickOnce
works so I'll have to live with it?

Regards,
Andrew
Jul 18 '06 #1
Share this Question
Share on Google+
1 Reply


P: n/a
Issue resolved, ClickOnce wasn't really downloading the files (no network
activity despite the clickOnce asynchronous progress reporting that it was
downloading). Is there any way to receive the *real* download size of the
deployment? Rather than just the size of the total deployment? I'm trying to
make a download progress bar with asynchronous updates that is actually
useful to the end-user.

"Andrew86" wrote:
I have an application which requires a number of DLLs (unmanaged ansi C dlls)
to reside in the same directory as the application. I currently have these
dlls included in the project folder and marked as "content".

When I publish the application with ClickOnce and update my application -
these dlls (along with a .chm help file that doesnt change) keep being
redownloaded. From what I've read in all of the ClickOnce marketing hype, it
claims that only files that have changed will be redownloaded - but these
files seem to be always redownloading. From what I can tell from the manifest
file in the Release directory, the hashes of these dlls are the same. My
application is simply using "dllimport" statements to access functions in the
dlls, so the dlls themselves arent being recompiled.

If I mark the files as data - and choose the "exclude" option in the
publishing properties, it seems to roll the existing files forward to the new
version as expected - however as I said previously, I need the files to exist
in the same folder as the program/executable.

I've considered using System.IO.File.Move to grab the dlls from the data
directory and put them in the application folder at runtime, but for some
reason this seems dangerous/unreliable to me.

If this application was just residing on a regular LAN, I wouldnt care - but
the intent is to distribute updates over the web to customers, and this is
adding an unccessary 2-3MB of downloading for each update.

Anyone have any ideas what I'm doing wrong? Or is this just how ClickOnce
works so I'll have to live with it?

Regards,
Andrew
Aug 16 '06 #2

This discussion thread is closed

Replies have been disabled for this discussion.