IISApp VDIR with subdiroctories give undesired output

Topics: IIS and Web Services
Dec 22, 2014 at 7:02 PM
Hi all,

Thanks for the ever continuing work here and I do think IISApp is a step foward but I did encounter something I cannot easily explain.
I have setup a IISApp tag as below:
    <IISApp Include="*">
      <AppPoolName>BtsWcfBasicHttp</AppPoolName>
      <DeployAction>CreateOrUpdate</DeployAction>
      <UndeployAction>Delete</UndeployAction>
      <Exclusions>Temp;*.csproj;Web.Debug.config;Web.Release.config;WcfServiceDescription.xml;obj;Properties</Exclusions>
      <VirtualPath>ServiceDIrectory/ServiceName/1.0</VirtualPath>
      <PhysicalPath>..\Logicx.BizTalk.FlowToAlpa.IISAP</PhysicalPath>
      <SiteName>Default Web Site</SiteName>
    </IISApp>
Thist results in a dirty entry in IIS which also shows the entire drive below(!) my solution folder.
When I use only 'ServiceName' as Virtual Path, the output is clean as expected. See also this picture.

Image
Link to Image

The output in the build window is always the same, however:
Target DeployIISApplications:
    Creating IIS application '<vdir>'...
    Created/updated IIS application '<vdir>'.
Can anyone point me to a solution on this?

Thanks!
Charles
Coordinator
Dec 23, 2014 at 3:38 AM
Hi Charles,

In a multi-level directory hierarchy such as ServiceDIrectory/ServiceName/1.0, a virtual directory must be set up for ServiceDirectory and ServiceName and 1.0. In addition, an application must be overlaid on 1.0. Those virtual directories are required to have paths.

To accomplish that, the virtual directory deployment process assumes that the physical path contains at least as many path segments as the virtual path. For example, if the virtual path is /My/App the physical path must also have at least two segments, like ..\My\App or C:\My\App, but ..\Its\My\App is also OK because it has more than the minimum. The process has quite a bit of logic to automatically "do the right thing," so this is a bit of a trade-off to make things as simple as they are in the configuration XML.

If you modify your PhysicalPath to ..\Services\ServiceName\1.0 to match ServiceDirectory/ServiceName/1.0 (the names aren't important), you'll see the behavior that you expect.

Thanks,
Tom