Application pool version incorrect

Topics: IIS and Web Services
Feb 20, 2012 at 9:12 AM


I'm trying to configure the build to deploy a wcf service that is part of the BizTalk project I'm working on.  During deployment the target creates an app pool of the specified name if it doesn't already exist.  The problem is that I've just upgraded all the projects to .net 4.0 but the application pool created by the build is using a version of .net 2.0.  I guess it's detecting the version from the project properties somehow but why isn't it picking up the new version?

Any help would be great.

Feb 20, 2012 at 5:38 PM

You'll be able to specify the .NET version for the AppPool in the final V5.0 release.  For now, you'll want to add a custom Target named CustomPostDeployTarget in your .btdfproj and call out to AppCmd.exe using the set apppool command, managedRuntimeVersion switch.


Feb 22, 2012 at 1:50 PM

Hi Thomas,

Thanks for your response.  I had previously considered using appcmd to create the app pool before I realised the frameword already catered for that...  It hadn't occurred to me that I could set the version using appcmd.  I have done as suggested and it works a treat!  

My colleague had since read your source code comments so we had seen that you have fixed a number of issues with faced including this version issue and the multiple BAM xls files issue among others...   we're eagerly anticipating the final version 5.0 release! :)

One other thing, (sorry if this is the wrong thread I can start a new one if you'd rather?), I have configured a TFS 2010 build using your framework and it was all working fine except that I couldn't find a target to use that would fire after the build btdf msi activity.  The problem was that my build outputs were not being copied to the correct drop folder so I wanted to add a custom target that would do this for me.  I ended up hacking the WIXSetup to call a custom target called "AfterDropBuild" that I created in my .btdfproj.   I would rather not have had to hack the WIXSetup although it's not that bad because it only needs to be done once on our TFS build server.  I was confused as to why there appeared to be no alternative to the MSBUILD "AfterDropBuild" target.  Have I missed something?

Great work on this framework, I'm liking it and it's going to make deploying some of our larger solutions that have all sorts of artifacts and components a lot easier! 


Feb 23, 2012 at 6:34 AM

Thanks a lot for the positive feedback!  If you haven't already done so, there's a place to rate the project/release on the Downloads tab.

As to your question, please enter this as a feature request on the Issue Tracker tab.  The good news is that what you suggested is a really low risk change, so I can probably throw it in.