(Though we really don’t like this style of project for other reasons)
Here is our process:
0) Create a custom Nuspec file for your precompiled website
We have an entirely seperate csproj in the solution that we call ‘WebsitePostBuild’. This project is empty except for some post build steps, which do this:
a) Run a batch file that calls aspnet_compiler.exe and outputs the “build” of the website to a staging directory.
b) A second post build event that calls an msbuild script that generates the package and publishes it as an artifact to teamcity. The ms build script calls the .octopack NuGet.exe directory with the contents of the staging directory.
The msbuild script is `
<!-- insert the version number into the nuspec files, this version number is passed down to
us from the main build system in the OctoPackPackageVersion variable -->
<XmlUpdate
Prefix="ns"
Namespace="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd"
XmlFileName="$(BaseDir)$(TargetName).nuspec"
XPath="/ns:package/ns:metadata/ns:version"
Value="$(OctoPackPackageVersion)" />
<Exec WorkingDirectory="$(BaseDir)" Command="$(BaseDir)..\.octopack\NuGet.exe pack $(BaseDir)$(TargetName).nuspec" />
<ItemGroup>
<OctoPackFile Include="$(BaseDir)$(TargetName)*.nupkg" />
</ItemGroup>
<Message Text="##teamcity[publishArtifacts '@(OctoPackFile-> '%(FullPath)' )']" />
<Message Text="Finished Octpack for $(TargetName)!" />
`
It’s not as smooth as the windows services or ‘web applications’, but it works.
Is this a feature we should add to Octopus so that a checkbox appears on the package step page (“Precompile ASP.NET site”) and if checked, we’ll call aspnet_compiler after deployment?
It’s a build-time event-- before it hits Octopus. The Octopack of the precompiled website should just be alongside all the windows services and regular web app packages in the nuget server, right?
Maybe the most helpful thing would just be instructions on the website. Give people another reason to move off of that terrible project(-less) type anyway.
I realized I mangled the xml and perhaps left out some important tidbits about how we were “building” the website-- can I find your contact info somewhere to email you more detailed instructions on what I did to package up a precompiled website?
I agree the project(-less) type is less than ideal. I am working towards migrating to precompilation prior to creating the nuget package, but it is all baby steps. Not doing the compilation on the target machine currently causes our application to have problems deserializing existing session data, so I need to work out of that corner.
Even with procompilation, there will be a start up cost to compile MSIL to native. Doing the aspnet compile and then ngen at deployment time would save us these compilation costs at start up and reduce the complexity of production deployments.
So I guess while I understand and agree that having a project and deployment setup this way is not “ideal”. Having support for this type of deployment and having it perform great out of the box (or by following simple support documentation) could be a big win.
There are classes in code behind data which are stored in the session. This means they are dynamically named at compile time which differs machine to machine. If only it was dynamic per compile and this would have broken a long time ago and we wouldn’t have this mess.
Anyways not a solution I would recommend, but they do exist in the wild.
Reading over this discussion, we have added this idea to UserVoice:
Any and all comments and votes would help to see this feature added to Octopus.
We feel it would add much to the product, so get voting and commenting!