Why does the user have to install the files on an internal network share? Is the installation for him alone? You could try this:

Deploy the files to a folder on your computer like C:\MyAppDeployment\.

Zip up that folder and send it to your guy.

Have him unzip it into the same foldername, and double-click on the setup.exe in the folder.

Over time, if he unzips into that folder, he will end up with the Application Files structure, and he can delete the old versions from application_files, or not. Doesn't matter.

What matters is that your installation URL matches the one he installs from, be it a web address or a folder name on a hard drive.

RobinDotNet

Hello Victor,

I am writing to check the status of the issue on your side. Would you mind letting me know the result of the suggestions? If you have any additional question, welcome to post here.

Have a great day!

Thanks,
Rong-Chun Zhang
MSDN Subscriber Support in Forum
If you have any feedback on our support, please contact msdnmg@microsoft.com

I ended upwith a temporary solution that involves setting the publish location to c:\myFolder\myFolder and publishing to my local machine. I also turned off checking for updates since this relaxesthe requirement to verify the DeploymentProviderURL.

I then programmatically added codeto check for updates.In effect the update capability is still there without the requirementto go to the DeploymentProviderURL.

I still need a better solution in respect to not having the customer install on their server at the "c:\myFolder\myFolder" location. Again, we ship a CD with an MSI that contains the ClickOnce deployment because some of our customers operate secure internal LAN/WANS and do not have outside public internet access. Therefore I want to let them use the MSI to pick any location on their network to drop the ClickOnce deployment into, and then their people will install and update from that location. This is the scenario I am trying to find a solution for andstill have not found it. Having a "hard coded" location is not desirable or optimal. Many networks do not use a c: drive to prevent virus attacks that assume every machine has a c:\ drive.

I know it is possible to do this by automating the modification of the manifest file using the MAGE tool, however as previously posted, this is notsecure sinceeither I have to expose my certificateor my customers' need to compromise theirs. What I want is the easy ClickOnce install and dependency checking, the updating capability, and the easy uninstall capability. What I DO NOT want is the manifest checking and signing and DeploymentProvider URL verification. Once delivered to my customer it is up to them to secure the application. I also have a licensing scheme in place to further protect who installs and uses my software, so I do not need ClickOnce to do this. Does this make sense????


Here is the code to check for updates in case someone else wants to go down a similar path:

class ClickOnce
{
private static System.Timers.Timer _updateTimer = null;
public static void StartListeningForUpdates()
{
if (ApplicationDeployment.IsNetworkDeployed)
{
_updateTimer = new System.Timers.Timer();
_updateTimer.Interval = 10000;
_updateTimer.Elapsed +=
new System.Timers.ElapsedEventHandler(_updateTimer_Elapsed);
_updateTimer.Start();
}
}

public static void StopListeningForUpdates()
{
if (ApplicationDeployment.IsNetworkDeployed)
{
_updateTimer.Stop();
_updateTimer.Dispose();
}
}

private static bool _updating;
static void _updateTimer_Elapsed(object sender,
System.Timers.ElapsedEventArgs e)
{
if (ApplicationDeployment.IsNetworkDeployed)
{
ApplicationDeployment current =
ApplicationDeployment.CurrentDeployment;

if (!_updating)
{
try
{
if (current.CheckForUpdate())
{

Log.Write("ClickOnce we have updates!", 2);
_updating = true;
current.Update();

}
}
catch (Exception ex)
{
Log.Write(String.Format("ClickOnce Update failed: {0}", ex.Message), 1);
_updating = false;
}
}
}
}
}

// add this to your main or startup method:

ClickOnce.StartListeningForUpdates();

Thanks for your help,

Victor