I am attempting to deploy a web application to IIS over OctopusDeploy. I have a PreDeploy script that successfully creates my site name, app-pool, and all other administrivia.
My problem is that the Tentacle service appears to be calling “InstallUtil” on all my dlls, but it is skipping my primary dll - let’s call it Host.dll. It attempts to install other libraries like Microsoft.Practices.EnterpriseLibrary.Data and Microsoft.Practices.EnterpriseLibrary.Common but it skips my Host.dll. Suffice it to say, I do not want to deploy either of these Microsoft libraries as a WebApp 
I noticed that both the EnterpriseLibrary dlls have a System.Configuration.Install referenced - is this what Tenatacle is seeking out as a convention? If so, does my WebApp need to include this? (I do this for my Windows Services I deploy through Octopus, but I haven’t changed anything in my WebApp).
Finally, what can I do to have Tentacle exclude certain dlls when it attempts to install (or does this not hurt anything)?
Thanks for the input - this is the last piece toward solving my deployment puzzle.
-Seth
I may be able to answer part of my question - The calls to “InstallUtil” are not part of the IIS deploy convention, but the Windows Service deploy convention.
The clue that I overlooked was the message in the logs that says:
Tasks will be run in the following order:
- PowerShellPreDeployScript
- XmlConfigTransforms
- XmlConfigVariables
- PowerShellDeployScript
- Installers
- IisWebSite
- PowerShellPostDeployScript
And what I’m seeing is the Installers section firing off on my 3rd-party libs. In other words, it’s a red herring. That my IIS deploy says it succeeds but doesn’t function may instead be a problem with my NuGet packaging.
Currently, I package everything at the root - all binaries mixed in with all configs. The site, when it is installed correctly, will have all the binaries in a bin directory with the configs up at the root level. I will configure my packaging to do the same and see if I get the same results.
Hi Seth,
You are correct about System.Configuration.Install. Octopus uses Mono.Cecil to scan through all .dll/.exe files looking for classes derived from the Installer class in that assembly. You’ll need to create an Installer class in the Host.dll assembly for it to be picked up by InstallUtil.
The location of your DLL’s within the package shouldn’t matter - the scan is recursive.
Paul
Ok - I have a refinement (If this should be in a new topic, please let me know and I’ll do so).
The stated conventions for IIS (here) state that I should ensure:
The site name in IIS matches the name of your NuGet package - e.g., >MyApp.Web.nupkg → IIS site named MyApp.Web
However, TeamCity (Using NuGet v1.5.21005.9019) currently packages with the following convention: [id].[version].nupkg. That is, if my nuspec file has an id of My.Cool.Site and a version of 2.1.3 then I get a file named “My.Cool.Site.2.1.3.nupkg” which no longer matches my website named “My.Cool.Site”
My two questions are:
A) Does OctopusDeploy’s convention truly require an exact match on the whole filename (up to extension) or does it ignore the version. And further - should it ignore the version?
B) Is there a way to strip off the version during a PreDeploy or anything like that? I cannot name all my packaged site versions “My.Cool.Site.nupkg” or they will not co-exist in their source directory.
Thanks for the input!
-Seth
Hi Seth,
I should correct the documentation - Octopus uses the package Id (MyApp.Web) to match IIS - the version number is ignored.
Paul
From: seth.orell
Sent: 17/10/2011 16:33
To: Paul Stovell
Subject: Re: Deploying Web Site: Convention Question [Questions]