One pain point that keeps recurring for me and several other users is working with projects and files by recursing the dte:/solution/projects node.  Since this node contains all projects and file items, as well as the code model for each file, recursion generally takes a gignormous amount of time.

I'd like to remove the code model from dte:/solution/projects/<projectname>/<filename>/codemodel/ and isolate it somewhere else in the path node tree.  This will allow project and project-item recursive ops without the pain.  And it should also make the code less cumbersome to describe in a path.

Moreover, since there are two ways to access the code model - across an entire project and within a single file - I want to expand the tree to encompass them both. 

I'd like move the project-level code model root node to dte:/codemodel/<projectname>.  The entire project code model will be available at each <projectname> node; e.g., creating a new method may look like so:

new-item -path dte:/codemodel/PoshRabbit/PoshRabbit/Extensions/ -name Create -type method -membertype 'void' 

For the file-level code model, I'd like to keep them under the dte:/solution/codemodel/<projectname>/<projectitemname>.  So the same call above could be rewritten as:

new-item -path dte:/solution/codemodel/PoshRabbit/Extensions.cs/PoshRabbit/Extensions -name Create -type method -membertype 'void'

Thoughts?

I haven't gotten into using this stuff yet, so my thought should be taken with a tsp of salt, but doesn't leaving the file-level code model in there still leave you problems with recursion? I would have thought you'd want to totally separate the codemodel from the file tree, or at least, have a file tree that has no code model ... separate from a codemodel file tree.

Actually that's exactly what I intend to do.  Lemmie 'splain some more.

There is one code model for an entire project and another for individual files.  The major difference is that the project-level code model doesn't support all operations, such as creating new namespaces or classes.  You have to turn to the file-level code model to do that.  So I'd like to include *both* code models, and I want to isolate them from project and file objects for the reasons you describe.

So here is what the relevant parts of the DTE drive will look like:

DTE:
-----/codemodel
---------------/[project code model root namespaces]
-----/solution
--------------/projects
-----------------------/[project or folder name]
------------------------------------------------/[project item file name]
------------------------------------------------/References
------------------------------------------------/Properties
--------------/codemodel
------------------------/[project name]
---------------------------------------/[project item file name]
----------------------------------------------------------------/[file code model root namespaces]

Projects and their files are isolated from the file code model (dte:/solution/projects vs dte:/solution/codemodel).  Does that make more sense?

The thing I do not like about this setup is the repeated codemodel path nodes.  Not entirely intuitive.  Wondering if I should just use the project-level code model (dte:/codemodel) and add code to make smart assumptions or accept relevant parameters when attempting to do things that code model doesn't allow.  E.g., when you attempt to create a new namespace or class, you would have to specify a file path (new or existing).