Discussion: CreateVirtualDirectory cannot find the path specified.

[tfabraham]

KrisW[12/13/2013 6:25:21 PM] I have an msi that deployed fine in several environments, but on one server it gets this error:

Target DeployVDirs:
                ...\BizTalkDeploymentFramework.targets(1701,5): error MSB4018: The "CreateVirtualDirectory" task failed unexpectedly.\r
                ...\BizTalkDeploymentFramework.targets(1701,5): error MSB4018: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.IO.DirectoryNotFoundException: The system cannot find the path specified. (Exception from HRESULT: 0x80070003)\r

The virtual directory is supposed to go under the Default Web Site.

As far as I can tell, the physical directory is present and in the correct place, and the service account that is doing the scripted deploy has the appropriate rights to it.

This is a production server, so there is a limited amount of "trying stuff" I can do on it, and the msi doesn't have a problem deploying anywhere else.

Any ideas where to look for the source of this problem?

Thanks

[tfabraham]

tfabraham It's definitely hard to diagnose when the same MSI deploys successfully on other machines. I've been trying to get a DirectoryNotFoundException out of CreateVirtualDirectory and cannot find a case where it happens. Even if I give it a bogus physical directory path, it happily creates it anyway. You don't have a stack trace anywhere in the deploy output?

What version of the Deployment Framework are you using? What version of Windows Server (and thus IIS)? Have you overridden the IISMetabasePath property in your .btdfproj? What else is different or unique about IIS on this machine?

Here's an MSBuild project file that you can use to directly test the task (save as, say, CreateVDirTest.targets):

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <UsingTask AssemblyFile="C:\Program Files (x86)\MSBuild\DeploymentFrameworkForBizTalk\5.0\BizTalkDeploymentFramework.Tasks.dll" TaskName="CreateVirtualDirectory" />
  <UsingTask AssemblyFile="C:\Program Files (x86)\MSBuild\DeploymentFrameworkForBizTalk\5.0\BizTalkDeploymentFramework.Tasks.dll" TaskName="DeleteVirtualDirectory" />

  <Target Name="TestCreateVirtualDirectory">
    <CreateVirtualDirectory MetabasePath="IIS://localhost/w3svc/1/Root" Name="TestBTDF" Path="C:\Invalid" />
  </Target>

  <Target Name="TestDeleteVirtualDirectory">
    <DeleteVirtualDirectory MetabasePath="IIS://localhost/w3svc/1/Root" Name="TestBTDF" />
  </Target>
</Project>

Run MSBuild.exe CreateVDirTest.targets /t:TestCreateVirtualDirectory from an admin Command Prompt. You'll have to change the DLL paths to one of the installed app directories on the server.

Thanks, Tom

[tfabraham]

KrisW What version of the Deployment Framework are you using? - version 5.0

What version of Windows Server (and thus IIS)? - 2008 R2 (IIS 7)

Have you overridden the IISMetabasePath property in your .btdfproj? no - using Default Web Site

What else is different or unique about IIS on this machine? - Nothing I know of. It should be a clone of another production BizTalk server where virtual directory deployments have worked fine. I'm guessing something is different though, just trying to figure out where to look for it.

I'll give the project file a test. Thanks!

[tfabraham]

KrisW TestCreateVirtualDirectory worked fine. I put the proj file and the dll in the same folder to test it. Are there any dependent files that that the dll could be trying to access? Maybe a permissions problem?

[tfabraham]

KrisW It turned out that the root of the problem was an early (non-BTDF) version of the application was still installed on the server, but not deployed to BizTalk. Once it was removed, everything worked fine. It must have had some kind of hold on the virtual directory. The test project helped track down the problem.

Thanks for your work on this framework, and your quick answers on the discussion threads.

[tfabraham]

tfabraham You're welcome and thanks for the update. Glad to hear that you figured it out!

Tom