none
What technical drawbacks are there to referencing a win app proj from another? RRS feed

  • Question

  • Another developer on our team is working on a project that contains the following aspects:

    1. We have a full LOB Winforms application written in vb.net. The VS solution currently contains only a Windows Application project.

    2. Recently another group has provided a separate VS solution that contains a C# Windows Application project and a Class Library project.

    3. We need to merge our existing application with all of the functionality and components of this new C# solution in an "as is" fashion, meaning that initially the code will not be modified. Also, the driving .exe will continue to be the Windows Application project mentioned in point (1) above. All that is really needed are the functional logic classes/Forms to be references and instantiated form the main Windows Application project as mentioned in point (1).

    Here is were the discussion begins:

    Question:

    In the .net world we can bring in the existing project references of these two new C# projects as mentioned in point (2) above. Which changes our solution to now contain two Windows Application projects and one C# Class Library project. Is there any real technical problem or issue in having two Windows Application projects under the same solution? Feels kinda dirty Please Comment... My thought was to extract out the functional objects into separate class libraries and then add these as project references under our main solution.

    Please comment from a technical perspective in context with your best practices recommendations.

    Thanks!

    Saturday, July 7, 2012 3:35 PM

Answers

  • Cool. I am about to mark your replies as my answer. For the sake of overstating the concepts expressed here... Since we have already agreed that having a solution that contains project references to one or more executable (.exe) producing projects is not a problem at all. One of these executable producing projects will be marked as the startup project... The other .exe producing project will basically act as a resource just like any other project reference, such as a Class Library... Please state your agreement or objection to this summary.

    Correct.

    I think that we both agree that unless there is a requirement to keep the secondary executable producing project as a Windows Application... It should be converted into a Class Library because the entire intention behind this effort is to have only one .exe, but consume the objects and functionality that happen to exist in another Windows Application project, which in and of itself, specifically as a Winform project has no value for us... As we ONLY need the containing logic & objects... Which again are better defined in a Class Library. Please state your agreement or objection to this summary.

    Correct.

    One more thing what I want to emphasize on that - even though other Winform apps act as DLLs, they are still .exe files. But, as a good programming practice, executables shouldn't be used as DLLs. So, jus convert them to DLLs. On other hand, if those exes are still needed and you need to reference them, then take them out of the solution and establish an interprocess communication. But I guess this second part doesn't suit you, so don't worry :)

    It's 12.30am here. Time to go for bed.. If any questions, I will respond tomorrow :)


    Please mark this post as answer if it solved your problem. Happy Programming!

    • Marked as answer by jesjones Saturday, July 7, 2012 7:12 PM
    Saturday, July 7, 2012 6:50 PM

All replies

  • A Solution is just a logical container of projects. It just gives extra advantage to the user to debug 1 or more related projects by allowing the control jump from one project to another. But, during deployment, what matters is the output of the project i.e. exe or dll.

    I hope this makes sense.


    Please mark this post as answer if it solved your problem. Happy Programming!

    Saturday, July 7, 2012 4:08 PM
  • Yes, this does make sense. Your comment speaks to a related, but separate issue where our team tends to get "married" to a solution in that they try to put the referenced projects under the same file structure and TFS mapping so that it all "feels" like one unit... And when creating other/new solutions (Yes, for the purposes of building a deployable compilation such as an exe) they copy the referenced projects over to live "under" this new solution and then try to sync code changes and updates between these project copies, when they should just share the single physical project via references as needed between solutions b/c the sync between these project copies indeed needs to be 100% correct.

    However, in terms of having a solution with more than one windows application. It sounds like there are NOT any technical limitations here, correct? Do you feel that when building a Winforms solution that having only one .exe producing project reference is a "better practice" than having many? Where the other referenced projects should be supporting Class Library projects? Realizing that the overall logical organization is subjective by nature. 

    Thanks


    JesJones

    Saturday, July 7, 2012 4:58 PM
  • Yes. Having more than one Winforms projects under one solution is not at all a problem.

    However, it doesn't make sense. Because, you can see that, there can be only one active (startup) project under a solution. Since, it's an executable, one of the WinForms projects will be an Active project. Then what about other WinForms projects under that solution. They can just work like DLLs!!!

    So, whatever you are thinking is right. One executable application + optionally one or more DLLs per solution is the ideal solution.


    Please mark this post as answer if it solved your problem. Happy Programming!

    Saturday, July 7, 2012 5:58 PM
  • Cool. I am about to mark your replies as my answer. For the sake of overstating the concepts expressed here... Since we have already agreed that having a solution that contains project references to one or more executable (.exe) producing projects is not a problem at all. One of these executable producing projects will be marked as the startup project... The other .exe producing project will basically act as a resource just like any other project reference, such as a Class Library... Please state your agreement or objection to this summary.

    To close on this... I think that we both agree that unless there is a requirement to keep the secondary executable producing project as a Windows Application... It should be converted into a Class Library because the entire intention behind this effort is to have only one .exe, but consume the objects and functionality that happen to exist in another Windows Application project, which in and of itself, specifically as a Winform project has no value for us... As we ONLY need the containing logic & objects... Which again are better defined in a Class Library. Please state your agreement or objection to this summary.

    Your time is absolutely appreciated!


    JesJones

    Saturday, July 7, 2012 6:14 PM
  • Cool. I am about to mark your replies as my answer. For the sake of overstating the concepts expressed here... Since we have already agreed that having a solution that contains project references to one or more executable (.exe) producing projects is not a problem at all. One of these executable producing projects will be marked as the startup project... The other .exe producing project will basically act as a resource just like any other project reference, such as a Class Library... Please state your agreement or objection to this summary.

    Correct.

    I think that we both agree that unless there is a requirement to keep the secondary executable producing project as a Windows Application... It should be converted into a Class Library because the entire intention behind this effort is to have only one .exe, but consume the objects and functionality that happen to exist in another Windows Application project, which in and of itself, specifically as a Winform project has no value for us... As we ONLY need the containing logic & objects... Which again are better defined in a Class Library. Please state your agreement or objection to this summary.

    Correct.

    One more thing what I want to emphasize on that - even though other Winform apps act as DLLs, they are still .exe files. But, as a good programming practice, executables shouldn't be used as DLLs. So, jus convert them to DLLs. On other hand, if those exes are still needed and you need to reference them, then take them out of the solution and establish an interprocess communication. But I guess this second part doesn't suit you, so don't worry :)

    It's 12.30am here. Time to go for bed.. If any questions, I will respond tomorrow :)


    Please mark this post as answer if it solved your problem. Happy Programming!

    • Marked as answer by jesjones Saturday, July 7, 2012 7:12 PM
    Saturday, July 7, 2012 6:50 PM
  • I agree with your additional point and just as you state there is not a need/requirement to keep the additional Windows Application project defined as this type of Output Project. The correct/best practice is to convert this WinForm Project to a regular Class Library so that we produce a consumable .dll and not an .exe within our deployable set. I realize that your thoughts (and other potential readers) on this topic might consider this entire thread to be just a simple decision on defining a .net project output type, and if so... That is basically correct, this is all we are really talking about when you boil it down. However, there was some disconnect within our team when I made the suggested change as described and discussed within this thread. The additional perspective provided has been helpful.

    Thanks


    JesJones

    Saturday, July 7, 2012 7:12 PM