The work here has been done since then, it should be replaced by a notice to maintain two separate solutions for express editions users.

SLN / Project Refactoring to better support Visual C# Express developers

Goals

  • Enable easier compilation of EVEMon from VC#Express
  • Reduce "checkin churn" from csproj files that get "fixed up" to make them compatible with VC#Express
  • Fix dependency bugs in SLN files that cause C++ and C# projects to build out of order

Design

  • Check into depot Reference Assemblies*.dll files for C++ G15 project. This removes the need for a VC# developer to install VC++ or to manually move files
  • Change reference in csproj from vcproj references to binary reference pointing at the Reference Assemblies*.dll files

Results

  • VC# developers no longer need to install VC++, manually copy files, or fix up their csproj and SLN files to remove VC++ references. They just sync and compile.
  • VC# developers no longer need to perform a manual edit of CSPROJ files to restore VCPROJ references after they modify the CSPROJ (to add a C# file for instance)
  • VC++ developers need to check in their Reference Assemblies*.dll file when they check in a source code change to their CPP files
  • Bug fixed where build dependencies between VC++ and VC# projects are not set properly

Debate

  • We're an open source project so we have to provide source.
  • All source code is available in this design. It simply doesn't build all source in one SLN.
  • for a 100% c# solution we'd have to drop the relocator and the LCD support
  • Support is not dropped, we've just moved from VCPROJ references to binary references (same technique as in HowToBuildEveMon)
  • Regarding the original converation around "couldn't we do this in C#", the suggestion was not to drop these features but to instead rewrite them in C# using P/Invoke to talk to the Win32 APIs
  • Is it really that bad to just unload the C++ projects in C# Express until the two projects are turned into plugins? It's not like you have to do it repeatedly :)
  • This causes problems at checkin times because with the current design the CSPROJ binary references have to be fixed up back to their VCPROJ references
  • as soon as that VC#Express developer does a commit, this change is undone, since VC#Express will want to remove that reference
  • That's definately a problem with how the SLNs and CSPROJs are layed out today. This change would fix that.
  • it is the way it is because that's the lowest common denominator
  • This approach works much better for the lowest common denominator developer who only has VC#Express.
  • Takes 2 minutes to set up one time and then we just live with it <shrug>
  • Yes, but when you add a file to your CSPROJ, you need to jiggle it before you can check in or you've changed the VC++ reference from project to binary. However, the likelihood of the C++ code and project files needing to change is remote.