6

I currently have a program that i wrote that is divided up into 3 separate solutions.

  1. Front end (all display related stuff)
  2. Parsers (multiple (39) projects that each create a dll to parse specific data)
  3. Globals (multiple (5) projects that each create a dll that is used by projects in the parsers solution, and by the front end).

Requirements -

  • Both the Front end and Parsers require the globals dlls to exist at compile time, and used at run time.
  • The Parsers dlls are loaded at run time using assembly.LoadReference.
  • Development is: C:\projects\myProg
  • deployed location is: C:\myProg

My problem is that I have been going back and forth with issues dealing with project dependencies, where to point to for my globals dlls. Do I point to the deployed location or the developement location, and if so, release or debug?

So I started looking up the different solution types, and I'm wondering if I should set up a partitioned solution, or a multi-solution for my particular situation.

Surjit Samra
  • 4,614
  • 1
  • 26
  • 36
Jason
  • 2,147
  • 6
  • 32
  • 40
  • 4
    Any reason you are not using project references? Why are you using ` assembly.LoadReference` to load assmblies? Why do you have 39 (!) projects for the different parsers? Why 5 for globals? – Oded Dec 22 '11 at 17:00
  • an arq diagram would be a nice place to being, a solution is just a logical grouping of projects. – mcabral Dec 22 '11 at 17:02
  • This was done so that the front end was dumb about what it was parsing. If i had a new message that needed parsing, i could write a dll throw it in the directory. All i would have to do from the front end is associate a messageId with the DLL, and i was good to go. Each Dll defines different parsing for different data types. – Jason Dec 22 '11 at 17:04
  • I had to google to find some of these terms - are you using 'partitioned solution' etc in the sense of [this MS paper](http://msdn.microsoft.com/en-us/library/ee817674.aspx) ? In which case, that document is pretty explicit about which options you should prefer over which others. – AakashM Dec 22 '11 at 17:05
  • @AakashM - yes, this is what i am referencing. it probably deserves to be read a second time, but after the first i came back with option 2 and 3 both seem good. – Jason Dec 22 '11 at 17:08

4 Answers4

3

Add all the projects to a single solution.

Change any references between projects into "project references" rather than direct references to dll files. This will fix a lot of dependency issues.

If you have any "library" files that are not changed often, then you can optionally move them into a separate solution. The output of this should be "prebuilt" release dlls that you can then reference from a standard location in your main solution (the best way to do this is to add a post build step that copies the output to your development "library binaries" folder. That way, the build process is not changed, you simply add an extra step to get the files where you need them, and you remain in full control of the build process). This works well, but is a pain if you need to change these prebuilt dlls often, so it's best only used for fairly static parts of your codebase.

Finally, consider merging many of your projects into a single project/assembly. The killer on build times is not the amount of code, it's the number of assemblies - on my PC every project adds a pretty constant 3 seconds to the build time, so by merging small projects I've saved quite a bit of build time.

Jason Williams
  • 56,972
  • 11
  • 108
  • 137
  • would this be done in the manner that @rfmodulator said? how would i visually separate the parsers vs globals vs front end? – Jason Dec 22 '11 at 17:16
  • My guess is the parsers aren't very big. So you can probably do this to keep things simple and just use project references without killing your build times. The suggestion to merge is a good one, too. For example, can some related parsers be merged into a single project? (E.g. reduce 39 parser assemblies to, say, 5.) – James Johnston Dec 22 '11 at 17:19
  • @James - I most likely can combine the globals into a single assembly. Unfortunately, the parsers are not intended to be mixed. – Jason Dec 22 '11 at 17:24
  • Then I would still try putting everything in a single solution and live with the build times... how bad is the build time with everything in a single solution, anyway? – James Johnston Dec 22 '11 at 17:26
  • It's not too bad to be honest. compared to some of the other projects we have, it's like a ferrari. So back to my original comment from this answer - do i start with a blank solution as rfmodulator said, and add existing project, or do i physically move and set up a whole new directory structure? – Jason Dec 22 '11 at 17:31
  • @jason: separate code in your solution into projects. If you want to reduce the number of projects (assemblies) then use folders in your project to group related source files. – Jason Williams Dec 22 '11 at 19:44
  • @Jason Williams - I moved some stuff around, and ended up with a globals dll and a parsers dll. Both are contained in the same solution. That was easy enough. My next step is to figure out how to get to the right parsing functionality. As mentioned before, the front end doesn't know how to parse anything. It just has an association with a messageID and a dll. Any suggestion how i might bridge this now that i do not have a dll for each parser? – Jason Dec 22 '11 at 20:05
  • i should elaborate that the solution contains only 2 projects (globals and parsers – Jason Dec 22 '11 at 20:18
  • 1
    @Jason: I'd add a "discovery" mechanism to the parser classes, so you can enumerate all the parsers and ask each in turn if they recognise the message ID or dll name. That way, you should be able to "plug in" new parsers and they'll "just work". – Jason Williams Dec 23 '11 at 12:34
2

Since those 3 are all part of the same system, it will probably be easier to have a single Solution with each Project added to it.

NOTE: You do not need to move anything from their current locations.

Just create a new empty solution and do a right-click Add > Existing Project... for each project you want to be a included, they will remain where they are on disk, but will be opened together.

The current ("old") solutions will be available as well, just as they are.

Also keep in mind that if you are editing the same project in two instances of VS at the same time, it will bug you about reloading the source code when a change is made and saved.

Most importantly, having the projects in the same solution will allow you to add references between them, rather than the DLL files.

rfmodulator
  • 3,638
  • 3
  • 18
  • 22
0

why are they scattered into separate projects, Combine the Parses and globals into a single assembly. keep the UI assembly separate and as simple/small as possible.

Jason Meckley
  • 7,589
  • 1
  • 24
  • 45
  • The goal for the parsers was to be able to quickly write a new parser at some point in the field, and put it in the correct directory, and the gui would handle it. Conversely, if we were giving this to vendor who didn't support (or we didn't want to see messages), we'd pull out all the parsing dlls but the ones they needed to see. – Jason Dec 22 '11 at 17:13
  • there are better ways to handle this. but that's beyond the scope of this post. – Jason Meckley Dec 22 '11 at 17:47
  • any way to sidebar? I'm curious of your thoughts on this. – Jason Dec 22 '11 at 17:52
0

Let's say you have a good reason for having so many projects (example: different amount of parsers available for different licenses of a product).

Managing dependencies in visual studio is made easy:

  • Right click your solution node

  • Select "Project Build Order..."

Make sure that every project does not need a project beneath it in that dialog.

About "where to deploy": visual studio does it well by default. If you're in debug, it will output to the debug folder of your solution, likewise for release.

HTH.

Louis Kottmann
  • 16,268
  • 4
  • 64
  • 88
  • Funny thing is we tried setting a build order for dependecies within a solution. My .sln would appear checked out in sourcesafe (yeah, i know), but it wouldn't show that it had any changes. – Jason Dec 22 '11 at 17:11
  • You need to set Dependencies on each project of your solution through that dialog (look at the ComboBox there). – Louis Kottmann Dec 22 '11 at 17:28