Comments on: Mono Package and Deployment Framework http://zbowling.com/blog/2005/02/26/mono-package-and-deployment-framework/ Human Code Generator Fri, 05 Sep 2008 17:00:42 +0000 http://wordpress.org/?v=2.6.1 By: 9447976b5b7c http://zbowling.com/blog/2005/02/26/mono-package-and-deployment-framework/#comment-26284 9447976b5b7c Thu, 15 May 2008 17:02:40 +0000 http://zacbowling.com/archives/2005/02/26/mono-package-and-deployment-framework/#comment-26284 <strong>9447976b5b7c...</strong> 9447976b5b7cd51a7b10... 9447976b5b7c…

9447976b5b7cd51a7b10…

]]> By: Idetrorce http://zbowling.com/blog/2005/02/26/mono-package-and-deployment-framework/#comment-25792 Idetrorce Sat, 15 Dec 2007 13:10:03 +0000 http://zacbowling.com/archives/2005/02/26/mono-package-and-deployment-framework/#comment-25792 very interesting, but I don't agree with you Idetrorce very interesting, but I don’t agree with you
Idetrorce

]]> By: Scott Willeke http://zbowling.com/blog/2005/02/26/mono-package-and-deployment-framework/#comment-171 Scott Willeke Sun, 13 Mar 2005 08:39:04 +0000 http://zacbowling.com/archives/2005/02/26/mono-package-and-deployment-framework/#comment-171 You should also consider usage scenarios for deploying development components & tools, and application plug-ins/extensions. I work for a .NET component vendor and actively work with MS related to deployment & versioning challenges we face. Some examples of challenging deployment considerations we face as a component vendor are as follows: * GAC policy (should the assembly be GAC'd or not) * Publisher policy * Help files & IDE Help Integration * Samples locations * IIS Virtual Folders * IIS/ASP.NET HttpHandlers registration & IIS file extension registration * IDE Registration in the "References Dialog" * IDE Toolbox Integration (and *not* have it deleted the next time somebody installs a visual studio package that "resets (see devenv /setup)" the environment) * IDE Package Integration (for tighter integration with the IDE for things like language services, visual designers, etc...) * Support URL * Version update URL Obviously we have overcome these items, but they are remarkably challenging and seem like relatively basic deployment scenarios. Also consider a configuration tool that could be used to explore installed components, launch samples, add/remove toolbox items, integrate packages, view help, check for updates, etc... Plug-in scenarios like Mozilla's Firefox and Thunderbird extensions should also be considered. Make sure the deployment file can be signed with digital signatures (more on digital signing: http://blogs.pingpoet.com/overflow/archive/2005/03/13.aspx). Anyway, I think you're onto something and I hope to see something come of this. You should also consider usage scenarios for deploying development components & tools, and application plug-ins/extensions. I work for a .NET component vendor and actively work with MS related to deployment & versioning challenges we face. Some examples of challenging deployment considerations we face as a component vendor are as follows:

* GAC policy (should the assembly be GAC’d or not)
* Publisher policy
* Help files & IDE Help Integration
* Samples locations
* IIS Virtual Folders
* IIS/ASP.NET HttpHandlers registration & IIS file extension registration
* IDE Registration in the “References Dialog”
* IDE Toolbox Integration (and *not* have it deleted the next time somebody installs a visual studio package that “resets (see devenv /setup)” the environment)
* IDE Package Integration (for tighter integration with the IDE for things like language services, visual designers, etc…)
* Support URL
* Version update URL

Obviously we have overcome these items, but they are remarkably challenging and seem like relatively basic deployment scenarios. Also consider a configuration tool that could be used to explore installed components, launch samples, add/remove toolbox items, integrate packages, view help, check for updates, etc…

Plug-in scenarios like Mozilla’s Firefox and Thunderbird extensions should also be considered. Make sure the deployment file can be signed with digital signatures (more on digital signing: http://blogs.pingpoet.com/overflow/archive/2005/03/13.aspx). Anyway, I think you’re onto something and I hope to see something come of this.

]]> By: Scooter's Musings http://zbowling.com/blog/2005/02/26/mono-package-and-deployment-framework/#comment-160 Scooter's Musings Thu, 03 Mar 2005 17:41:01 +0000 http://zacbowling.com/archives/2005/02/26/mono-package-and-deployment-framework/#comment-160 <strong>Great Night of .NET/Mono</strong> Great Night of .NET/Mono

]]> By: A.Nahr http://zbowling.com/blog/2005/02/26/mono-package-and-deployment-framework/#comment-153 A.Nahr Sun, 27 Feb 2005 10:00:59 +0000 http://zacbowling.com/archives/2005/02/26/mono-package-and-deployment-framework/#comment-153 .Net automatically packages an Application into a PE file, so I don't understand why using an additional packaging - mechanism should make any sense. Surely using PE as package format isn't as simple as using e.g. ZIP files, however it also provides advantages over more simpler formats (like the ability to digially sign the resulting package, add metadata). I agree that for a centralized deployment you need some sort of externalized information-set so the user doesn't need to download the entire package to do any checks. .Net automatically packages an Application into a PE file, so I don’t understand why using an additional packaging - mechanism should make any sense.
Surely using PE as package format isn’t as simple as using e.g. ZIP files, however it also provides advantages over more simpler formats (like the ability to digially sign the resulting package, add metadata).
I agree that for a centralized deployment you need some sort of externalized information-set so the user doesn’t need to download the entire package to do any checks.

]]>