Not setting AppPool correctly on Virtual Directory

Topics: IIS and Web Services
Jun 3, 2009 at 1:59 PM

Firstly, outstanding piece of work gentlemen. For those of us 'confined' to an MSBuild world, no longer must we look on with envy at our Nant-shaped BizTalk colleagues. Nice one! :-)

Now to my question. I've been using the Framework for a couple of days now and I've mostly got it working for my app...mostly.

Once the process has completed I can see that the Virtual Directory for my HTTPReceive location has been setup and most of the properties are correct - all except the Application Pool.

Instead of being set to the one I had specified (this is a pre-existing AppPool) in the .btdfproj File (I'm using the new V 5.0 facility rather than the text file) I find that it is set to the DefaultAppPool instead.

I can of course change it manually, but that rather defeats the purpose of setting it in the .btdfproj file.

Here's the relevant excerpt from the .btdfproj file:

  <!-- Optionally define IIS virtual directories and associated AppPool names to be configured by the Framework -->
  <ItemGroup>
    <VDirList Include="*">
      <Vdir>COPS.ReceiveOrderRequest</Vdir>
      <Physdir>..\COPS.ReceiveOrderRequest</Physdir>
      <AppPool>COPSAppPool</AppPool>
    </VDirList>
  </ItemGroup>

I've examined the sample app and can't see any significant differences between it and what I've written. Any ideas what I'm missing?

Thanks in anticipation.

Coordinator
Jun 3, 2009 at 4:59 PM

Thanks for the positive comments, they are much appreciated!

So this must be on Windows Server 2003?  32 or 64 bit?  Does this behavior occur when you are doing a dev deploy from the IDE or a server deploy?  Does the behavior change when the app pool already exists vs when it does not exist?

Thanks,
Tom

Jun 4, 2009 at 11:16 AM

No problem guys, credit where credit is due.

You are quite correct in that I am running on Windows Server 2003 R2 32-bit. At the moment I am just doing the deploy/undeploy from the VS.NET IDE.

The existence of the App Pool doesn't seem to make a difference. I've tried deploying with it present and absent, and in both cases it just uses the DefaultAppPool.

In the case where I have first removed the App Pool I am not doing anything 'extra' in the .btdfproj file with respect to the App Pool beyond what you see in my previous post - in other words I'm not explicity creating the App Pool in the .btdfproj (because I wasn't sure if you could do that, and if you could do that how you would go about it).

Something else I've just noticied during this round of testing is that the Virtual Directory is getting left behind when I run the Undeploy process - I would have expected that to have been removed as a part of this process. Again, am I missing something here?

 

Thanks again.

Jun 9, 2009 at 11:19 AM

Tom,

I've now progressed to the Server Deployment process so I can answer a question you raised earlier.

On a Server Deploy/Undeploy the Virtual Directory and Application Pool are being created and assigned correctly but after the Undeploy has run the App Pool is being left behind while the Virtual Directory is removed correctly - even though there are no applications asssigned to it. Also, this behaviour doesn't change depending on whether the App Pool pre-exists or not.

In addition to the behaviour around the deploy/undeploy of App Pools there also seems to be some unexpected behaviour around the log4net Registry Key.

On a Server Deploy/Undeploy the registry entry that points to the log4net file is being setup correctly by the Deployment Framework but it is being left behind by the Undeploy process.

Looking through the 'DeployResults' log file for the deployment process I can see an explicit call to WriteRegValue.vbs to create the Registry entry for the .log4net config file, but looking through the log file for the undeployment process I can't see any output that suggests there was any attempt to delete it.

When the application is removed through the Control Panel the .MSI takes care of removing the .log4net file from disk but now you are left with an 'orphaned' log4net Registry entry that points to a non-existant file. I can't see a rationale for this so I am assuming this is not by design.

Thanks.

Coordinator
Jun 9, 2009 at 4:28 PM

On the App Pool, I'm sure that we do not attempt to remove it because other apps may be associated to it.  Lacking logic to check if it is unused we play it safe and leave it there.

I would have to validate and potentially fix the log4net registry key issue as well as the App Pool issue separately.

Could you please jump over to the Issue Tracker and log all of your concerns (this thread and your others) as separate issues?  That will make them much easier for me to manage.

Thanks!
Tom