It can be pointed to existing AppPools, but it will always modify the AppPool's Identity. In v5.0 the deployment on a server always assumes that a username and password will be provided to configure the AppPool identity. I created an issue for v5.1 that will make that step conditional on the presence of a value in both $(VDIR_UserName) and $(VDIR_UserPass), so if you don't provide either one there will not be an error and the AppPool identity will be untouched.
In the meantime, your only options are to point to a dummy account as you described, then reassign the vdir's app pool later on, OR to override or modify the default DeployVDirs target. The former option is probably best until v5.1 is available. You can use the following task in a custom target to reassign the vdir:
Tom
In the meantime, your only options are to point to a dummy account as you described, then reassign the vdir's app pool later on, OR to override or modify the default DeployVDirs target. The former option is probably best until v5.1 is available. You can use the following task in a custom target to reassign the vdir:
<AssignVirtualDirectoryToAppPool MetabasePath="$(IISMetabasePath)" VDirName="MyVDir" AppPoolName="TheAppPool" />Tom