Deal with update location for click-once

I'm not sure how many people here are experts with visual studios, but I'd imagine a handful (not to raise expectations but to appeal to your egos :P).

I'm working primarily in visual basic for now (though I hope to switch to c# in the near future and maybe a java or web app).

Basically I'm trying to create an update feature that will work similarly to how common programs such as firefox or itunes update automatically. There is supposed to be provided functionality for this in what is called click once.

I carry out the following procedures and get the following errors when trying to change the update url of my program to a password-protected ftp location.

Go to project properties

Go to publish

click updates

click browse

click FTP Site

Under Server put: web###.opentransfer.com

Under Port: 21

Under Directory put: CMSOFT

Passive mode is selected (which is what filezilla tells me the server is accessed with)

Anonymous User is unselected and a username and password are typed in

Push Ok

Under Update location it shows: ftp://web###.opentransfer.com/CMSOFT

I push Ok

I see a message box titled Microsoft Visual Basic 2010 Express with an x icon

Publish.Upd开发者_Python百科ateUrl: The string must be a fully qualified URL or UNC path, for example "http://www.microsoft.com/myapplication" or "\server\myapplication".

I've tried changing the directory to "CMSOFT/PQCM.exe" and the results are the same...hope this was descriptive enough.

With ClickOnce deployment (the publish tab in Visual Studio), you can publish to a webserver or file share with FTP. You can NOT install a ClickOnce application using FTP. You have to use http or a file share (as you have discovered). (You can also publish to a CD and provide the deployment that way, but that doesn't really help you here.)

If your intention is to protect your ClickOnce deployment, the only real way to do this is to use Windows integrated security to protect the default deployment manifest (.application file). Of course, this is only practical for an application hosted on an intranet inside a company.

Your other choice is to password-protect the page where the Install URL is invoked, but this isn't 100% secure, since anybody could get the link to the setup.exe or .application file and run it directly without ever going through the web page.

We provide protection by requiring the customers to log into our application when they start it up. So they can install the ClickOnce application, but they can't use it unless they are a valid user.

I'm having formatting issues with comments, so I'll answer your questions here.

Links on setup & deployment packages
http://support.microsoft.com/kb/307353
http://msdn.microsoft.com/en-us/library/tw8kdk75.aspx
http://msdn.microsoft.com/en-us/library/k3bb4tfd.aspx
My expertise is in ClickOnce deployment; I know very little about S&D packages. AFAIK, the expert is Phil Wilson, and he answers questions in the MSDN ClickOnce and Setup & Deployment Forum. He's a brilliant guy.

Also note that the setup & deployment project type is not available in the Express versions of VS.

Why do the users need to have access to the executable?

If you want people to be able to run the application without it being installed, why don't you just do an XCopy of the \bin\release folder and let them put it wherever they want to and then run it via the exe file?

Microsoft doesn't have a problem with installing a program to Program Files; it's just not for ClickOnce applications. Installing in Program Files requires admin privileges, and that is counter to the design goals of ClickOnce deployment. The point of C/O is to provide a lightweight deployment methodology that doesn't require administrative privileges. It installs the files under the user's profile, and it keeps them cached separately from anything else so you can be sure that installing a ClickOnce deployment cannot mess up anything else on the computer. This gives IT folks a nice warm fuzzy feeling. As a customer, it would give me a warm fuzzy feeling because I wouldn't have to worry about dll hell or something like that impacting me. The other great feature of C/O deployment is the automatic updates, which means you can ensure the users get automatic updates and they are always running the most current version of the application with almost no effort on your part.

It seems like you want the ability to force the users to run the most recent version (i.e. upgrades), but you don't want to install the application in a specific place, or require that it be installed. Those two things are counter to each other, and the only way I know of to accomplish that is to write your own deployment packaging.

I don't see how putting the application in some folder on the user's computer is going to allow you to do programmatic updates even. ClickOnce does have an APi that you can call to check for updates, the really the application must be hosted on a file share or web server. If you have to send files to a user and have him put them in a specific folder so he can then run the application and get an update, it's just overkill. Just send him the files and have him put them in a specific folder, and your work here is done.

There is a big difference between visual studio and the C/O document. http://msdn.microsoft.com/en-us/library/bb608591.aspx Correct me if i'm wrong, on MSDN, it says the installation folder can be local, but actually it only allows UNC folder.

It will be better if there's a way that we can specify to local path per document said.