I have a number of successful builds behind me.  Suddenly, I get this error output when deploying recent changes in my application:

Error 1 Failed to copy file 'C:\Aspire Projects\AspireSF\AspireSF\bin\Debug\app.publish\AspireSF.application' to '\\Spmonroe\Monroe\Deployment\AspireSF\AspireSF.application'. Unable to add 'AspireSF.application' to the Web site.  The file 'AspireSF.application' already exists in this Web site.  1 1 Aspire.SF

When I actually look at the folder that VS2008 sticks out there, it is full...nothing missing.  All users are updating properly.

Why am I getting this error?

Thanks,
Bill

Hi Bill,

It looks like your web application was simply in use whenever you went to deploy and (as such) the .application file couldn't be overwritten or cleared.

I would definitely recommend precompiling your application rather than just deploying it as is (which is what it looks like you are doing.) This should not only resovle the issue you are having, but will make your web application run much faster.

To precompile, you will add a call to aspnet_compiler.exe within the post-build of your project. Aspnet_compiler.exe is distributed with .net and can be set to clear out the destination directory before deploying, not to mention the greater benefit of making your web application run a lot faster. There is a ton of info out there about using aspnet_compiler.exe out on msdn and elsewhere.

Here is an example of a typical call to aspnet_compiler.exe in the post build of one of our web projects:

The /p specifies the path to your solution, the /v identifies the virtual directory for the destination, and the /f signifies that the destination should be cleared before deployment.

Hope it helps ,

Dustin

Hey Dustin!

You are right...there was a user who has kept open the .application file.  No answer from her, so I will wait on her for further information as to why this may be happening (stalled installation, error popup, etc.).  Appreciate your help.

Btw, I am not sure what you mean by this.  I will do a little research to figure this out.  One-click deployment (Windows Forms) has been quite useful, so far.  Since it is not really broken, I am not sure what you suggest would be an enhancement.

Regards,
Bill

Dusting is talking about deploying an ASP.NET application and precompiling it for deployment.



I believe you are talking about deploying a WinForms application using ClickOnce, where you couldn't do the final deployment because a user was using the .application manifest file.



I'd suggest that you might consider publishing to a local folder, then moving the deployment to the web site at a different time, e.g. during off hours. When you are on the publish tab, there are two textboxes to indicate both were you want to publish the application to (there the .application, .manifest and .deploy files will be copied) and also the installation folder (were the user will navigate to to install the application...this URL is embedded within the .application file to prevent spoofing). I'm guessing you are just filling in the top one with you install folder on a web site ("http://www.mycomany.com/install" for example) and leaving the other one blank.



Try publishing to a local folder by putting that path into the top textbox ("C:\myapp\publish" for example) and then putting the install site in the second textbox ("http://www.mycomany.com/install" for example). Then you can publish independently of actually deploying it.



If I'm guessing right, this should at least separate you publishing the app in VS from deploying to your installation server. Then when something like this happens, it is just a matter of getting the user off the system and copying the files again (as opposed to having to republish the application again).



Hope that helps (and is on the right track)!

If ClickOnce is working for you...then you are the ONE person that made it work   Actually if you have a very simple deployment environment (in other words only deploying to a static site and location)...and I mean very simple, then it will work about 80% of the time.  So you can see where my opinion of ClickOnce lies.

Regardless, Dustin's point is that you should always pre-compile your application.  ClickOnce doesn't do this by default.  When you pre-compile ASP.NET application, it does just what it says...it compiles the application so when a user shows up, the site will perform faster.  Secondly, when you deploy this through a post-build command, you can have it clear out the destination folder, etc. as part of the deployment.  Last, it will prevent files from staying open like this (in most cases) when in a compiled format.

An example of this is that I can deploy at time time of day (though I may kick someone off if they were in the middle of something...and a service call may follow ) but you can force the deployment.

Finally, you application will not only perform faster, but is more secure when pre-compiled.  Only place holders are deployed in place of the pages (i.e. default.aspx)).

I would highly recommend pre-compiling any ASP.NET application prior to deployment.  And by using a post-build mechanism and setting up a "Deploy" configuration within your solution, then it negates the need for ClickOnce (if you are deploying to a single site) and gives you far more control over the build as well as the deployment environment.

Sorry...great advice, but I am not deploying a web app.  This really is a simple winforms deployment (and has worked flawlessly for months).  I will, however, consider your thoughts, Greg, on splitting the publish and install folders.  Intriguing.

Perhaps you could help with additional issue related to this.  The user who had the file opened is in a remote location connected via T1.  To install this app (>45MB) through the pipe from one location has been a bit slow for most remote users.  So, I have published the app in two locations each time.  This is annoying.  Would the split between publish location and install location help with this situation?  If I could speed up the install times, that would be great. And, publish times....the time to publish to the remote server is about 10 minutes.

Thanks!!
Bill

Sorry...both Dustin and I read into web site when we read your initial post.  In regards to deployment, we never use ClickOnce...we clicked it once (and every time that they had a patch or update too) and it never worked worth a hill of beans...so we created our own deployment process for this type of thing...which we can control and rely on.

