Should I bring in a project or a .dll in my VS solution?
-
Let me ask you this question - My group has WPF application, we use three custom built libraries in this WPF application. These libraries are built as separate projects and have their own Subversion repositories. (4 Subversion repositories altogether) Question - Should we be using the .dll files in our WPF solution or should we be using the projects from Subversion? and bring the entire project into Visual Studio? Keep in mind our WPF application isn't the only application that uses these 3 libraries, we have other solutions that use these libraries. We are bringing in the library projects because we frequently modify these libraries when working on our WPF app. ***Here is my concern - we are now moving to TFS from Subversion and TFS has, whats called, TFS projects. Should we be creating 4 different TFS projects, one for each Subversion repository or should we be putting all projects into one TFS project? In TFS you have to create work items for each TFS project so if we have a user story that might need modification of both the WPF app and a library, if the library is its own TFS project, then we will have to create work items in 2 different TFS projects. And that seems redundant/annoying/not efficient.
-
Let me ask you this question - My group has WPF application, we use three custom built libraries in this WPF application. These libraries are built as separate projects and have their own Subversion repositories. (4 Subversion repositories altogether) Question - Should we be using the .dll files in our WPF solution or should we be using the projects from Subversion? and bring the entire project into Visual Studio? Keep in mind our WPF application isn't the only application that uses these 3 libraries, we have other solutions that use these libraries. We are bringing in the library projects because we frequently modify these libraries when working on our WPF app. ***Here is my concern - we are now moving to TFS from Subversion and TFS has, whats called, TFS projects. Should we be creating 4 different TFS projects, one for each Subversion repository or should we be putting all projects into one TFS project? In TFS you have to create work items for each TFS project so if we have a user story that might need modification of both the WPF app and a library, if the library is its own TFS project, then we will have to create work items in 2 different TFS projects. And that seems redundant/annoying/not efficient.
As with many things, it depends... We do the same thing a lot where I work. Sometimes we reference a DLL, sometimes we share the project, sometimes we copy the project and reverse integrate the changes. Referencing a DLL is the safest answer. You always know what version you are running against and upgrade it when you decide to (Test can run full test passes and make sure nothing broke by doing so). Sharing a project is very dangerous and is rarely used. If you change an interface in project B, project A probably will no longer compile. Making a copy of the project and reverse integrating changes is one of the best solutions. It allows bugs to be fixed from both sides of the project and each side gets to decide whether or not to integrate those fixes. This even has the added benefit of allowing you to heavily modify some things (Interfaces, Classes ect) that would otherwise break the other project while still being able to take some bug fix type integration back. I'm getting tired so hopefully that makes sense.
The best way to accelerate a Macintosh is at 9.8m/sec² - Marcus Dolengo
-
As with many things, it depends... We do the same thing a lot where I work. Sometimes we reference a DLL, sometimes we share the project, sometimes we copy the project and reverse integrate the changes. Referencing a DLL is the safest answer. You always know what version you are running against and upgrade it when you decide to (Test can run full test passes and make sure nothing broke by doing so). Sharing a project is very dangerous and is rarely used. If you change an interface in project B, project A probably will no longer compile. Making a copy of the project and reverse integrating changes is one of the best solutions. It allows bugs to be fixed from both sides of the project and each side gets to decide whether or not to integrate those fixes. This even has the added benefit of allowing you to heavily modify some things (Interfaces, Classes ect) that would otherwise break the other project while still being able to take some bug fix type integration back. I'm getting tired so hopefully that makes sense.
The best way to accelerate a Macintosh is at 9.8m/sec² - Marcus Dolengo
"Sharing a project is very dangerous and is rarely used. If you change an interface in project B, project A probably will no longer compile." you shouldn't be changing anything from interfaces (adding stuff is ok). Isn't that what the purpose of an interface is???
-
"Sharing a project is very dangerous and is rarely used. If you change an interface in project B, project A probably will no longer compile." you shouldn't be changing anything from interfaces (adding stuff is ok). Isn't that what the purpose of an interface is???
It is. It was meant to serve as an example, albeit a bad one. Changing a hash function is something I have seen done in this scenario. The havoc this wreaks is... absolutely terrible. I don't even want to get into the details but knowing that this was the cause of the problem, FROM ANOTHER FREAKING PROJECT was angering to say the least.
The best way to accelerate a Macintosh is at 9.8m/sec² - Marcus Dolengo
-
It is. It was meant to serve as an example, albeit a bad one. Changing a hash function is something I have seen done in this scenario. The havoc this wreaks is... absolutely terrible. I don't even want to get into the details but knowing that this was the cause of the problem, FROM ANOTHER FREAKING PROJECT was angering to say the least.
The best way to accelerate a Macintosh is at 9.8m/sec² - Marcus Dolengo
Ok understood. Does anyone know, or can tell me how a project in TFS is structured? Do I create and put VS projects (dll, WPF, asp, etc) in a single TFS project and seperate them by folders? Or should I map a one-to-one with 1 Visual Studio project (ex. WPF) to one TFS project? In my TFS book it shows "product families" as a folder in a TFS project. I assume this means a VS project???
-
Ok understood. Does anyone know, or can tell me how a project in TFS is structured? Do I create and put VS projects (dll, WPF, asp, etc) in a single TFS project and seperate them by folders? Or should I map a one-to-one with 1 Visual Studio project (ex. WPF) to one TFS project? In my TFS book it shows "product families" as a folder in a TFS project. I assume this means a VS project???
A TFS project is not analogous to anything in Visual Studio. It is more for permissions and work item types. For most people/teams they will work out of the same TFS Project. I've never strayed out of my TFS Project. We just have different folders for each Visual Studio Project. External teams have a different folder for their team still within our same TFS Project. The only time I've seen people use other TFS Projects is when they have a different permission model, or different work item types they are tracking against.
The best way to accelerate a Macintosh is at 9.8m/sec² - Marcus Dolengo
-
Let me ask you this question - My group has WPF application, we use three custom built libraries in this WPF application. These libraries are built as separate projects and have their own Subversion repositories. (4 Subversion repositories altogether) Question - Should we be using the .dll files in our WPF solution or should we be using the projects from Subversion? and bring the entire project into Visual Studio? Keep in mind our WPF application isn't the only application that uses these 3 libraries, we have other solutions that use these libraries. We are bringing in the library projects because we frequently modify these libraries when working on our WPF app. ***Here is my concern - we are now moving to TFS from Subversion and TFS has, whats called, TFS projects. Should we be creating 4 different TFS projects, one for each Subversion repository or should we be putting all projects into one TFS project? In TFS you have to create work items for each TFS project so if we have a user story that might need modification of both the WPF app and a library, if the library is its own TFS project, then we will have to create work items in 2 different TFS projects. And that seems redundant/annoying/not efficient.
Reference the unless you plan to modify any of the projects.
WP7.5 Apps - XKCD | Calvin | SMBC | Sound Meter | Speed Dial
-
A TFS project is not analogous to anything in Visual Studio. It is more for permissions and work item types. For most people/teams they will work out of the same TFS Project. I've never strayed out of my TFS Project. We just have different folders for each Visual Studio Project. External teams have a different folder for their team still within our same TFS Project. The only time I've seen people use other TFS Projects is when they have a different permission model, or different work item types they are tracking against.
The best way to accelerate a Macintosh is at 9.8m/sec² - Marcus Dolengo
OH! so you just keep one TFS project for all your applications? And separate them by folder in your TFS project. :) Does everyone agree with this?
-
Let me ask you this question - My group has WPF application, we use three custom built libraries in this WPF application. These libraries are built as separate projects and have their own Subversion repositories. (4 Subversion repositories altogether) Question - Should we be using the .dll files in our WPF solution or should we be using the projects from Subversion? and bring the entire project into Visual Studio? Keep in mind our WPF application isn't the only application that uses these 3 libraries, we have other solutions that use these libraries. We are bringing in the library projects because we frequently modify these libraries when working on our WPF app. ***Here is my concern - we are now moving to TFS from Subversion and TFS has, whats called, TFS projects. Should we be creating 4 different TFS projects, one for each Subversion repository or should we be putting all projects into one TFS project? In TFS you have to create work items for each TFS project so if we have a user story that might need modification of both the WPF app and a library, if the library is its own TFS project, then we will have to create work items in 2 different TFS projects. And that seems redundant/annoying/not efficient.
chuckdawit wrote:
Keep in mind our WPF application isn't the only application that uses these 3 libraries, we have other solutions that use these libraries.
I think this here is what defines it. If these projects are used by more than just one solution, it is usually a good idea to keep them independent. As for your TFS question, I think the other option you are missing is creating 1 independent Team Project for all these libraries so as for them to remain completely independent from the projects that are using them. As always the devil is in the details and it will depend, among other things, in how these libraries are connected to one another.