2 februarie 2012 18:33
We are trying to implement the partitioned solutions approach as given on http://msdn.microsoft.com/en-us/library/bb668953.aspx
We are using TFS 2010. Following is the scenario:
1. Team A builds the core set of library projects
2. Teams B,C and D build Project Sets B, C and D , each of which reference the library projects
So basically solution B has project set b and reference to the output of library projects.
The security issue here is that these teams should not see each other's source codes or the source code of Team A.
3. Team A also occasionally opens up all the projects in one master solution.
Any suggestions on how to do above ?
- Mutat de Trevor HancockMicrosoft Employee, Moderator 3 februarie 2012 15:56 TFS VC Security Issue ultimately. I think it would do better in this forum. (From:Team Foundation Server - General)
3 februarie 2012 09:15Moderator
Thank you for your question.
I am trying to involve someone familiar with this topic to further look at this issue. There might be some time delay. Appreciate your patience.
Thank you for your understanding and support.
Cathy Kong [MSFT]
MSDN Community Support | Feedback to us
7 februarie 2012 17:58Proprietar
One solution would be to:
1. Create a directory in SourceControl for the output of the binaries for Team B,C,D.
2. Set the output directory for projects B,C,D to this directory
3. Set permissions for this directory to allow A,B,C,D to have contributors rights on the folder
4. Set permissions for all folders to allow Team A to have access
5. Set permissions for B, C, D to have access to their individual project directories only
6. Create a Solution for each of the projects that contains only the individual project
7. References for all projects will refer to the files in extra output directory created in #2
8. Setup workspaces that include the extra output directory (I assumed that you were going to allow Team A to have access to all directories since they had a SLN that contained all projects)
Trevor Hancock (Microsoft)
Please remember to "Mark As Answer" the replies that help.
- Marcat ca răspuns de Trevor HancockMicrosoft Employee, Moderator 17 februarie 2012 22:09
8 februarie 2012 21:44Keep in mind that without serious obfuscation, the sources for project A are easily "inspected" using either ILSpy or Reflector or a similar product that will reverse engineer the code from the binary files.
My blog: blog.jessehouwing.nl
29 februarie 2012 07:00
I think the solution given by Trevor is acceptable.
However as pointed out by Jesse, the scheme has to have obfuscated output of the shared libraries.
The ideal solution is of course to treat the shared libraries as completely separate and hence never require team A to open them in one solution.
But the main issue in doing that is that sometimes we need to debug them together.
We can use a symbol server to enable Visual Studio to open up the code file but then Edit-And-Continue is not available.
So the questions comes down to this:
Is it possible to enable Edit-And-Continue for the shared library project while not having it in the same solution ?
1 iunie 2012 06:56
We are facing a similar issue. Security is a top priority, what would you suggest for partitioned solutions? Is it common to include obfuscation as part of the build process on TFS or is there a better approach? The approach that Trevor mentioned is near acceptable, if we are able to monitor activity on developer machines/VMs, and even so it would be reactive, i.e. taking actions after something is comprimised rather than proactive (securing the code/dlls beforehand). I have tried digging around for articles but I guess I am looking in the wrong direction (or there is little to no information on the subject). I am relatively new to this concept and want to learn more about best practice for such situations.