Powershell: Future of Add-Type

Created on 20 Dec 2017  路  9Comments  路  Source: PowerShell/PowerShell

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

Area-Cmdlets-Utility Issue-Enhancement Resolution-Fixed

Most helpful comment

Please do add FSharp.

Current versions of FSharp.Compiler.Codedom seem to be broken relative to incorrect version of FSharp.Core -- and no amount of installing packages for various versions had helped me -- or asking on FSharp Slack.

Whose problem would this be? Where should it be reported?
(I think it is stuck half-way between PowerShell & FSharp with no one to care.

All 9 comments

Add-Type was a big change to dotnetcore so I'm personally ok with not maintaining strict compatibility for legacy features that people don't use (with sufficient data).

Ideally, we should use dynamic parameters per language.

I think adding a -CompileOnly switch would be useful.

Please do add FSharp.

Current versions of FSharp.Compiler.Codedom seem to be broken relative to incorrect version of FSharp.Core -- and no amount of installing packages for various versions had helped me -- or asking on FSharp Slack.

Whose problem would this be? Where should it be reported?
(I think it is stuck half-way between PowerShell & FSharp with no one to care.

@HerbM Thanks for your feedback. I like this too. But I don't found FSharp classes in Roslyn repo. It seems it is a separate project. So my current plan is to remove a regression and add VisualBasic support. After that we could research in depth how add FSharp support.

Should we support creation new assembly without loading? Currently we always load created assembly, even with -Passthru

One correction: -PassThru returns the types that were added by Add-Type, so the assembly has to be loaded when it's specified.

Would it be possible to add PowerShell as a language to overcome the limitation link to the PowerShell's keyword Class?

@LMA1980 Could you add more information about your request?

Powershell now have the keyword _class_ and _enum_. When using that method it allow to quickly generate simple class or even extend other classes.

class MyClass { 
[string] myProperty;
[int] anotherProperty; 

MyClass() { 
#...do something - this is a constructor... 
} 

MyClass([PSCustomObject] $object) { 
#... do something using a PSCustomObject as source ...
}
}

Now the issue with such definition, they are only accessible to their Scope and currently they cannot be exported like a Function or a Cmdlet. (https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_classes?view=powershell-5)

With Add-Type -language PowerShell ... This would open up new capability without requiring wrapper like _New-MyClass_ function solution to instanciate such object from outside of a Module scope.

@LMA1980 Thanks for clarify! It seems we have already such request (related with Import-Module). I couldn't find a quick the Issue.

@LMA1980 Please see related Issues #4713, #2964, #2963, #2505, #2449

Was this page helpful?
0 / 5 - 0 ratings