You can find the documentation for the new package format here:
http://msdn.microsoft.com/en-us/library/windowsazure/jj151522
http://msdn.microsoft.com/en-us/library/windowsazure/jj151532 says I have to change the ModifiedTimeUtc element when I change a file. Do I really? Why?
I've only just skimmed through the documentation and opened up a package created in the new format, so my impressions are a bit early. It's great to see movement in the direction of a more accessible package format. Thanks!
Overall impression: the format isn't particularly developer friendly. I know it's more modifiable than the old format, but OPC itself is unpleasant. More specific feedback:
- Hashes seem unnecessary. I trust my zip tools to properly store content.
- I don't understand what CreatedTimeUtc and ModifiedTimeUtc do, but it makes me nervous that they're there. (See my other response to this thread.)
- The indirection between file names and where they go is annoying (FilePath versus DataContentReference). I understand this is helpful when you need to duplicate files without storing them twice, but that should be rare, and this prevents my zip file structure from looking sensible (LocalContent\sitesroot\0\Global.asax, LocalContent\approot\startup\..., etc.).
- The existence of .rd and .rdsc files in the package is unfortunate. It would be nice to see those generated server-side.
I'm contemplating writing a cross-platform Python library to generate WA packages, but it seems like a hassle, and it seems like the things causing it to be a hassle are unnecessary.
Happy to chat more about this. Use smarx@smarx.com, if you want to connect offline.
Hey Steve, nice to see that you are trying this out!
Hashes are optional. So if you don't rehash your file and edit the package, it is still fine.
CreatedTimeUtc and ModifiedTimeUtc are file timestamps. Again, these are for informational purposes and are not required for editing the package contents.
I totally get your feedback on improving the file name indirection.
Really appreciate your feedback. Keep it coming :-)
Avilay, et. al:
How much progress have you all made on making it possible to generate the initial cspkg from a non-Windows platform, or without cspack? I notice others are starting with a "base package" created on Windows then manipulating that, but it would be great for deployment automation scenarios to be able to generate the package dynamically ourselves, on a non-Windows platform, completely from scratch without cspack.
See Cloud9's approach here: http://github.com/c9/azure-packager-node
- Edited by Glenn Scott Thursday, August 09, 2012 3:51 PM
Avilay, et. al:
How much progress have you all made on making it possible to generate the initial cspkg from a non-Windows platform, or without cspack? I notice others are starting with a "base package" created on Windows then manipulating that, but it would be great for deployment automation scenarios to be able to generate the package dynamically ourselves, on a non-Windows platform, completely from scratch without cspack.
See Cloud9's approach here: http://github.com/c9/azure-packager-node
- Edited by Glenn Scott Thursday, August 09, 2012 3:51 PM
Avilay, et. al:
How much progress have you all made on making it possible to generate the initial cspkg from a non-Windows platform, or without cspack? I notice others are starting with a "base package" created on Windows then manipulating that, but it would be great for deployment automation scenarios to be able to generate the package dynamically ourselves, on a non-Windows platform, completely from scratch without cspack.
See Cloud9's approach here: http://github.com/c9/azure-packager-node
- Edited by Glenn Scott Thursday, August 09, 2012 3:51 PM
All, I'm resurrecting this thread because I'd love to know how the cross-platform packaging support is going as described in the June 7 post.
What does "Hashes are optional" mean? Can I tell cspack not to hash the content?
When I run cspack with the /useCtpPackageFormat
option, then unzip the resulting .cspkg I see my /LocalContent directory is hashed. Are you suggesting just deleting the contents and replacing with /sitesroot and /approot as we'd expect it to be after deployment?