We have a server service that all of the clients connect to (probably overkill for what you are trying to do) that verifies licensing, etc.  But we also use it for updates.  When the client app launches, it recognizes that there is an update available, automatically downloads it, spawns and installs it, then restart the app.  The user never has to worry about getting out the first time and it will automatically take care of itself.  You can do the same thing with a web service.  Just query the service when the client launches, if there is a new update, download it (on a thread even if you like) and then either launch it then automatically or give the user the option...depending upon your needs. Then it takes all of the files in use stuff out of the forumla.  You can even have a service on the client side (again, if you have the need) that downloads the update when it sees a new version out there, and then schedules the update after hours or something.

No worries.  I just tried Greg's suggestion.  The version did not register on the install site.  For whatever reason, it did not increment...it stayed at the last build.  Odd.  I am probably doing something wrong.  Well, I am going back to my orginal setup.  It works...just never had a user attempting an update while I was publishing the app.  Everything seems to be working fine now that the files are no longer locked.

Thanks!! 
Bill

I've been using ClickOnce for about a year now. Probably published the app a 100+ times (in the beginning I'd have to do it about 5 times for each publish because I kept making mistakes). My app allows for 4 distinct versions (build, beta, training and production) to be installed on the users machine at once. I have also used ClickOnce to publish obfuscated apps as well. It works pretty well (especially considering I don't have the time to roll my own). The only way I can get to the server were the production installation is by remoting into a terminal server, then remoting to the web server from it...sigh. The only time I have ever published directly to the install site was when I was first learning about it and did to my local IIS. Here are some things I've learned:



1. I always publish to a local folder. I almost always have to do some post procesing of the .application file (and sometimes the .manifest file as well, like when obfuscating). Also, since I remote into to all of my installation servers, I can then zip the installation files to speed deployment. This is especially important when I'm remoting twice, hence have to copy twice (they swear they're going to setup a VPN concentrator soon!).



2. I have found that it is a good idea increment the ClickOnce version every time I publish, even if there are no code changes. Just too likely to have problems. I also control the version manually, rather than allow the auto increment feature. I.e. if I'm testing version 1.0.0.0 in beta, and all is good, when I publish to production, the version will be 1.0.0.1, even though it is the same application. Don't do this and you are asking for trouble....



3. I use MageUI.exe to change the name and description in the .application file (this allows for multiple instances of same app to be deployed via ClickOnce...build, beta, production). When changing anything in this file, I also always just reselect the .manifest file also...makes sure all the hashes are correct.



4. ClickOnce has a mechanism to ensure that the .application, .manifest and all the .deploy files aren't tampered with. It stores a hash for each file. Any changes to any file means that the .manifest and .application files need to be updated with the new hash. MageUI does this.



5. At some point your certificate will expire. This will invalidate all of your installations. It's like Christmas in July. At this point, after some head banging as you figure out what is occurring, you will have the obvious, but painful choice of having all of your users uninstall, then reinstall the application (that is using the new certificate) or you can use a tool like this to update your certificate so it isn't expired http://www.may.be/renewcert/.



6. ClickOnce doesn't do secured sites. Period. You cannot access a clickonce installation site unless you allow anonymous access. This of course refers to the installation, not the application, which can be as secure as needed.



7. There is a command line equivalent for mageui.exe, mage.exe. This can be used in msbuild tasks to automate the process, but I haven't figure that out yet...



I might suggest the following process for you Bill:



1. Setup a publish folder to hold your published apps. Some thing like:

c:\myapp\publish\primaryserver

c:\myapp\publish\remoteserver

2. publish in VS. Set a local folder (c:\myapp\publish\primaryserver) and your primary install site.

3. copy this into the remoteserver folder

4. open the remote server's version specific .application file (see notes below) using mageui and update the installation url to the remote site, select the manifest in the remote folder, save the file (this updates the hashes).

5. update .application file by copying the version specific .application file over it (see notes below).

6. zip the appropriate files for primary and remote servers.

7. copy to primary and remote servers and unzip.

8. Update publish.htm to indicate new version.



I'd be glad to offer more help as needed...



Notes (just in case...):

- in VS 2005, when you publish a clickonce, it would add a version folder that contained all the .deploy files and the .manifest file and it would add a version specific .application file in the root folder, then overwrite the .application file. (If this sounds confusing...it is You have to do a few times to get it). So the folders look like this:

c:\myapp\publish\

myapp.application

myapp_1_0_0_.application

publish.htm

c:\myapp\publish\myapp_1_0_0_0\

myapp.manifest.exe.manifest

myapp.exe.deploy

mylib.dll.deploy

Microfour StratarFrame Base.dll.deploy

...etc....

So when I update the version specific .application file I'm updating (in this example) myapp_1_0_0_.application, then copying it over myapp.application.

- VS 2008 does it differently. It creates an "Application Files" folder and puts the version specific folders there. It also puts the .application file for the specific version within this version specific folder:

c:\myapp\publish\

myapp.application

publish.htm

c:\myapp\publish\Application Files\myapp_1_0_0_0\

myapp.application

myapp.manifest.exe.manifest

myapp.exe.deploy

mylib.dll.deploy

Microfour StratarFrame Base.dll.deploy

...etc....

In this case, I update the myapp.application file in the c:\myapp\publish\Application Files\myapp_1_0_0_0\ folder, then copy that over the myapp.application file up in the root.

Fantabulous!  Thanks a ton, Greg!!  I am getting close to 100 publications of my app.  Great stuff here (especially the link for taking care of the certificate thing)...I will peruse deeper after I tackle a couple of other issues.

You're always a big help!  Hope I can do the same for you someday.

Have a great night!
Bill