多个开发人员在单个服务器上测试 Sharepoint 部署
我们由三人团队开始 Sharepoint 开发，目前正在设置我们的开发环境。 我们希望避免为每个开发人员安装一个 Server 2008，因此设置了一个终端服务器，使用远程 Windows 在每个开发人员的计算机上启动一个 VS2008 实例。 现在，我们希望分离开发人员的测试环境（即每个开发人员的不同站点集合），但意识到需要将程序集安装到 GAC 中才能在站点上正确显示。 但由于据我所知只有一个 GAC，开发人员将无法独立测试他们的东西。
有没有什么方法可以让我们创建单独的测试环境而无需安装一堆 2008 服务器？
We are starting with Sharepoint development with a team of three and are currently setting up our development environments. We would like to avoid installing a Server 2008 for each developer, thus a single terminal server has been setup, using Remote Windows to start a VS2008 instance on each developer's machine. Now we would like to separate developers' testing environments (i.e. a different site colletion per developer), but have realized that the assemblies would need to be installed into GAC to show properly on the site. But since there is AFAIK only one GAC, developers wouldn't be able to test their stuff independently.
Is there any way we could create separate testing environments without installing a bunch of 2008 Servers?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
贡献者是对的，多开发人员单服务器环境存在很多障碍。
第一个开发人员将尝试附加到同一个 Web 应用程序进程 w2ps.exe，因此必须在不同端口上创建单独的 Web 应用程序，除非您准备好共享时间调试。 如何为 sharepoint 2013 设置开发环境< /a>
第二个问题是当您尝试协作并使用共享组件/功能时。 是否希望单独工作是值得商榷的，我认为团队开发人员应该协作和共享，因此需要组合工作以确保无缝集成到单个最终解决方案中，并且不会重复工作。 多开发人员单服务器环境可以完美运行，直到您尝试协作。“一个常见的错误是所有团队开发人员都使用一台“开发服务器”。 除非团队成员正在处理完全不相关的组件，并且不需要执行常见的操作（例如重新启动 IIS 或将调试器附加到 IIS 进程），否则这种类型的环境通常无法正常工作。 http://technet.microsoft.com/en-us/magazine/dn145990。 aspx 我们由于缺乏经验和知识而犯了这个错误，但是一旦你犯了这个错误，就可以解决它。
我第一次尝试共享功能是将开发人员 1 的项目复制到开发人员 2 的解决方案中，并在开发人员 2 的项目中添加对其的引用，并将所有功能添加到开发人员 2 的包中。 部署此功能对于开发人员 2 来说效果很好，直到我发现如果开发人员 1 将其解决方案与调试器分离，它会根据场中的重复解决方案 ID 撤回解决方案，从而从每个开发人员的 Web 应用程序中撤回该解决方案。 因此，开发人员 2 将地毯从他们下面拉出。 虽然这是一个部分解决方案并且似乎工作了一段时间，但我花了一段时间才弄清楚发生了什么以及开发 1 和 2 部署的哪些组合使彼此工作和不工作。
所以我找到了更好的解决方案。 在 Visual Studio 的项目属性下的 SharePoint 选项卡下，有一个名为“调试后自动收回”的组合框。 默认情况下，当开发人员停止附加的调试器并从其他开发人员下面提取功能时，这会收回解决方案。 取消勾选此框可防止撤回，并使每个开发人员在场级别部署单独的解决方案，并且在重新连接到调试器时只需以最小的麻烦替换该解决方案。
根据我的经验，回收 IIS 应用程序池的速度非常快，其他开发人员甚至都没有注意到，但对于超过 2 人的团队，这种情况可能会变得更加普遍，因此也许其他人可以添加他们的经验。 我还猜想，除非其他开发人员尝试在回收发生的同一时间附加，否则会很好，因此随着时间的推移发生交叉的可能性很小，并且简单地分离和重新附加将解决此问题（如果是）曾经经历过。
The contributors are right that there are lots of stumbling blocks to multi-developer single server environments.
Number one developers will be trying to attach to the same Web Application process w2ps.exe so creating separate Web Applications on different ports is a must unless you are prepared to share time debugging. How to setup a development environment for sharepoint 2013
The second problem is when you try to collaborate and use shared components/features. Having a desire to work separately is debatable, I believe that the team developers should be collaborating and sharing so combing work is desirable to ensure seamless integration into a single final solution and that no work is duplicated. The multi-developer single server environment works perfectly until you try to collaborate 'One common mistake is to have one “development server” used by all team developers. Unless team members are working on totally unrelated components and never need to do common things such as restart IIS or attach a debugger to an IIS process, this type of environment generally doesn’t work well.' http://technet.microsoft.com/en-us/magazine/dn145990.aspx We made this mistake through lack of experience and knowledge, but once you make it it's possible to work round it.
My first attempt to share features was to copy developer 1's project into developer 2's solution and add a reference to it in developer’s 2's project and add all the features to developer 2's package. Deploying this works fine for developer 2, until as I discovered if developer 1 detaches their solution from the debugger it retracts the solution based on the duplicated solution id from the farm and therefore from each developer's web application. Therefore developer 2 has the rug pulled out from underneath them. Although this is a part solution and seemed to work for a while, it took me a while to work out what was happening and what combinations of dev 1 and 2 deployments make each other’s work and not work.
So I found a better solution. Under the project properties in Visual Studio under SharePoint tab there is a combo box called 'Auto-retract after debugging'. This by default retracts the solution when the developer stops the attached debugger and pulls the features out from underneath the other developers. Unticking this box prevents the retract and leaves each developers individual solutions deployed at farm level and on reattaching to the debugger just replaces the solution with minimal fuss.
In my experience recycling the IIS application pool is so fast other developers don't even notice, but with a larger team than 2 this might become more prevalent, so perhaps someone else could add their experiences. I also guess unless the other develops try to attach at exactly the same time that the recycle is happening it'll be fine, so is a really small chance of having a cross over time, and simply detaching and reattaching will fix this if it is ever experienced.
那么你们都将在启动 Visual Studio 中远程并编译内容并重新启动 IIS 等吗？
你们会互相跺脚。
如今，更明智的选择是使用 Hyper-V（或其他虚拟化）。
我们在笔记本电脑上使用 Windows Server 2008，并使用 Hyper-V 来运行我们的开发环境。 然后，我们各有一个开发环境（沙箱），其中有 VS2008、SVN、Nunit 等。
借助唯一共享 Hyper-V 上的 CruiseControl，我们的代码可以相互测试。
这对我们来说非常好......我们分配负载，我们可以在移动中工作，我们不会踩到彼此的脚趾，如果我们需要进行演示，我们可以从演示 Hyper 切换 Hyper-V 和演示-V（早期从开发分支分支，以便了解环境）。
走向虚拟，不要回头。
PS：我刚刚看到您对一台服务器的评论...只需在其上安装 Hyper-V 并运行 3 个实例即可。 这也是我们所做的；）
So you're all going to remote in an fire up Visual Studio and be compiling stuff and restarting IIS, etc?
You're going to be stamping on each other's toes.
A wiser choice nowadays is to use Hyper-V (or some other virtualisation).
We use Windows Server 2008 on our laptops, and use Hyper-V to run our dev environments. We then have a dev environment (sandbox) each, and these have VS2008, SVN, Nunit, etc.
Our code is tested against each other thanks to CruiseControl on the only shared Hyper-V.
This has been great for us... we distribute the load, we can work on the move, we don't step on each others toes and if we need to do a demo we can switch Hyper-Vs and demo from the demo Hyper-V (branched from the dev one early on so that the environments are known).
Go virtual and don't look back.
PS: I've just seen your comment about one server... just put Hyper-V on that and run 3 instances. That's also what we do ;)
我不知道如何在所有设备上安装服务器，但这听起来像是虚拟机而不是物理机的理想任务 - 在我工作的地方，我们经常使用 VMWare 来完成此类工作，而且效果非常好。
在测试安装过程等方面，能够回滚到快照也很有用。
I don't know about installing the server on everything, but this sounds like an ideal task for Virtual Machines rather than physical ones- where I work we using VMWare a whole lot for this kind of work and it does very well.
It's also useful to be able to roll back to a snapshot when it comes to testing installation processes and so on.
不。除了 GAC 之外，12 个配置单元中还有所有 SharePoint 文件，例如功能和网站模板。 您节省的服务器成本不值得。
（当然，如果你不使用GAC，而是部署到bin文件夹，并且你不接触12个hive中的任何内容，你可以在同一台服务器上为每个开发人员提供他们自己的Web应用程序。但是这种方法会带来他们的功能受到很多限制，这仍然不值得。）
虚拟机可以工作，但开发速度可能很慢。 例如，您需要为每个 GAC 部署重新启动应用程序池 - 这意味着可能需要暂停 15-60 秒来重新加载应用程序（取决于硬件）。 这会变得很烦人。
虚拟机更适合测试和生产，您不必经常重新启动应用程序。
我为每个开发人员推荐一台物理服务器。 这将最大限度地减少代码-部署-测试周期时间，并确保他们不必担心踩到彼此的脚趾。
No. In addition to the GAC there are all the SharePoint files in the 12 hive, such as features and site templates. It's not worth what you save on server costs.
(Of course if you don't use the GAC, but deploy to the bin folder, and you don't touch anything in the 12 hive, you can give each developer their own web application on the same server. But this approach puts a lot of restrictions on what they can do. It's still not worth it.)
Virtual machines will work, but they can be slow to develop on. For instance, you'll need to restart the application pool for every GAC deploy - which means a pause of maybe 15-60 seconds to reload the application, (depending on the hardware). This will become annoying.
Virtual machines work better for test and production, where you don't restart the application so often.
I recommend a physical server for each developer. This will minimize the code-deploy-test cycle time, and make sure they don't have to worry about stepping on each others toes.
您在终端服务上走错了路——它不会给您带来任何分离。
很多人确实建议直接在W003/2008服务器上进行开发，并且它确实简化了一些事情，例如远程调试。
我更喜欢使用 VMWare 运行虚拟机的更传统方法。 它们可以在本地或远程主机上运行。 远程调试的设置稍微复杂一些，但仍然是可能的。
最后 - 如果可能的话，部署到 bin 目录而不是 GAC。 这将使编译后自动部署变得更加容易。
You are on the wrong track with Terminal Services - its just not going to give you any separation.
A lot of people do recommend developing on W003/2008 server directly, and it does simplify some things like remote debugging.
I prefer the more traditional method of using VMWare to run virtual machines. These can be running on a local or remote host. Remote debugging is a little more complex to setup but still possible.
Finally - if possible then deploy to the bin dir rather than the GAC. This will make it much easier to deploy automatically after compilation.