Author Topic: modeling Visual Studio Solution Explorer filter folders  (Read 684 times)

eberline

  • EA User
  • **
  • Posts: 40
  • Karma: +0/-0
    • View Profile
modeling Visual Studio Solution Explorer filter folders
« on: March 06, 2018, 09:42:14 am »
What's the best way to model, and explore within EA, a hierarchy of Solution Explorer filter folders from Visual Studio?

I need to model legacy code currently arranged in solution explorer folders, filesystem folders, and C++ namespaces. The three hierarchies are not orthogonal, but not isomorphic either. Anybody have a preferred modeling pattern/practice for this?

What I've been doing is manually creating a package structure that aspires to somehow unify the C++ namespaces and solution explorer folders. C++ namespaces have packages, and if pretty much isomorphic to a solution explorer folder, I use the latter as a package alias. For a solution explorer folder not isomorphic to a C++ namespace, I make it its own package but set "Suppress Namespace". Then I import whatever C++ headers are assign to a solution explorer folder within whatever model package represents that folder (either as itself or as a C++ namespace alias). In this manner I get a model that is somewhat useful as a starting point, but only that. I generally have to manually fix various relationships, because the solution explorer folders are just this fiction not actually represented in the C++ source code that was imported.

For policy and/or institutional cultural reasons, C++ namespaces are pretty coarse-grained and historically not really encouraged. Likewise with source filesystem folders. Whether I had EA's importer assign a package per C++ namespace or per filesystem folder, either way if I just ignored the solution explorer folders entirely, the model package hierarchy would be overly flat, with enormous packages serving as dumping grounds for hundreds of elements.

For better or worse, the VS folder hierarchy does embody much of the design. Round-tripping isn't needed at this time, but being able to re-sync the model to updated source code would be great.

Any suggestions? Thanks for reading.