This project is read-only.

Microsoft.CodeAnalysis.EditorFeatures.dll dependencies

Topics: General
Apr 23, 2014 at 5:11 PM

After Roslyn was released I started to modify the compiler with some colleagues in order to get familiar with the code and with the architecture. We implemented a variation of the string quoting Anders demoed on the stage, then a new operator, then a new keyword.

When we added a new Token to the SyntaxKind enumeration for the operator, things started crashing in the IDE, but somewhat stabilized once we added a second item to the enumeration for the operation expression. We managed to finish this operator aparently without issues (luckily, it turns out).

Once we added our new Keyword to the enumeration, it kept crashing more consistently, and we quickly found out why - there's a number of assemblies (Microsoft.CodeAnalysis.EditorFeatures.dll & others) that use Roslyn but are not shipped with source, and can't quite handle the change of the enum values. SyntaxKind enumeration is public API.

We worked it out for our experiments adding the new item to the end of the enum and hacking multiple places that assume their ranges are correct.

How can this be handled? Should I not be changing this enumeration? Are you going to include the missing assemblies in the source release? Abstract this dependency so Lexer/parser can be changed to recognize new tokens/expressions? Or this is something that sadly will not be supported at all?
May 31, 2014 at 2:15 PM
Edited May 31, 2014 at 2:17 PM
I have similar experience. Can someone from Roslyn team gives us a brief explanation please?
System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.CodeAnalysis.EditorFeatures, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
Jun 5, 2014 at 4:04 PM
@ltoginiolli: At this point we are not planning on opening the source for these assemblies, though we are considering doing so at some point in the future. We are willing to do some work to try and make this code a little bit more forgiving to enable people to experiment with the compiler. However, if you are really interested in making a new language that is similar to C#, you should actually fork the source, build to a different set of binaries, use a different extension, and implement your own VS support for it. It's not practical to try and abstract away the dependency - the IDE features for C# have a deep dependency on the compiler API to do its job, and any abstraction would be equally broken by changing the compiler underneath it.

@mynkow: Did you by chance build the code from master (which is versioned at, instead of releases/build-preview? If so, this won't work, as there are API differences between the two branches.
Marked as answer by TomasMatousek on 8/3/2014 at 12:01 AM