您的自定义 SharePoint 程序集的代码维护策略是什么？
您如何处理现有 SharePoint 代码的改进和添加功能？
您是否将原始代码部署为功能？
您是否创建新的 feature_V2 并停用原始功能？
您发现哪些流程会导致未来出现问题？
我对 WebParts、EventHandlers 和 WorkFlows 特别感兴趣。
据我所知，微软没有留下关于更新现有代码的“最佳实践”。 （实际上，我不确定他们是否留下了“实践”，更不用说“最佳实践”了）
您可以查看有关此主题的其他问题：
如何升级-a-long-正在运行-sharepoint-workflow-已经在生产中
如何更新-spitemeventreceiver- assembly-共享点列表的版本
应该-i-keep-solutions-and- features-in-a-1-1-ratio
你的方法是什么？
我知道这个问题可能是主观的，但我觉得 SharePoint 开发的这一领域存在很大的信息差距。
谢谢你，
基思
How do you handle improvements and added functionality to your existing SharePoint code?
Did you deploy your original code as a feature?
Do you create a new feature_V2 and deactivate the original?
What processes have you found that led to problems in the future?
I am specifically interested about WebParts, EventHandlers, and WorkFlows.
From what I can find, MS did not leave a "Best Practices" around updating existing code. (Actually, I'm not sure they left a "Practice" much less a "Best Practices")
You can see other questions around this topic:
how-to-upgrade-a-long-running-sharepoint-workflow-already-in-production
how-to-update-spitemeventreceiver-assembly-version-for-a-list-in-sharepoint
should-i-keep-solutions-and-features-in-a-1-1-ratio
What is your method?
I understand this question may be subjective, but I feel there is a large information gap surrounding this area of SharePoint development.
Thank you,
Keith
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我们始终将自定义代码部署为功能和解决方案。 当需要升级现有代码时，您所要做的就是 stsadm -upgradesolution，一切都运行良好。 我不喜欢拥有 feature_v2 类型功能的想法......这使得跟踪当前版本变得极其困难。 我认为在生产环境中每个功能应该只拥有一个版本。
将版本控制留给您的源代码控制系统。
We always deploy custom code as features and solutions. When it is time to upgrade the existing code, all you have to do is stsadm -upgradesolution and everything works very nicely. I do not like the idea of having feature_v2 type features around...it makes it extremely difficult to keep track of the current version. I think you should only have one version of each feature in your production environment.
Leave the version control to your source control system.
我在一家进行大量 SharePoint 开发的商店工作。 您希望使用解决方案包按功能进行部署。 您可以随时轻松升级功能，并且需要升级解决方案包。 可以使用 WSPBuilder 从 TFS 构建服务器创建此解决方案包。 在您进行过程中，唯一剩下的就是升级解决方案并“强制”重新激活您的功能以获得该功能的新功能。
不要忘记对通过 GAC 完成的任何新代码部署进行 IIS 重置。 如果您在 12 中放入站点地图和资源等任何内容，您将需要执行 stsadm -o copyappbincontent。
如果您部署包含应用程序文件的功能，您需要在场的所有服务器上卸载应用程序。 通过放置 App_Offline.htm 每台机器上每个应用程序的根。
完成后，删除 App_Offline.htm（或重命名）即可完成。 您的网站已恢复上线。
I'm working at a shop that does a lot of SharePoint development. You want to deploy by feature with a solution package. You can easily upgrade your features as you go along and you will need to upgrade the solution package. This solution package can be created from a TFS Build server with WSPBuilder. As you along, the only thing left is to upgrade the solution and "Force" reactivate your feature to have the new feature of the feature.
Don't forget to do an IIS reset for any new code deployment that is done through the GAC. If you put anything inside like sitemaps and resources inside your 12, you will want to do a stsadm -o copyappbincontent.
If you deploy features that contain application files, you want to unload your application on ALL servers of the farm. It can easily be done by putting an App_Offline.htm at the root of every application on every machine.
When completed, remove App_Offline.htm (or rename it) and you are done. Your site is back online.