none
multiple developers debugging on different web apps on single server RRS feed

  • Question

  • How can we allow multiple 5/6 developers work on single SharePoint solution and allow them debug a site without causing issues. Right now we are having performance issues with developers debugging a single web app. If we create multiple web apps then also unless dev checksin his code his code will be overwritten by other.

    Can we have 6 boxes for 6 developers? Is it fiasible?


    MCTS Sharepoint 2010, MCAD dotnet, MCPDEA, SharePoint Lead

    Wednesday, December 11, 2013 5:18 PM

Answers

  • Create 1 web application for each developer and set the Visual Studio property "Assembly Deployment Target" to "Web Application" instead of "GlobalAssemplyCache"

    In this case, the DLLs will be deployed to the BIN folder of the WEB APPLICATION and not to the GAC, therefore the developers will not suffer with conflicts anymore.

    When you have a final solution, just change the setting "Assembly Deployment Target" from "Web Application" to "GlobalAssemblyCache" back.



    Rafael Nunes SharePoint Dev & Admin - MCTS (SP2010)

    Remark: This won't avoid everyone freezing when someone does a deployment, because of the IIS restart. But at least they won't suffer with code conflicts anymore.
    Friday, December 13, 2013 1:00 PM

All replies

  • This isn't a great idea, developers can block other developers depending on what they're working on.

    At the very least, make sure each Web Application is using its own application pool. If you start needing to debug the timer service, service applications, or the SecurityTokenService, I'd strongly suggest one farm per developer.


    Trevor Seward, MCC

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Wednesday, December 11, 2013 6:14 PM
    Moderator
  • Thanks Trevor!

    We created 6 web apps for 6 developers on single server but the issue is when they work on single solution the gac dll of one developer gets overwritten by other developer local changes. Until they are not checkin the code till that time its a problem for others.

    one farm per developer is issue for us as we can pu a person to integrate lists, workflows on each of those machines.

    I have seen one option where auto retract on debugging can be unchecked. So if one developer starts debug in his web app will that oevrwrite other developer's changes in his web app as although they are using local folders to checkout the assembly name and solution is same for all developers.


    MCTS Sharepoint 2010, MCAD dotnet, MCPDEA, SharePoint Lead

    Wednesday, December 11, 2013 7:37 PM
  • Yep, no way to avoid deploying to the GAC and no real way to avoid recycling all of the app pools when deploying to the GAC. You could deploy to the App Bin folder, but that requires you to use Code Access Security, which is complicated to implement.

    I'd suggest one farm per dev.


    Trevor Seward, MCC

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    • Proposed as answer by Amr FouadMVP Wednesday, December 11, 2013 8:14 PM
    Wednesday, December 11, 2013 7:44 PM
    Moderator
  • The best solution is to create a VM for each developer, backup and restore the site collection on all Farms (each VM) and then they have the same exact environment to develop on. 

    Rafael Nunes SharePoint Dev & Admin - MCTS (SP2010)

    Wednesday, December 11, 2013 8:00 PM
  • can we use intepub app bin folder to deploy same solution but on 6 different web apps given to 6 developers and then can just click on debug and all their local solution changes will get deployed to only assigned web app? and they can debug it without overwriting other's 

    MCTS Sharepoint 2010, MCAD dotnet, MCPDEA, SharePoint Lead

    Wednesday, December 11, 2013 11:46 PM
  • If you deploy to App Bin folder (which requires you to set up a CAS Policy), correct it will only impact that specific web app. If each developer has their own web app, they will not overwrite each others deployments.

    Trevor Seward, MCC

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Wednesday, December 11, 2013 11:52 PM
    Moderator
  • So suppose we have 12 developers it means we create 12 separate Sharepoint 2013 instances, spend time in configuring workflow manager 12 times, SSO(invloved in this project), and lists etc. and plus cost of adding these instances! wow! Project is of 6 weeks and this infra will take 2/3 weeks for us so not possible and looking at deploying 6 web apps(2 servers so 12 webapps) and bin folder deployment using CAS policy.

    MCTS Sharepoint 2010, MCAD dotnet, MCPDEA, SharePoint Lead

    Thursday, December 12, 2013 11:32 AM
  • That is the norm in the industry. Scripted deployments can make that much less painful as does using backup-restore to make sure that the environments are similar.

    If you're using VMs then, as long as they were isolated, you could just create one copy and then duplicate it for each of your Developers. Then it's one off configuration effort and a copy+paste.

    Thursday, December 12, 2013 12:57 PM
  • Create 1 web application for each developer and set the Visual Studio property "Assembly Deployment Target" to "Web Application" instead of "GlobalAssemplyCache"

    In this case, the DLLs will be deployed to the BIN folder of the WEB APPLICATION and not to the GAC, therefore the developers will not suffer with conflicts anymore.

    When you have a final solution, just change the setting "Assembly Deployment Target" from "Web Application" to "GlobalAssemblyCache" back.



    Rafael Nunes SharePoint Dev & Admin - MCTS (SP2010)

    Remark: This won't avoid everyone freezing when someone does a deployment, because of the IIS restart. But at least they won't suffer with code conflicts anymore.
    Friday, December 13, 2013 1:00 PM
  • Cool Rafael! Thats what we will be trying next week! Thanks!

    I think bin approach is going to work!


    MCTS Sharepoint 2010, MCAD dotnet, MCPDEA, SharePoint Lead


    Friday, December 13, 2013 10:44 PM
  • All developers should sign in by FarmAdmin user?

    Or one user name for each developer and set it as farm admin?

    Tuesday, January 19, 2016 9:32 AM
  • The latter option. Even when you've just got one developer on an instance they should not be running as the farm account, it's bad practice.
    Tuesday, January 19, 2016 1:04 PM