After a lot of hemming and hawing, I am now adding the concept of “workspaces” to AntlrVSIX<\/a>. By this I mean an equivalent of workspaces<\/a> that is defined in Roslyn. In AntlrVSIX, a Document<\/a> will be a source file; a Project<\/a> will be a collection of Documents; a program will be a Workspace<\/a>, a collection of Projects. Properties on a Project or Document are copied to the equivalent AntlrVSIX object as a property list.<\/p>\n<\/p>\n\n\n\n The reason for this is clear if you consider what constitutes a program for languages like C# or Java. But, Antlr has a similar issue: a grammar can be “imported” into another, and the scope of the grammar symbols is local to the project.<\/p>\n\n\n\n This required a lot of changes to AntlrVSIX, and will be released as v4.0. Although there aren’t many new features, it is a significant change nonetheless.<\/p>\n\n\n\n Note: I found that obtaining the property lists for the older csproj formats very, very slow, while <\/em>the newer format much faster<\/em><\/a>. For AntlrVSIX itself in VS 2019, it takes an additional 10 seconds if I query the property lists for the 10 projects contained in the solution. Investigating this with the profiler, I found that querying the Value of a property runs especially slow. I now only query the FullPath property and ignore the others. I’m planning on performing a lazy evaluation of EnvDTE properties for properties in general because the Microsoft code that performs the parsing and semantic analysis of build files is exceedingly slow.<\/em><\/p>\n\n\n\n –Ken<\/p>\n","protected":false},"excerpt":{"rendered":" After a lot of hemming and hawing, I am now adding the concept of “workspaces” to AntlrVSIX. By this I mean an equivalent of workspaces that is defined in Roslyn. In AntlrVSIX, a Document will be a source file; a Project will be a collection of Documents; a program will be a Workspace, a collection … <\/p>\n