Given this scenario:
We have an ASP.NET vNext web app that we build once, and then deploy to 5 separate servers running IIS.
With old ASP.NET it's pretty easy - we can publish it to a folder, then xcopy the files to each IIS server. The publish directory would just contain the views, config files, assets, and a few DLL's in the bin directory. We can clearly say "this is the best way" and not worry about much else.
With vNext, it seems like we have a few options:
We can use dnu publish to publish the web app as explained in the documentation.
dnu publish -o ../artifacts/webapp --configuration Release --no-source --runtime active
However, the resulting directory is quite big.
- For a vNext (beta 8) web app that just targets
dnx451, it's 117MB, or 37MB zipped. This seems to just be a result of so much of ASP.NET now being xcopy-deployable rather than in the GAC. - For coreclr it's much bigger with the runtime included - around 300MB or 100MB+ zipped.
It does have the upside of guaranteeing that each box will end up running the exact same software with the exact same CLR version.
Since Octopus does delta compression we can probably reduce the actual bandwidth transferred here. Or maybe OctoPack could do some smarts around de-duplication of files (there are many copies of the same files).
When developers hit F5 to run their code from VS, it isn't compiled - Roslyn interprets it on the fly. At build time, we can just package the project.json and all the source code. Then at deployment time, we can use dnu restore to have each IIS machine go and fetch all the dependencies and compile it.
Downsides:
- Risk that each box gets different dependencies
- Relies on external internet access and a third party source (nuget.org) to be available during deployment, possible security issues there
Like above, only instead of relying on NuGet.org when resolving dependencies, the Octopus server could resolve them (replacing nuget.org as the feed). I think this can by done by having Octopus replace the NuGet.config or add the feed in project.json. Downside is that it relies on the IIS boxes being able to see Octopus, and security isn't as good as option 1.
@PaulStovell It is unclear why CoreCLR/CLR ASPNET5 apps would have special consideration in OD.
Building an ASPNET5 app and publishing to a NuGet package is a core tenant of DNX/DNU. The size of the resulting package should mean little in context of the package containing an ASPNET5 app vs a MVC5-based app.
There is currently an issue with extracting/uncompressing an ASPNET5-based NuGet package due to how Calamari handles multiple nuspec files. This is an issue that effects all packages, not just ASPNET5-based packages although ASPNET-based packages bring it to the forefront.
Option 2 & 3 both have merit outside of ASPNET5 apps and C#; but implemented specifically for ASPNET5 apps, these options leave a lot of gaps as you have already mentioned.
Ultimately, besides fixing the Calamari issue -- OD should have no special considerations besides the core primitives that OD currently provides.