Hi Jim,
I appreciate your passing these along. Hopefully this can be of some help in working them out now, or at least getting some fixes for SP1. I've done a little more digging.
1) (Opening multiple files). Attaching listeners to IMonitorSelectionService DocumentWindowChanged reveals significantly different behavior between VS2005 and VS2010 (I'm assuming VS2008 is behaving like 05, I attached a listener in the Package.Initialize override using the package itself as the service provider). VS2005 is quiet while multiple documents are being opened, with an activation notification on the active window at the end of the load process. VS2010 shows DocumentWindowChanged events on each file as it loads. However, the last notification is not fired for the active document after all of the docs are loaded. This would certainly explain the problem as command routing, tool window display, etc are all dependent upon a document being active, and are all the responsibility of VS itself, not the editor. VS is displaying the document in the active tab without actually activating it (you don't get a DocumentChanged notification either). I don't see how this can be anything other than a VS issue.
3 (constraint lines) and 5 (frequency and reading shape size) seem to be an issue of a shared DSL core design surface resource (brush, pen, etc) being modified and not properly restored. I've seen this in a few other cases in 2010 and have worked around the problem by introducing new resource identifiers instead of sharing the resources. Basically, then pen/brush retrieved for the resources does not correspond to the initial specifications for the resource identifier (invalid color, incorrect dashstyle, etc). I'm modifying color in some cases for modality and hover variations, but I never modify width or dash style on the fly, so I don't think I'm responsible for this one either (although, unlike the first problem, I'm reasonably sure I can work around this one). Other dashed lines (ValueType, non-identifying subtype) are rendering fine.
4) Just how do you integrate with the VS help now? I'm using the Wix35 help integration extensions, which don't work correctly.
I have a list of other VS2010 grievances if anyone is interested. Getting this working was not a stroll in the green patch formerly known as Lake Bill (a nice little park at one point in MS history). For example, dynamic menu ids in VS2010 must be separated by at least one unused menu number or all of the items from the trailing menu appear at the end of the menu with the earlier ids (cost me at least two days). Another fun one is that the ProjectItem.Document property for a ProjectItem retrieved in a code generator does not actually return the original document or provide any way to reference it (that cost me the Wednesday before Christmas).
Regarding VSIX installation
NORMA VS2010 uses a number of the VSIX install patterns. However, NORMA is itself is an extensible platform and, as such, there is no way to register all extension components in a static manifest file. Extension modules, generators, and import transforms are all registered separately outside the VS hive, as are the code generator (ORMCustomTool) and a NewFileItems entry, which is not supported by VSIX. NORMA is also designed for a command line load without the VSIDE, which doesn't work if the assembly files are not in the GAC. You could easily create a basic VSIX installation as follows:
-
Snapshot the Common7\IDE\Extensions\ORM Solutions\Natural ORM Architect\1.0 directory
-
Delete any directories and subdirectories starting with ~ (these are VS cache directories)
-
Copy C:\Program Files\ORM Solutions\ORM Architect for Visual Studio 2010\bin\ORMSolutions.ORMArchitect.Core.VS2010.dll to the root of the vsix directory (with the manifest). Use C:\Program Files (x86) on a 64-bit box.
-
In the extension.vsixmanifest file, change the 'InstalledByMsi' value to false instead of true.
-
In the Content section of the manifest file add an MefComponent tag with a value of ORMSolutions.ORMArchitect.Core.VS2010.dll
-
Zip up the directory and save it as a vsix file (I'd need to investigate if you zip the whole directory structure below Extensions or just the file itself).
This should give you a reasonable VSIX impression of NORMA with no extensions (relational, etc), generators, importers, or custom tool. It will definitely exhibit all of the problem behaviors I've mentioned here, and the isolated form might be more palatable to internal developers than the .msi.
Thanks again for forwarding these. I'd love to keep this going until we get things resolved.
-Matt