For the purpose of consistency, version numbers should be the same there are few exceptions. One exception is for backward compilation: if you have other .dll files depend on the assembly, changing Assembly Version will break these dependencies and then cause a crash in your application.
So you can keep the Assembly Version unchanged and increase the File Version when you release new build. It is easy to maintain the version numbers in VS.NET. For more information on versioning see semantic versioning rule.
The Assembly Version, File Version should be in Sync 95% of the time. The only case is backward compatibility. If you are using ClickOnce for deployment, you also need to keep the Publish Version in sync also. Yes that is 3 places Microsoft should make this easier. See semantic versioning.
In general, you should set the user to download the Setup.exe of your ClickOnce application. However there are many cases where the only prerequisite of the application is .NET 2, and the users don't need the Setup.exe. Instead, the .application file would allow the user to install the application, or run it instantly if they already have .Net 2. The following code allows you to check for the .NET 2 runtime on the client's machine (note: Request.Browser.ClrVersion may return 0.0 on some browsers).
If you use ClickOnce to deploy your application, you should clearly show a symbol indicating this is a ClickOnce version application. ClickOnce makes applications enjoying convenient update, maximising to keep the safety of the users' system environment.
Application updates don't have to be difficult to do for the user. Pointing the user to a website where he can download an update is not ideal. A better way is to take advantage of the System.Deployment.Application namespace. You can develop custom upgrade behaviours into your ClickOnce/Smart client application.
You should have a standard menu item "Check for Updates" in the Help menu.