What do you think of the new Azure packaging format?

Question

As you may know, we have released an open packaging format based on the OPC packaging protocol. This lets you open the package using your usual zip utilities, edit the contents of the package, re-pack it using your usual zip utility, and deploy to Azure. Let me know what you like and what you'd see changed in the final version.

Answer 1

You can find the documentation for the new package format here:

http://msdn.microsoft.com/en-us/library/windowsazure/jj151522

---

Ryan Wike [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.

Answer 2

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?

Answer 3

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:

1. Hashes seem unnecessary. I trust my zip tools to properly store content.
2. 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.)
3. 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.).
4. 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 [e-mail], if you want to connect offline.

Answer 4

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

Answer 5

I understand that Azure is intended to (and does) support more than just .NET apps.  Having said that, did you guys consider supporting NuGet as an alternative packaging format for the .NET community?

Answer 6

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

Answer 7

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.  

Answer 8

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?