locked
Sharing code between solutions and/or projects. RRS feed

  • Question

  • I developed an app (App1) that runs on maybe 5 computers in our facility.  The solution contains two projects: one contains source code, and the other is a deployment project.  Now, I'm developing a second app (App2), and I want to use some of the classes that I created in App1.

     

    What's the "best way" to share code between the apps?  I'm considering pulling the classes I want from App1, and putting them into a class library (.dll) that App1 and App2 reference.

     

    Is there another way to organize my solutions and projects, that allows App1 and App2 to share code, but does not require me to "tear apart" App1?  Or, is the .dll the best way to go?

     

    Thanks,

    Mike

    Saturday, August 25, 2007 12:49 PM

Answers

  • The Dll would be the best way to go IMO - this is what I had to do for a large project of mine. Saves duplication of code and everything is in one central location and should there be any modifications required - you only need to do it on that one assembly.

     

    I am interested to hear other people's views on this too.

     

    Saturday, August 25, 2007 2:58 PM
  • I'd agree that the ideal approach would be to have a DLL. There isn't really another viable option really, I did think Remoting or Sockets but both approaches would create a tight coupling between the applications and in order for App2 to run you'd need to have App1 running, and it's a not quite what these technologise where developed for. 

     

    It shouldn't take that much really to move the classes across, depends on your namespaces and structure, but once you reference the DLL it's very much as though the classes in it are part of the original solution. There might an other option of course Reflection, you could from App2 load in App1's assembly and create instances of classes within it... no, no, no, I agree with ahmedilyas go with the DLL approach.

     

    There is actually another option, don't develop two applications, combine them both and just have one application with a switchboard that loads App1 or App2s forms depending on what the user wants to do.

    Saturday, August 25, 2007 3:12 PM

All replies

  • The Dll would be the best way to go IMO - this is what I had to do for a large project of mine. Saves duplication of code and everything is in one central location and should there be any modifications required - you only need to do it on that one assembly.

     

    I am interested to hear other people's views on this too.

     

    Saturday, August 25, 2007 2:58 PM
  • I'd agree that the ideal approach would be to have a DLL. There isn't really another viable option really, I did think Remoting or Sockets but both approaches would create a tight coupling between the applications and in order for App2 to run you'd need to have App1 running, and it's a not quite what these technologise where developed for. 

     

    It shouldn't take that much really to move the classes across, depends on your namespaces and structure, but once you reference the DLL it's very much as though the classes in it are part of the original solution. There might an other option of course Reflection, you could from App2 load in App1's assembly and create instances of classes within it... no, no, no, I agree with ahmedilyas go with the DLL approach.

     

    There is actually another option, don't develop two applications, combine them both and just have one application with a switchboard that loads App1 or App2s forms depending on what the user wants to do.

    Saturday, August 25, 2007 3:12 PM
  •  

    Thanks for the answers.  That's what I was hoping to hear.

     

    Mike

    Saturday, August 25, 2007 4:20 PM