Current version of Add-Type cmdlet is partially ported on Roslyn from Dom. It is large breaking change. It is true for most of the parameters. Some parameters was related to Dom and was removed. Some parameters don't implemented. In fact, we already have a new cmdlet.
Before I push new enhancements I want discuss a few points. We could remove old things.
- public enum
Language
Should we keep JScript for backward compatibility?
Should we add FSharp for future?
Should we keep CSharpVersion1, CSharpVersion2 and so on? If yes should we add VisualBasicVersion9 and so on? Could we leave only CSharp and VisualBasic in the enum? Why anybody can want to use CSharpVersion1 in PowerShell?! I found nothing on GitHub - I think we should old elements.
Currently I have to add language family type with CSharp and VisualBasic internally. So I'd prefer simplify public enum Language and don't use the new type and helper functions to translate these types.
- Roslyn can accept parsing and compile options. It is different types for every language (currently CSharp and VusualBasic). Some options (not all) can be useful for Add-Type (language version, preprocessor variables).
How we can better expose the options? Generic or by language? The question related with previous one - with options we can specify the language version. We could Roslyn generic classes but they are not convenient to work in PowerShell. I have no conclusion.
- Should we support creation new assembly without loading? Currently we always load created assembly, even with
-Passthrou. I think we could add -CompileOnly switch.
/cc @SteveL-MSFT @daxian-dbw
Current version of Add-Type cmdlet is partially ported on Roslyn from Dom. It is large breaking change. It is true for most of the parameters. Some parameters was related to Dom and was removed. Some parameters don't implemented. In fact, we already have a new cmdlet.
Before I push new enhancements I want discuss a few points. We could remove old things.
LanguageShould we keep JScript for backward compatibility?
Should we add FSharp for future?
Should we keep CSharpVersion1, CSharpVersion2 and so on? If yes should we add VisualBasicVersion9 and so on? Could we leave only CSharp and VisualBasic in the enum? Why anybody can want to use CSharpVersion1 in PowerShell?! I found nothing on GitHub - I think we should old elements.
Currently I have to add language family type with CSharp and VisualBasic internally. So I'd prefer simplify
public enum Languageand don't use the new type and helper functions to translate these types.How we can better expose the options? Generic or by language? The question related with previous one - with options we can specify the language version. We could Roslyn generic classes but they are not convenient to work in PowerShell. I have no conclusion.
-Passthrou. I think we could add-CompileOnlyswitch./cc @SteveL-MSFT @daxian-dbw