1

In VB.NET (or C#), how can I determine at runtime which namespaces are imported in the Project properties? I'll be using this for dynamic compilation, I'd like the dynamic code to automatically have the same Imports as its parent project.

I've seen "Finding all Namespaces in an assembly using Reflection (DotNET)" already. It and other examples I've found do not appear to solve my issue, as I've found they provide a list of all project references. Yes, I want all these to be accessible, but some through fully qualified names, rather than all Imported into the root namespace. And I want to select solely through the existing Project Properties' "Imported Namespaces" list, rather than maintaining a separate and redundant list in my dynamic execution class.

  • Possible duplicate of [Finding all Namespaces in an assembly using Reflection (DotNET)](http://stackoverflow.com/questions/1549198/finding-all-namespaces-in-an-assembly-using-reflection-dotnet) – thehennyy Mar 25 '16 at 10:25
  • Thanks, but not what I need. I've edited my original question to better explain what's required. –  Mar 25 '16 at 19:27
  • For me its still not clear what you want to achieve. Can you provide a full example? What result do you expect under which conditions? – thehennyy Mar 25 '16 at 22:58
  • My project has lots of references. One of them is "System", and that is something I want imported project-wide, so I can always type Convert instead of System.Convert. Another is "Maat", a user-created class library. Though I reference it I never import it, either at project or file level; part by personal preference and part because it has classes like Maat.Convert, which would conflict with those in System, leading to ambiguity. So if I want to use Maat.Convert, I am used to typing that out in full. (continued in next comment) –  Mar 26 '16 at 00:03
  • Now when dynamically compiling code, I must tell the compiler what my dynamic code will reference, which I want to be identical to the parent project. That's what your link solves, allowing the dynamic code to access both System.Convert and Maat.Convert - but through those fully qualified names. To retain my standard name/access conventions in the dynamic code (accessing System.Convert as just Convert, and Maat.Convert as Maat.Convert), I also need to duplicate the imports as listed in the project properties, rather than importing every reference. (continued again) –  Mar 26 '16 at 00:04
  • And I would strongly prefer to do that automatically, rather than hard-coding a separate list of imports. But I can find no way to discover, at run-time, what the project-wide imports are in the first place. –  Mar 26 '16 at 00:04
  • Do you want to work with the source code or the compiled assemblies of the parent project? – thehennyy Mar 26 '16 at 08:17
  • I'd like to pull the list of imports from the compiled assemblies of the parent project, if possible. –  Mar 26 '16 at 16:51
  • No what you are describing is not possible with the compiled assembly, because its a kind of compiler feature. After compilation there is only the information of the used types (what you can get via reflection), not how they were referenced in the source code. I suggest to play a bit with a .net decompiler of your choice and your assembly to get a sense what is left after compilation. Maybe you can use the roslyn plattform with your source code to get these information. – thehennyy Mar 26 '16 at 17:00
  • I have high confidence that you're correct, imports are used only as inputs to the compiler, and are not output to the compiled assembly in any form. Thank you, thehennyy. If you can repost that it's not possible as an answer, I will formally accept it. –  Mar 26 '16 at 23:39

1 Answers1

1

What you are describing is not possible with the compiled assembly, because its a compiler feature. After compilation there is only the information of the used types (what you can get via reflection), not how they were referenced in the source code.

thehennyy
  • 4,020
  • 1
  • 22
  • 31