locked
Getting .NET (maybe native) source code tree from VSPackage RRS feed

  • Question

  • Hello!

    I'm interesting on how to get source code tree using Microsoft.RestrictedUsage.CSharp.Semantics.

    And how to use Microsoft.RestrictedUsage.CSharp.Syntax.

    It'll be good if any examples provided with helpful information.

     

    Thanks!

    Friday, December 10, 2010 5:08 PM

Answers

  • You can try using some open source stuff to help there (writing a C++ parser would be...a nightmare :)).  I hear clang is very good, Microsoft also has Phoenix which is a compiler framework but it may be a way to understand compiled code at the binary level (including native code).

    Ryan

    • Marked as answer by Victor_Chen Monday, December 20, 2010 9:39 AM
    Friday, December 10, 2010 7:50 PM

All replies

  • I don't see ANY documentation for these types on MSDN, which leads me to belive they are not intended for public use (the RestrictedUsage part of the namespace also hints at such), so I doubt you will have much luck finding any examples.

    Ryan

    Friday, December 10, 2010 5:56 PM
  • I don't see ANY documentation for these types on MSDN, which leads me to belive they are not intended for public use (the RestrictedUsage part of the namespace also hints at such), so I doubt you will have much luck finding any examples.

    Ryan

    They used for the new CodeModel for VS2010 I guess ..there is nothing in MSDN, thats why i'm asking for help.

    Or maybe other suggestions on how to get source tree, like all the namespaces in project, all the classes, go inside the body of methods, and get information about who uses type, what types uses type, where instantiated, all the loops and if/else etc. I think this two namespaces contains all that i need from source, but dont know how to use it. There is ParseTreeVisitor in Syntax. If anyone can gave me some info ..thanks a lot.

     

    Roman.

    Friday, December 10, 2010 6:08 PM
  • >They used for the new CodeModel for VS2010 I guess ..there is nothing in MSDN, thats why i'm asking for help

    The fact they are used for the CodeModel (i.e. they are the underlying bits) doesn't mean they are intended to be used directly.  There are lots of stuff we use internally that aren't intended to be exposed/used directly by third parties.  Some of this has to do with testing/support costs and some to do with the need for us to make breaking changes to these types without worrying about breaking a bunch of third party folks.  I haven't seen any official announcement that these types are used for the CodeModel, I have just seen speculation by someone on a forum that isn't a Microsoft employee, which isn't really substanative as to their nature.

    >Or maybe other suggestions on how to get source tree, like all the namespaces in project, all the classes, go inside the body of methods, and get information about who uses type, what types uses type, where instantiated, all the loops or if/else etc.

    I believe the only documented, supported way would be to use the publically described/documented CodeModel, NOT the bits that that CodeModel may be using 'under the covers' to get its information.  I am not an expert in the CodeModel stuff so I can't give much more help there (maybe someone else here can). I can definetly say using things that aren't documented / intended for public use is a sure way to bring yourself pain.  Those types weren't documented / intended for public use for a reason (not because we are trying to keep all the good bits private), they are HIGHLY likely to change between versions in non-trivial ways, there will be NO support for figuring out how to use them, debugging any issues you run in to and there is no promises that they won't entirely disappear/change drastically in the next release.

    Ryan

    Friday, December 10, 2010 6:14 PM
  • >They used for the new CodeModel for VS2010 I guess ..there is nothing in MSDN, thats why i'm asking for help

    The fact they are used for the CodeModel (i.e. they are the underlying bits) doesn't mean they are intended to be used directly.  There are lots of stuff we use internally that aren't intended to be exposed/used directly by third parties.  Some of this has to do with testing/support costs and some to do with the need for us to make breaking changes to these types without worrying about breaking a bunch of third party folks.  I haven't seen any official announcement that these types are used for the CodeModel, I have just seen speculation by someone on a forum that isn't a Microsoft employee, which isn't really substanative as to their nature.

    >Or maybe other suggestions on how to get source tree, like all the namespaces in project, all the classes, go inside the body of methods, and get information about who uses type, what types uses type, where instantiated, all the loops or if/else etc.

    I believe the only documented, supported way would be to use the publically described/documented CodeModel, NOT the bits that that CodeModel may be using 'under the covers' to get its information.  I am not an expert in the CodeModel stuff so I can't give much more help there (maybe someone else here can). I can definetly say using things that aren't documented / intended for public use is a sure way to bring yourself pain.  Those types weren't documented / intended for public use for a reason (not because we are trying to keep all the good bits private), they are HIGHLY likely to change between versions in non-trivial ways, there will be NO support for figuring out how to use them, debugging any issues you run in to and there is no promises that they won't entirely disappear/change drastically in the next release.

    Ryan

    Oh ..Thank for the answer.

    Waiting for any suggestions for my problem. Any help would be helpful.

    Those namespaces above is from Microsoft.VisualStudio.CSharp.Services.Language assembly located in %MSVS2010_ROOT%\Common7\IDE.

    Roman.

    Friday, December 10, 2010 6:27 PM
  • >Microsoft.VisualStudio.CSharp.Services.Language

    Yep, but just because something is marked 'public' in the dll doesn't mean it is intended for third party use.  Sometimes the rules of the CLR or COM interop require that types be 'public' even if they aren't intended to really be public. It takes MUCH more to design a publically consumable interface than slapping 'public' on the type :) 

    One telltale sign of the 'non-public'nature is the complete absence from MSDN.  I know some of our stuff is sparesely documented, but most of the intentionally public stuff HAS MSDN pages, the pages just might not have a lot of info.  These types have NO MSDN pages, meaning they explicitly chose NOT to document them or expose them in any way.  The fact someone 'found' them doesn't really mean they are intended to be used externally.

    Sorry I can't offer more help, I am just trying to strongly discourage people from taking dependencies on types that aren't intended to be used by third parties. You are free to ignore this advice, but realize any code you write will likely be broken in Dev11 (and beyond) as those interfaces/types change, and Microsoft won't consider it a bug or a problem that they have changed.

    Ryan

    Friday, December 10, 2010 6:40 PM
  • >Microsoft.VisualStudio.CSharp.Services.Language

    Yep, but just because something is marked 'public' in the dll doesn't mean it is intended for third party use.  Sometimes the rules of the CLR or COM interop require that types be 'public' even if they aren't intended to really be public. It takes MUCH more to design a publically consumable interface than slapping 'public' on the type :) 

    One telltale sign of the 'non-public'nature is the complete absence from MSDN.  I know some of our stuff is sparesely documented, but most of the intentionally public stuff HAS MSDN pages, the pages just might not have a lot of info.  These types have NO MSDN pages, meaning they explicitly chose NOT to document them or expose them in any way.  The fact someone 'found' them doesn't really mean they are intended to be used externally.

    Sorry I can't offer more help, I am just trying to strongly discourage people from taking dependencies on types that aren't intended to be used by third parties. You are free to ignore this advice, but realize any code you write will likely be broken in Dev11 (and beyond) as those interfaces/types change, and Microsoft won't consider it a bug or a problem that they have changed.

    Ryan

     

    OK. Thanks for the advice. In that case i'm going to parse source with native C++ :)

     

    Roman.

    Friday, December 10, 2010 6:58 PM
  • You can try using some open source stuff to help there (writing a C++ parser would be...a nightmare :)).  I hear clang is very good, Microsoft also has Phoenix which is a compiler framework but it may be a way to understand compiled code at the binary level (including native code).

    Ryan

    • Marked as answer by Victor_Chen Monday, December 20, 2010 9:39 AM
    Friday, December 10, 2010 7:50 PM
  • You can try using some open source stuff to help there (writing a C++ parser would be...a nightmare :)).  I hear clang is very good, Microsoft also has Phoenix which is a compiler framework but it may be a way to understand compiled code at the binary level (including native code).

    Ryan

    I was thinking about Coco ..its great one ..better in some cases than lex/yacc or flex/bison ..i tnink:)

     

    Roman.

    Monday, December 13, 2010 12:27 PM